BT

Início Notícias Microservices descartáveis

Microservices descartáveis

Favoritos

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?

Avalie esse artigo

Relevância
Estilo/Redação

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

BT

Seu cadastro no InfoQ está atualizado? Poderia rever suas informações?

Nota: se você alterar seu email, receberá uma mensagem de confirmação

Nome da empresa:
Cargo/papel na empresa:
Tamanho da empresa:
País:
Estado:
Você vai receber um email para validação do novo endereço. Esta janela pop-up fechará em instantes.