BT

Microservices descartáveis

| por Mark Little Seguir 14 Seguidores , traduzido por Luis Cesar Barreto Seguir 28 Seguidores em 11 fev 2016. Tempo estimado de leitura: 3 minutos |

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.

Dê sua opinião

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

Receber mensagens dessa discussão
Comentários da comunidade

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

Receber mensagens dessa discussão

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

Receber mensagens dessa discussão

Dê sua opinião

Faça seu login para melhorar sua experiência com o InfoQ e ter acesso a funcionalidades exclusivas


Esqueci minha senha

Follow

Siga seus tópicos e editores favoritos

Acompanhe e seja notificados sobre as mais importantes novidades do mundo do desenvolvimento de software.

Like

Mais interação, mais personalização

Crie seu próprio feed de novidades escolhendo os tópicos e pessoas que você gostaria de acompanhar.

Notifications

Fique por dentro das novidades!

Configure as notificações e acompanhe as novidades relacionada a tópicos, conteúdos e pessoas de seu interesse

BT