No post passado eu introduzi uma analogia sobre o automobilismo profissional, e como os avanços tecnológicos chegam ao nosso dia-a-dia como consumidores de automotivos, carros de passeio.

Preambulo

A ideia foi contrastar duas realidades: Early Adopters com dinheiro infinito e nós, mundanos com orçamentos apertados.

Esse contraponto tenta trazer para a luz da discussão a lembrança de que Netflix e Amazon são players que podem se dar ao luxo de terem as arquiteturas que têm.

Enquanto isso, nós na tentativa de copiar, fazendo engenharia reversa de suas estratégias, estaremos copiando superficialmente o que nos ressalta aos olhos, ou simplesmente o que é viável.

Se continuarmos a incentivar essa bolha ao redor de Microsserviços, afundemos não só nossos projetos, mas nós mesmos, nossas empresas, e o termo microsserviço será enterrado como SOA foi.

Um novo passo nessa jornada começa agora, dedico esse post à compreensão de um dos principais fatores para o fracasso dos mais variados projetos técnicos:

Incompetência técnica e incapacidade de compreensão.

Sim, é agressivo, mas uma visão míope somada à busca pelo viés de confirmação, tentando achar quem sustente uma ideia que se pareça com a sua, o faz sentir-se cheio de si e firma na sua visão de que seus esforços estão empenhados na direção certa, fazendo a coisa certa.

Se você não conseguir olhar o contraditório, não conseguirá avaliar sua própria decisão. Onde mora a unanimidade, mora a ignorância.

O post

Tudo começa com esse o artigo Microservices do Martin Fowler (Leitura obrigatória para quem quer entender Microsserviços). Dedicarei um post outro inteiro a dissecá-lo. Hoje olhemos para um material um pouco menos denso. Um vídeo da GOTO Conference, realizada em Berlin em 2014.

A apresentação

Vamos começar olhando para as características gerais dos microsserviços:

Componentization via services

3:54

Ao falarmos de Componentização por meio de serviços, precisamos definir o que são Componentes. É aqui reside o primeiro grande dilema de quem não quer entender os conceitos de microsserviços:

Componente são substituíveis e atualizáveis independentemente.

E para isso ser viável, há esforços de engenharia imensos!

Aqui é um dos pontos em que databases compartilhados vão fracassar. É aqui que decisões sobre a infraestrutura errada ou a falta de automação vão fracassar.

Load balancer? Orquestração? DevOps? O que será necessário para que seu serviço de fato seja substituível e atualizável de forma independente e autônoma?

Organized around Business Capabilities

6:37

8:15 – Microservices rejeitam a o approach centralizador dos ESB’s

Quando olhamos para nosso código, quando olhamos para os nossos deployments, nossas solutions e até nossos repositórios GIT, vemos uma divisão bem radical em relação ao que observávamos em uma arquitetura monolítica.

A forma como agrupamos, organizamos e gerenciamos serviços muda, e a palavra de ordem aqui é independência e autonomia.

Decentralized Data Management

9:20

Pelo ponto de vista de microsserviços, ele diz não (em contraponto aos monolitos), cada serviço é responsável pelos seus próprios dados e por sua própria persistência… Você nunca fala com o data store de outro serviço a não ser via sua API.

Pelo ponto de vista de microsserviços, ele diz não (em contraponto aos monolitos), cada serviço é responsável pelos seus próprios dados e por sua própria persistência… Você nunca fala com o data store de outro serviço a não ser via sua API.
Martin Fowler

Mas eu li que Shared Database é um pattern…

Um dos principais contrapontos que recebo sobre o tema está relacionando ao “Pattern: Shared database” que o Chris Richardson documentou em microservices.io (link).

Se você acha esse argumento válido para continuar compartilhando databases e considera que está trabalhando com microsserviços, leia isso:

É o comentário do autor do post. Resolvi tirar o print, pois a ferramenta de comentários utilizada no blog é externa, pode em alguns anos não estar mais no ar e não gostaria de perder isso.

Infrastructure Automation

11:22

Pra fazer tudo isso funcionar, é realmente importante que haja automação de infraestrutura. Várias coisas como Continous Delivery, técnicas como Blue/Green Deployment que permite por coisas online com zero downtime. Esses tipos de coisas são obrigatórios também para colocar este tipo projeto para rodar, porque você está falando sobre construir o que seria uma aplicação como uma dúzia ou duas dúzias de serviços, por isso é muito importante que você tenha uma maneira muito automatizada de fazer essas coisas rodarem.
Martin Fowler

Aqui estamos falando do que muita gente chama de DevOps. Eu não compartilho dessa visão e pelo título do tópico, dado pelo Fowler, aparentemente ele também não compartilha dessa visão.

Em um cenário de microsserviços, fazer deploy manual, seja usando o publish do visual studio não é uma estratégia inteligente. Aliás, ela te trará impactos muito negativos para seu desenho de microsserviços.

Design for failure

12:11

A premissa de que há a necessidade de isolamento dos componentes da arquitetura em deployments independentes nos traz problemas adjacentes. A distribuição de aplicações e a necessidade de comunicação entre elas produz falhas que antes não existiam.

Você nunca precisou testar conectividade ente uma classe A que chama um método da classe B em um monólito. Isso nunca causou falha antes. Mas ao passo que estar remoto nos coloca em uma situação onde falhar é uma possibilidade, quase uma certeza.

A gente encontra não só mensageria como solução, mas também engenharia de caos para produzir falhas ao ponto de conseguirmos avaliar o comportamento dos nossos serviços diante de falhas.

Microservice e SOA

13:23

Você precisa fazer isso tudo para usar microsserviços

E não para por aí. Essa apresentação é incrível e deveria ser exibida como conteúdo introdutório ao assunto. Deveria ser assistida cada vez que se fala em compartilhamento de dados de serviço via banco.

Tanto a apresentação como o texto são incríveis pois apresentam tradeoffs  a respeito da utilização de microsserviços, apontam claramente algumas das complexidades inerentes a esse desenho.

Microsserviços é complexo, um grande problema que vejo repetidamente, hoje, ao redor do assuntos é o olhar simplista, ingênuo e permissivo sobre Componentization via services. Sobre termos como independently replaceable and upgradeable e principalmente, suas conseqüências práticas. Não consigo ver esse tipo de arquitetura trabalhando sem um Event Stream, por exemplo.

Essa permissividade, que facilmente pode ser encontrara em quem se diz fazendo microsserviços com um banco monolítico, produz aberrações que vão na contramão daquilo que toda essa complexidade se preza a resolver:

• Deploys parciais, independentes e mais frequentes.
• Alta disponibilidade
• Modularidade

Conclusão

Microservices ou é necessidade fundamental, ao ponto de sua empresa ou projeto não sobreviver sem.

Ou é desnecessário!

Se inspirar em microsserviços e fazer o que é viável ou o que lhe traz maior resultado é completamente diferente de fazer algo pela metade, que não traz nem de longe metade dos benefícios, e no final dizer que usa microsserviços só para “fazer parte do clubinho”.

Outro ponto relevante: Microsserviços é mais caro, exige mão de obra especializada e Highlanders Full Stack. Suspeite de quem te vende alocação e quer te convencer a usar microsserviços, vendendo como se fosse um passaporte para a terra do nunca. Se você não tem budget para isso tudo, você não tem demanda para isso tudo!