É um prazer enorme pra mim iniciar a escrita desta série de artigos. Este “prazer” se dá por vários motivos. O principal deles (e que resume todos os demais) é: através destes conteúdos (o primeiro é este texto) apresentaremos uma série de conceitos e suas respectivas implementações em um projeto que iniciamos há alguns meses aqui na Microsoft (no time de evangelismo) e que tive a honra/responsabilidade de liderar. Estou falando do Arda, uma ferramenta de gestão de workloads de equipes de qualquer tipo e tamanho.
Motivação
Quando escrevi o post “Como é ser evangelista na Microsoft” falei um pouco sobre a nova natureza dessa posição, bem como os desafios que encontramos por aqui todos os dias. Se você não sabe do que estou falando, por favor, siga o link abaixo para efetuar a leitura.
Artigo: Como é ser evengelista na Microsoft?
Como evangelistas trabalhamos muito com o que chamamos por aqui de “early adoption ou dog food” de nossas próprias tecnologias. O que é isso? De forma resumida, temos o dever (mas principalmente o prazer J) de testar todas as novas tecnologias que a Microsoft irá colocar no mercado em um futuro próximo. As vezes trabalhamos com os primeiros alfas, betas, previews e afins. O objetivo é claro: quando estas tecnologias estiverem disponíveis em produção em nossos clientes e/ou parceiros ou ainda, quando uma apresentação com maior nível de detalhe sobre ela nos for solicitada, temos todas as condições técnicas (de preferência em nível 400 ou 500) de atender a estas demandas.
Como você bem sabe, felizmente o mercado de tecnologia muda muito rápido (sim, eu gosto muito disso) e em questão de meses tecnologias que eram amplamente utilizadas se tornam obsoletas. Os motivos dessa rápida metamorfose são diversos: o advento de ferramentas que oferecem um set de recursos maior e que faça mais sentido com o momento atual do mercado, tecnologias mais legais e leves, tecnologias que permitem reduzir custos, tecnologias disruptivas que permitem a criação de novos produtos e serviços ou simplesmente tecnologias que simplesmente fazem o que suas antecessoras também faziam, só que de maneira mais eficiente. Um bom exemplo disso? Basta ver como a computação em nuvem pública vem mudando o mercado, tornando datacenters proprietários (de milhões de dólares) obsoletos em pouco tempo. Hoje praticamente já não há mais quem não reconheça isso. Especificamente sobre este assunto (mudança para a nuvem), gravei um vídeo para o Channel 9 Brasil. Se quiser saber um pouco mais sobre nossa visão sobre, basta seguir o link abaixo para assistir.
Vídeo: Os porquês da movimentação do mercado brasileiro para a nuvem pública
Neste contexto, ouso afirmar que dentre todas as verticais aplicáveis no mercado de TI, a de desenvolvimento de software talvez seja a que mais experimente novas tecnologias em um curto espaço de tempo. É constante o anúncio de novos frameworks, metodologias, linguagens e tecnologias associadas. Por exemplo: há bem pouco tempo (pouco tempo mesmo) AngularJS emergia com o a principal framework para desenvolvimento de frontend em aplicações web. Hoje já temos frameworks que apresentam aspectos mais modernos e eficientes que o Angular (caso do Aurélia por exemplo). Esta realidade também se aplica para desenvolvimento mobile, de nuvem, etc.
Olhando para o cenário de aplicações críticas (de grande escala) o estado da arte neste momento é o que o mercado está chamando de “Microservices” (ou simplesmente, “Microserviços”). Em linhas gerais, um microserviço é uma unidade lógica que possui suas próprias regras de negócio e implementações e que funciona de maneira totalmente isonômica em relação a outros microserviços em um mesmo sistema. Teremos um artigo no futuro apenas para tratar deste tema, portanto, não se preocupe com isso agora. Por ser 100% isonômico ele é propício, portanto, para um ambiente de containers. Aliás, containers é outro assunto super atual e que o mercado ainda tenta entender os melhores cenários de aplicação. Some a isto os ambientes de nuvem e seus amplos recursos de inteligência (como Machine Learning, Bots, etc.), novos frameworks de desenvolvimento (ASP.NET Core, EF Core, etc.) e ferramentas de análise de grandes massas de dados e você terá um cenário amplamente favorável para estudo e provas de conceitos.
Como você deve imaginar, aqui na Microsoft atendemos clientes de todos os tipos e tamanhos e claro, está entre as nossas atribuições analisar cenários e propor modelos de arquitetura que façam sentido para cada um deles. Nos últimos meses temos recebido muitos questionamentos sobre como as aplicações podem ir para a nuvem no modelo de microserviços, sejam novas aplicações ou aplicações já existentes. A dúvida que surgiu neste contexto foi: será que conseguimos propor o melhor modelo de arquitetura baseado apenas no que conhecemos em nível conceitual? Será que não seria importante provarmos este conceito internamente para propor os melhores caminhos?
Além disso, olhando para alguns aspectos internos de nossa área aqui na Microsoft que poderiam ser automatizados, especialmente no time de evangelismo, chegamos a uma reflexão interessante: será que não conseguimos juntos (simulando um modelo de mini fábrica de software) criar uma solução de software que faça estas automatizações úteis utilizando todos os conceitos mencionados nos parágrafos anteriores (microserviços, containers, cache, machine learning, etc.) e ainda implementando o conceito de DevOps utilizando o Visual Studio Team Services (VSTS)? Assim resolveríamos dois problemas (nosso próprio aprendizado + automação de nossa área) com um único projeto. Após algumas reuniões de brainstorm, surgiu então a ideia do Arda.
Sobre o Arda
O Arda é uma ferramenta simples (e esperamos que ela continue sempre assim, mas sem abrir mão da eficiência) que faz gestão de workloads de times no ambiente corporativo. Note, não estamos falando de uma ferramenta de gestão de projetos, estamos falando de gestão de workloads em times, seja este time de desenvolvimento, de marketing, de suporte, de evangelismo ou de que natureza for.
A ideia é que tanto os membros dos times quanto os gestores dos mesmos possam ter uma visão horizontal sobre esforço, custo e banda, seja do time como um todo ou de um profissional específico na equipe.
Além disso, idealmente imaginamos uma ampla integração com os recursos do Office 365 que façam sentido. Por exemplo: Calendário, Active Directory (para autenticação e permissionamento) e Tarefas são alguns dos recursos que imaginamos fazer bastante sentido.
Uma grande inovação que deve ser entregue aqui (talvez não no MVP mas para as próximas versões certamente) é a maneira de coleta de horas trabalhadas em cada workload. Imaginamos uma ampla integração com o Cortana Analytics no sentido de ela (Cortana) solicitar com base em algum padrão de uso do sistema, as horas trabalhadas em cada workload durante o dia (uma computação mais pessoal para o profissional). Legal, não? Nós achamos que sim.
Todos os dados gerados devem ser consolidados em uma base que possa ser consumida por ferramentas como Power BI no sentido de extrair informações relevantes, como por exemplo: Qual profissional tem ficado com maior carga de trabalho quando o assunto é eventos? Além disso, com machine learning pretendemos conseguir informações do tipo: com base nos projetos já entregues com atraso, para o próximo ano, iremos atrasar quantos projetos? Por que iremos atrasar? Enfim, coisas desse tipo.
Uma premissa básica do projeto é que ele seja open source (como tudo o que a Microsoft tem feito de uns anos para cá). Definimos que, assim que primeira versão estiver disponível para uso interno (em produção), todo o código fonte será movido para o GitHub oficial da Microsoft e toda a comunidade poderá contribuir com o projeto. A ideia é que empresas/startups que gostarem da ideia/solução e que queiram utilizar em seus ambientes, o possam fazer gratuitamente e mais, possam personalizar a solução para suas próprias necessidades. Na prática o que importará para a Microsoft aqui é ter a comunidade engajada em um projeto que seja útil para o mercado no geral e ainda praticando os conceitos de microserviços. Se você é dev e se interessa por microserviços e containers, está convidado desde já, a ser um commiter.
Arda: Tecnologias + arquitetura básica
Conforme mencionei anteriormente, o Arda é uma solução que foi feita para funcionar nativamente com base em microserviços. Este fato é importante porque traz consigo uma série metodologias adjacentes, dentre elas, DDD. Mas não quero focar nisso neste texto, uma vez que faremos em um outro no futuro.
A esta altura, mais importante que discutir os aspectos técnicos (de implementação) dos microserviços, é pensar “no(s) porque(s)” faria sentido aumentar a complexidade de desenvolvimento de uma aplicação web (não se iluda, quebrar uma aplicação em microserviços, de fato, não é tarefa simples). Fizemos este exercício diversas vezes aqui no time antes de iniciarmos a codificação de fato e chegamos a algumas conclusões (benefícios técnicos além daqueles apresentados na seção “motivação”) determinantes para fundamentar nossa decisão de partir para este modelo. Confira:
- Escala dirigida por módulos: é fato que é muito mais interessante do ponto de vista de arquitetura que uma aplicação possa escalar módulos ao invés de escalar a aplicação como um todo. Se o gargalo de determinada aplicação está sendo mapeado para o módulo de permissões, por exemplo, então eu preciso escalar apenas este módulo. Isso me isenta de ampliar recursos não necessários.
- Isolamento real entre módulos: alto nível de isolamento entre camadas é algo almejado (por vários motivos) desde de sempre por arquitetos de software. Nos parece que com microserviços de fato isso será possível.
- Desenvolvimento orientado a serviços: o modelo de desenvolvimento dirigido por serviços já é amplamente aceito e difundido em aplicações modernas. Essa difusão se dá por diversos motivos sendo que, um dos principais, é a disponibilização de rotinas de um mesmo backend para o consumo por parte de diferentes modelos de aplicação: web, mobile, standalone, etc. O advento do modelo REST de comunicação associado com o formato JSON de mensagem acelerou ainda mais este processo de adoção.
- Azure pronto para receber este modelo de deployment: se existe uma nuvem preparada para aplicações distribuídas no modelo de microserviços, essa nuvem é o Microsoft Azure. Existem pelo menos 5 caminhos distintos (containers entre eles) para que possamos entregar aplicações com tipo de arquitetura. Dessa forma, nos pareceu coerente adotar a estratégia também para provar o Azure.
- Facilidade de manutenção: este é outro aspecto consideravelmente importante. Dar manutenção em código monolítico frequentemente não é tarefa simples. O isolamento das camadas facilita uma manutenção especializada eficiente.
Existem ainda outros aspectos que tornam o modelo de microserviços altamente recomendável, entretanto, aqueles que julgamos mais importantes e que de fato nos fizeram tomar essa decisão, são os cinco apresentados pela listagem acima.
Tecnologias
Dentre as várias premissas que o Arda deveria atender, algumas obviamente estavam associadas com tecnologias. Queríamos muito testar algumas coisas que temos estudado ao longo dos últimos meses, mas que ainda não tínhamos tido a oportunidade fazer algo “mais sério”, digamos assim. Casos do ASP.NET Core 1.0 (que na ocasião em que o projeto foi iniciado estava na versão RC1), Entity Framework Core, Containers no Azure, Azure Service Fabric (ASF), SQL Server 2016, Visual Studio Team Services, dentre outros. Desta forma, temos o Arda sendo estruturado de acordo com a seguinte pilha de tecnologias:
- Framework de dev: ASP.NET Core 1.0 (Web API + MVC 6) com DNX451
- ORM: Entity Framework Core
- Banco de dados relacional: Azure SQL Databases (Elastic Pool)
- Armazenamento: Azure Storage Standard
- Cache: Azure Redis Cache
- Provedor de autenticação: Azure Active Directory
- Containers: Docker host (sobre Ubuntu Server)
- SMTP: Azure SendGrid
- Frontend: Bootstrap 3 (e recursos associados: jQuery, etc.)
Escopo da primeira versão
Já sabíamos o que queríamos em termos de arquitetura, de tecnologias que deveriam ser utilizadas, de estratégia de desenvolvimento e demais informações técnicas sobre o produto. Faltava agora definir o grupo de recursos e funcionalidades que deveriam fazer parte da primeira versão.
Após algumas rodadas de discussões, chegamos a um pacote inicial de recursos para a primeira versão. Tratam-se de rotinas básicas para que um gerenciamento mínimo possa ocorrer, isto é, um dashboard de tarefas com 4 estados, criação de workloads e backlogs, apontamento de horas, permissionamento para usuários (que deveriam ser provenientes do AD), relatórios e demais rotinas administrativas associadas. Desta forma, a estrutura inicial da solução conta com 4 microserviços e mais um container de operações comuns a todos os microserviços, como pode ser visualizado pela Figura 1.
Figura 1. Arquitetura de microserviços inicial proposta para o Arda
A primeira camada (mais a esquerda) faz menção às estruturas primárias que podem consumir dados do backend da solução. A própria console web do Arda é bom um exemplo, entretanto, poderíamos ter facilmente alguns outros assets como “Power BI”, serviços de outras aplicações, dentre outros fazendo a mesma função.
Kanban: estamos chamando de Kanban o grupo de sub-entidades e respectivas operações que viabilizam a existência de uma dashboard de kanban com seus respectivos workloads e backlogs. Kanban é um projeto do tipo Web API e possui sua própria fonte de dados.
Authentication: trata-se de um microserviço para gerenciar sub-entidades e respectivas operações de autenticação autônoma do sistema (sem qualquer relação com algum provider de autenticação como o Active Directory, por exemplo). O microserviço está pronto e configurado, entretanto, não deverá estar presente na primeira versão do sistema, uma vez que mantivemos o foco apenas na autenticação via AD. A próxima versão da ferramenta deverá contar com este recurso.
Permissions: microserviço responsável por controlar todo o processo de permissionamento de usuários com base na role do Active Directory. A principio a este (autenticação via AD) deveria funcionar em um microserviço separado das permissões, entretanto, seguindo a recomendação da teoria de microserviços, como se tratam de microserviços que “conversam” com muita frequência, decidimos unificar os dois em um microserviço único, que aqui estamos chamando de “Permissions”. A exemplo dos demais, este microserviço possui fonte de dados própria.
Reports: microserviço que deverá cuidar de todas as rotinas associadas a geração de relatórios do sistema. Os dados distribuídos ao longo dos serviços serão consolidados nesta área para que os relatórios possam ser consolidados.
Existe ainda um elemento de suma importância nesta arquitetura – o Common. Common não é exatamente um microserviço, entretanto, ele fornece rotinas e modelos de dados úteis (e visíveis) para todos os demais microserviços. Ele implementa, por exemplo, o recurso que conecta os microserviços com a passagem de objetos como parâmetro, etc.
Finalizando
Gostou? Muita informação, não? Concordo. Fico por aqui neste primeiro artigo. A ideia inicial era apresentar a ideia e a maneira como estruturamos o projeto. Nos próximos artigos trataremos de aspectos mais técnicos de implementação e experiências pelas quais estamos passando durante este processo de desenvolvimento.
Por favor, não esqueça de deixar seus comentários. Queremos um projeto vivo e contamos com as opiniões de vocês para isso.
Forte abraço e até o próximo.
Pingback: Arda – Configurações iniciais e algumas decisões técnicas – Fabrício Sanchez