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.
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 nós, na tentativa de copiar, fazendo engenharia reversa de suas estratégias, estaremos copiando superficialmente o que nos ressalta aos olhos. Se continuarmos a incentivar essa bolha ao redor de Microsserviços, vamos afundar 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 quer que seja que 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 for capaz de olhar o contraditório, não será capaz de avaliar sua própria decisão. E onde mora a unanimidade, mora a ignorância. Quanto mais superficial, pior.
Por isso, mesmo às vésperas do lançamento de um dos meus maiores projetos, o curso Docker Definitivo (será lançado em agosto), venho dar a cara a tapa para dizer o que muitos pensam, mas ninguém quer dizer. Continuo lutando para que ideias sejam maiores que pessoas. Ideias valem a pena serem defendidas. Ideias precisam ser amparadas e contrastadas umas pelas outras para que possamos evoluir o discurso.
O post
Tudo começa com esse o artigo Microservices do Martin Fowler (Leitura obrigatória para quem quer entender Microsserviços). Vou dedicar um post outro inteiro a dissecá-lo. Hoje vamos olhar 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
Ao falarmos de componentização via service, precisamos definir o que são Componentes. É aqui reside o primeiro grande dilema de quem não quer entender os conceito de microsserviços:
Componente são é substituíveis independentemente, e são atualizáveis independentemente.
E para isso ser viável, há esforços de engenharia imensos!
Organized around Business Capabilities
8:15 – Microservices rejeitam a o approach centralizador dos ESB’s
Decentralized Data Management
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
Infrastructure Automation
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
Design for failure
Microservice e SOA
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!
