Microsserviços desempenham um papel importante em muitas organizações hoje em dia. O movimento ganhou força com o artigo seminal de James Lewis e Martin Fowler, seguido pelo livro de Sam Newman e várias palestras e artigos de Thoughtworkers, da Netflix, Google e várias outras. Os microsserviços chegaram rapidamente ao anel Experimente no Technology Radar da Thoughtworks, mas nunca chegaram ao anel Adote. Hoje, quero explorar a razão pela qual a os microsserviços não está no Adote.
Dadas essas definições, por que não colocamos microsserviços ou arquiteturas de microsserviços em Adote? Afinal, os microsserviços são comumente debatidos em conferências e pautam artigos. Mais e mais organizações estão mudando para esse estilo. Times da Thoughtworks as utilizaram com sucesso em muitos projetos. Existem várias razões, algumas derivando da definição de Adote, mas outras mais específicas relacionadas a microsserviços. Vamos começar com o problema específico do radar.
Mover algo para Adotar é uma afirmação muito forte. Não queremos que haja muita sutileza envolvida em considerar a recomendação. Adotar significa que estamos confiantes de que esta é a escolha correta para um conjunto de circunstâncias facilmente definido. Ao considerar microsserviços, embora haja algumas vantagens claras, também há custos. Os trade-offs de custo-benefício variam de acordo com a organização; é a maturidade, o domínio e outros fatores que podem afetar os recursos de desenvolvimento disponíveis. Nós não poderíamos ignorar a recomendação Adotar para esse grau. Mesmo que pudéssemos, isso não é realmente consistente com a forma como pensamos sobre nossas recomendações de adoção. Não deve haver ambiguidade em uma recomendação para adotar.
Outro aspecto, mais importante, do anel Adote é que deve ser algo que possa ser amplamente adotado universalmente em toda a ampla gama de maturidade de nossos clientes e empresas em geral. Algo que funciona bem para start-ups, mas não para organizações maiores, por exemplo, não deve entrar em Adote. Um exemplo proeminente disso foi quando os sistemas de controle de versão distribuída passaram a ser amplamente utilizados em empresas de tecnologia. Nós não os colocamos em Adote porque, na época, muitas empresas ainda estavam lutando para adotar o controle básico de fontes. Nós sentimos o salto do nada para o controle de versão distribuído era grande demais para fazer a forte recomendação para Adotar. Nós acabamos colocando o Github em Adote, mas isso foi alguns anos depois.
Da mesma forma, uma arquitetura de microsserviços tem modos de erro que simplesmente não são possíveis em um aplicativo monolítico. Os sistemas de microsserviços são inerentemente distribuídos, e os processos de negócios são mais frequentemente concluídos por meio da interação de vários microsserviços. Em um monolito, esses processos de negócios são executados com maior frequência dentro do mesmo limite de processo, permitindo transações tradicionais e garantindo a execução de tudo ou nada. Embora tenhamos soluções para todos esses problemas, a abordagem de microsserviço introduz esses problemas e exige que eles sejam resolvidos. Assim, há uma compensação (comum) entre a maior flexibilidade da abordagem de microsserviços e a simplicidade da abordagem monolítica, particularmente se for um monólito bem estruturado. Aplicativos que não se beneficiarão da flexibilidade são candidatos ruins para uma arquitetura de microsserviços.
Uma decisão de design crucial para uma arquitetura de microsserviços é a colocação dos limites entre os serviços. Embora contextos limitados certamente forneçam uma forte orientação para onde os limites apropriados estão, as escolhas ainda existem e a escolha errada complica o sistema. Pode não estar claro para um novo domínio onde os limites adequados estão, portanto, há alguma justificativa para não começar com uma arquitetura de microsserviços até que o domínio e os contextos apropriados sejam mais claros.
Adote estabelece um padrão deliberadamente alto
Primeiro, vamos relembrar as definições dos anéis Experimente e Adote no Radar. Experimente significa que a tecnologia está pronta para as empresas testarem em seus próprios sistemas. Colocamos a tecnologia em produção com sucesso em algum lugar, estamos confiantes de que ela é estável e sabemos como e onde fazê-la funcionar. Algo no anel Adote significa que acreditamos que, quando aplicável, essa tecnologia deve ser o padrão. No caso de bancos de dados, o fato de o banco de dados gráfico Neo4J estar no Adote não significa que todos os dados devam estar em bancos de dados gráficos. Significa que, se você quiser usar um banco de dados gráfico, o Neo4J seria a escolha padrão no momento em que o movemos para o Adote.Dadas essas definições, por que não colocamos microsserviços ou arquiteturas de microsserviços em Adote? Afinal, os microsserviços são comumente debatidos em conferências e pautam artigos. Mais e mais organizações estão mudando para esse estilo. Times da Thoughtworks as utilizaram com sucesso em muitos projetos. Existem várias razões, algumas derivando da definição de Adote, mas outras mais específicas relacionadas a microsserviços. Vamos começar com o problema específico do radar.
Mover algo para Adotar é uma afirmação muito forte. Não queremos que haja muita sutileza envolvida em considerar a recomendação. Adotar significa que estamos confiantes de que esta é a escolha correta para um conjunto de circunstâncias facilmente definido. Ao considerar microsserviços, embora haja algumas vantagens claras, também há custos. Os trade-offs de custo-benefício variam de acordo com a organização; é a maturidade, o domínio e outros fatores que podem afetar os recursos de desenvolvimento disponíveis. Nós não poderíamos ignorar a recomendação Adotar para esse grau. Mesmo que pudéssemos, isso não é realmente consistente com a forma como pensamos sobre nossas recomendações de adoção. Não deve haver ambiguidade em uma recomendação para adotar.
Outro aspecto, mais importante, do anel Adote é que deve ser algo que possa ser amplamente adotado universalmente em toda a ampla gama de maturidade de nossos clientes e empresas em geral. Algo que funciona bem para start-ups, mas não para organizações maiores, por exemplo, não deve entrar em Adote. Um exemplo proeminente disso foi quando os sistemas de controle de versão distribuída passaram a ser amplamente utilizados em empresas de tecnologia. Nós não os colocamos em Adote porque, na época, muitas empresas ainda estavam lutando para adotar o controle básico de fontes. Nós sentimos o salto do nada para o controle de versão distribuído era grande demais para fazer a forte recomendação para Adotar. Nós acabamos colocando o Github em Adote, mas isso foi alguns anos depois.
Nem todas as organizações estão preparadas para microsserviços
Este último ponto é o principal motivador da nossa decisão de não transferir microsserviços para o anel Adote. Como Martin Fowler aponta aqui em um de seus posts sobre microsserviços, há um nível mínimo de maturidade necessário em coisas como entrega contínua e práticas de automação de infraestrutura antes que microsserviços sejam considerados. Este nível de maturidade ainda é um alongamento para muitas organizações. Os microsserviços sobrecarregam as operações, pois há mais coisas para monitorar e alertar, além de mais coisas para implantar. Automatização abrangente e práticas de entrega contínua são essenciais neste contexto.Da mesma forma, uma arquitetura de microsserviços tem modos de erro que simplesmente não são possíveis em um aplicativo monolítico. Os sistemas de microsserviços são inerentemente distribuídos, e os processos de negócios são mais frequentemente concluídos por meio da interação de vários microsserviços. Em um monolito, esses processos de negócios são executados com maior frequência dentro do mesmo limite de processo, permitindo transações tradicionais e garantindo a execução de tudo ou nada. Embora tenhamos soluções para todos esses problemas, a abordagem de microsserviço introduz esses problemas e exige que eles sejam resolvidos. Assim, há uma compensação (comum) entre a maior flexibilidade da abordagem de microsserviços e a simplicidade da abordagem monolítica, particularmente se for um monólito bem estruturado. Aplicativos que não se beneficiarão da flexibilidade são candidatos ruins para uma arquitetura de microsserviços.
Uma decisão de design crucial para uma arquitetura de microsserviços é a colocação dos limites entre os serviços. Embora contextos limitados certamente forneçam uma forte orientação para onde os limites apropriados estão, as escolhas ainda existem e a escolha errada complica o sistema. Pode não estar claro para um novo domínio onde os limites adequados estão, portanto, há alguma justificativa para não começar com uma arquitetura de microsserviços até que o domínio e os contextos apropriados sejam mais claros.
Os microsserviços ainda são incrivelmente importantes para as empresas!
Você provavelmente já está se perguntando por que ou se ainda recomendamos uma arquitetura de microsserviços. A flexibilidade, a escalabilidade independente, as características evolutivas, o forte encapsulamento ainda são benefícios muito reais para uma abordagem de microsserviços. Esses benefícios são bem articulados em outros lugares. Ainda estamos firmemente comprometidos com o uso de arquiteturas de microsserviço, ampliando nossa compreensão dessas arquiteturas e continuando a explorar ferramentas e abordagens que abordam os problemas aqui descritos. De fato, Zhamak Dehghani, da Thoughtworks, publicou recentemente este artigo sobre a decomposição de um monolito em microsserviços. No entanto, os custos e desvantagens da abordagem e o nível de maturidade organizacional necessários para executar a abordagem são a razão pela qual os microsserviços provavelmente nunca passarão para o Adote.Aviso: As afirmações e opiniões expressas neste artigo são de responsabilidade de quem o assina, e não necessariamente refletem as posições da Thoughtworks.