Microservices e Modularidade, de Mark Little, aborda de frente a questão de utilizar ou não microservices. O texto gira em torno do conceito de modularidade, e discute como obter modularidade em uma arquitetura baseada em microservices. Em sua publicação, Mark também menciona outros autores, como Gene Hughson e Simon Brown, que afirmam que a modularidade, por si só, não justifica essa escolha arquitetural.
De fato, a modularidade somente não justifica, nem deve ser considerada em uma abordagem com microservices. Modularidade, com uma base teórica muito clara significa decompor um sistema em módulos com função claramente definida, e reutilizáveis em diversas áreas de uma solução. Um conceito amplamente aplicado a software, mas também à arquitetura, onde surgiu o conceito, e a engenharia em geral.
Microservices, por sua vez, é um conceito bem diferente, a ser usado em arquitetura de sistemas, de aplicações, e não na decomposição de programas em módulos. Além disso, microservices quando bem utilizados tendem a facilitar a estruturação, o desenvolvimento e, principalmente, a evolução de uma aplicação complexa.
Em sua publicação, Mark Little começa analisando a opção monolitos versus uma arquitetura orientada a microservices. No decorrer do texto, Mark defende, acertadamente, que tanto em sistemas monolíticos quanto em uma abordagem com microservices, é necessário estruturar a solução de forma a minimizar a complexidade, e essa é a tarefa da arquitetura de sistemas. Se mal feita, o resultado será uma estrutura em microservices tão complicada quanto um monolito. Por outro lado, é possível desenhar um monolito bem estruturado, reduzindo a complexidade e não chegando naquilo que ele chama de "grande bola de lama". Mark Little finaliza afirmando que microservices também podem transformar uma aplicação numa "grande bola de lama" se não forem bem pensados, independentes, com interface claramente definida e realizando uma só função da aplicação.
Mark menciona Hughson ao dizer que distribuição, uma das características de microservices, não é necessariamente uma forma de chegar a modularidade. Ou seja, a distribuição ‒ que pode chegar a ter microservices rodando em clouds separados, comunicando pela Internet via um protocolo como REST ‒ não leva necessariamente a modularidade. Um mau desenho pode levar a microservices distribuídos que interagem entre si, formando gargalos, quebrando o princípio de independência entre microservices. Ou a uma aplicação lenta, travada pelas inúmeras solicitações através da Internet.
Little menciona Posta quando este diz que a gestão de dados pode ser a parte mais difícil de um desenho de uma arquitetura baseada em microservices. De fato, conseguir que os dados sejam tratados independentemente por cada microservice, sem porisso travar outro microservice que precise acessar os mesmos dados, é duro. Aplicar soluções como definir um microservice que gerencia os dados para todos os outros pode criar um gargalo seriíssimo. O que deve ser feito é mudar para uma arquitetura de dados adequada para microservices, quebrando o paradigma antigo de banco de dados único e rígido. Não é fácil conseguir isso.
Posta continua apontando para a solução geralmente recomendada para microservices: DDD (Domain Driven Design). Encontrar domínios claramente definidos e fechados da aplicação (bounded context). Definir um modelo de dados para cada domínio. Dentro do domínio, cada contexto corresponderá a um microservice. Fica claro que o decisivo é o desenho, é a arquitetura da aplicação. A partir dela, definindo contextos claros, é que se chega à arquitetura de microservices, evitando dependências entre microservices.
O segredo disso está claro na definição básica de microservices por Martin Fowler:
"a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data."
Vale destacar o trecho "uma forma específica de desenhar aplicações como uma série de serviços independentes", bem como as características elencadas por Martin: organização a partir das aptidões do negócio, deployment automático, inteligência nas pontas e controle descentralizado de linguagens e dados.
Este é o ponto fundamental, que acredito ter faltado no artigo de Little: é necessária uma mudança total de atitude quando se desenha uma aplicação. O desenho deve partir do negócio e não da TI. Decompor um sistema em módulos é trabalho da TI, do arquiteto de software. Já decompôr uma aplicação em microservices é trabalho do arquiteto da aplicação. Melhor: do arquiteto do negócio.
A acertada escolha de DDD como método aponta para uma solução: uma radical mudança de ponto de vista, e de lugar na estrutura da empresa. Esta mudança radical tem atualmente um nome e um método: Business Architecture.
A Business Architecture , como todos as metodologias, teve uma evolução longa, passando por várias etapas e chegando recentemente à maturidade. Em junho, no Business Architecture Summit , foi possível verificar esta maturidade nos vários cases, modelos e progressos apresentados: ABN-Amro Bank, Boeing, Lloydś, Maersk Line, Nordea Life, United Airlines entre outras empresas que utilizam a Business Architecture.
Business Architecture consiste em modelar o funcionamento de uma empresa, usando uma série de métodos próximos do desenho de arquitetura ou engenharia (blueprints) e de conceitos fundamentais: capability (identificar o que uma empresa sabe fazer), value streams (como a empresa agrega valor - não confundir com processo), informação, e organização (como a empresa se organiza e como trata a informação).
No que diz respeito ao sinal de maturidade, os diversos métodos utilizados para modelar um negócio convergiram para Business Architecture e chegaram a uma definição comum, adotada pela Federation of Enterprise Architecture Professional Organizations (FEAPO), que congrega OMG, IEEE Computer Society, The Open Group e outras. Esta é a definição adotada:
Business architecture represents holistic, multidimensional business views of: capabilities, end-to-end value delivery, information, and organizational structure; and the relationships among these business views and strategies, products, policies, initiatives, and stakeholders.
Business Architecture representa um visão completa e multidimensional do negócio através de: aptidões, entrega de valor de ponta a ponta, informação e estrutura organizacional; inclui o relacionamento entre estas visões do negócio e estratégias, produtos, políticas, iniciativas e stakeholders.
A mudança radical de ponto de vista consiste em partir do negócio, modelá-lo com a Business Architecture, e a partir deste modelo criar a Arquitetura da TI (IT Architecture). A consequência é que a TI "cola" no negócio e acompanha sua arquitetura. A consequência seguinte é que mudanças no negócio são refletidas por mudanças na TI de uma forma natural. O "change management", o processo ITIL mais temido por gestores de TI, passa a fluir melhor e a atender adequadamente o negócio, tanto em prazo quanto em funcionalidades.
Estas funcionalidades são o que definirão os microservices, como módulos que efetuam uma função do negócio identificada nos modelos da Business Architecture. A dificuldade será, daqui para a frente, conseguir mudar a perspectiva: partir do negócio para a TI, não vice-versa.