Recentemente James Governor da RedMonk escreveu um artigo precursor para sua apresentação na Dreamforce, sobre a descartabilidade dos microservices. Governor teve essa ideia durante uma conversa recente:
A descartabilidade na infraestrutura vem sendo melhorada, e essa é uma das razões na adoção de containers, na verdade, é a definição de microservices.
Na essência, a agora bem entendida distinção entre iniciantes e os mais experientes em infraestrutura (discutido por Randy Bias, InfoQ.com e outros) pode e deve ser aplicada aos microservices.
A muito tempo, a descartabilidade vem sendo utilizada, lembro-me da surpresa ao ficar sabendo como a Google acabou com as falhas de hardware, simplesmente jogando fora as máquinas velhas de vez em quando, sem a necessidade de fazer algo de imediato. Na Google, a arquitetura de software significa dizer que o hardware se tornou descartável. Hoje, essa ideia (ou ideal) arquitetônica está se tornando um princípio central de design para a computação em nuvem.
A abordagem da infraestrutura imutável, que a adoção vem crescendo rapidamente, é um aspecto essencial de solução para descartabilidade. Chad Fowler disse isso em 2013, quando sua companhia havia se direcionado para adoção da imutabilidade pela primeira vez e visualizou isso como uma forma de resolver muitos problemas com a modernização da infraestrutura.
É necessário atualizar? Sem problemas. Construa um sistema novo e atualizado, e descarte o antigo. Uma nova revisão no aplicativo? Faça o mesmo. Construa um servidor (ou imagem) com uma nova versão e descarte os antigos.
Embora Mitchell Hashimoto tenha dito em nossa sessão de painel virtual em 2014, que a imutabilidade não é uma panaceia para tudo:
Possui seus benefícios e também suas desvantagens. No geral, acredito que possa ser uma escolha poderosa e um caminho correto, mas é importante estar ciente que não é uma solução rápida para um grande problema, e introduzirá alguns problemas que não aconteceram antes (enquanto resolve os outros).
Embora hoje a imutabilidade tenha sido o foco no nível da infraestrutura, Governor acredita que esse padrão é aplicável à maior parte da pilha. Citando um recente artigo da RedMonk, escrito por Stephen O'Grady, que pergunta qual é a unidade atômica da infraestrutura no futuro?
Containers e Docker geralmente tratam o sistema operacional e tudo abaixo dele como um substrato compartilhado, algo não tão importante como a aplicação em si. Para containers, a unidade de base de uma construção é a aplicação. Esse é somente o elemento único real.
Ao longo dos anos diversas afirmações semelhantes, que os microservices deveriam ser descartáveis, sem necessariamente equiparar-se á imutabilidade. Um exemplo disso, foi a afirmação recente de Kief Morris em seu artigo, embora de forma não específica, o que ainda é relevante aos microservices:
Com a entrega contínua de software, é mais seguro compilar uma determinada versão de um aplicativo dentro de um artefato implementável apenas uma vez, e saber que se está implementando e executando um aplicativo integrável em qualquer ambiente. Com um servidor imutável, faz-se alteração em uma imagem da base, e então sabe-se que todas as instâncias criadas dessa imagem são consistentes.
Relatamos no ano passado, como Pat Helland da Salesforce acredita que a imutabilidade altera os microservices e muito mais:
Muitos tipos de computação são para adicionar informações. Observações são registradas para sempre (ou por um longo tempo). Resultados derivados são calculados sob demanda (ou periodicamente recalculados). E normalização é para iniciantes !
Apesar da imutabilidade e microservices representarem algo que algumas pessoas pensam a algum tempo em implementar, a epifania da descartabilidade que James Governor mencionou é relativamente pouco discutida em sua área. Como Galen Gruman e Alan Morrison mencionaram, a descartabilidade é uma evolução lógica dos microservices e da arquitetura da imutabilidade.
Pense em MSA (Arquitetura de Microservices) como quase um plug-and-play em um serviço de integração discreto, ambos locais e externos. Espera-se que esses serviços mudem, e alguns eventualmente venham a se tornar descartáveis. Quando esses serviços têm um pequeno foco, tornam-se simples para desenvolver, entender, gerenciar e integrar. Fazem somente o que é necessário e podem ser removidos ou ignorados quando deixam de ser necessários.
Com isso, Governor conclui:
Os microservices devem ser descartáveis. Se um microservice falha ou é substituído por um serviço melhor, então simplesmente descarta-se o antigo.
Será que "devem" seja um termo muito forte ou talvez este seja um padrão que os outros desenvolvedores de microservices já usam ou estão caminhando nessa direção?