Microsserviços – Parte VI

Este texto é de James Lewis e Martin Fowler, disponível em: http://martinfowler.com/articles/microservices.html.

Sugiro começar por aqui: Microsserviços – Parte I


Desenhe para falhar

Uma consequência de usar serviços como componentes é que as aplicações devem ser desenhadas para tolerar falhas nos serviços. Qualquer chamada de serviço pode falhar devido a indisponibilidade do fornecedor, o cliente tem que lidar com isso o mais graciosamente possível. É uma desvantagem comparado com o desenho monolítico porque introduz uma complexidade adicional. A consequência é que os times de microsserviços constantemente refletem sobre como as falhas dos serviços afetam a experiência do usuário. O Exército Símio do Netflix induz falhas de serviços e até de datacenters durante o expediente para testar a resiliência e o monitoramento das aplicações.

Esse tipo de teste automatizado em produção é suficiente para trazer aos grupos de operações tremores antes de uma semana de folga. Não quer dizer que os estilos de arquitetura monolíticos não são capazes de configurações sofisticadas de monitoramento – só são menos comuns.

Como os serviços podem falhar a qualquer momento, é importante ser capaz de detectar falhas rapidamente, e, se possível, restaurar o serviço automaticamente. As aplicações de microsserviços colocam muita ênfase no monitoramento em tempo real, verificando tanto elementos arquiteturais (quantas requisições por segundo o banco de dados está recebendo) quanto métricas relevantes para o negócio (quantas encomendas são feitas por minuto.) Monitoramento semântico pode avisar um sistema com antecedência de que algo está errado e engatilhar as equipes de desenvolvimento para investigar.

Isso é particularmente importante para a arquitetura de microsserviços porque a preferência do microsserviço pela coreografia e colaboração de eventos leva a um comportamento emergente. Enquanto vários especialistas louvam o valor da emergência acidental, a verdade é que o comportamento emergente pode ser uma coisa ruim às vezes. Monitoramento é vital para detectar rapidamente o comportamento emergente para que seja corrigido.

Monolitos podem ser construídos para serem tão transparentes quanto microsserviços – e, de fato, deveriam ser. A diferença é que você tem que saber quando os serviços, rodando em processos diferentes, estão desconectados. Com bibliotecas dentro do mesmo processo, esse tipo de transparência não é tão útil.

Os times de microsserviços esperam ver monitoramento e log sofisticados para cada serviço individual, como dashboards mostrando status up/down e uma variedade de métricas operacionais e de negócio relevantes. Detalhes no status de disjuntor (circuit breaker), taxa de transferência e latência são outros exemplos que encontramos com frequência por aí.

Chamadas síncronas são consideradas nocivas

Quando você tem um número de chamadas síncronas entre serviços, você vai encontrar um efeito multiplicativo no tempo de inatividade. Simplesmente, é quando o tempo de inatividade do seu sistema se torna o produto das inatividades de cada componente individualmente. Você enfrenta uma escolha, fazer as chamadas assíncronas ou gerenciar a inatividade. Em http://www.guardian.co.uk, eles implementaram uma regra simples na nova plataforma – uma chamada síncrona por requisição do usuário. No Netflix, o redesenho da API da plataforma tem a assincronia construída no próprio tecido da API.

Desenho Evolutivo

Praticantes de microsserviços, normalmente, vêm de uma experiência evolutiva e vêem a decomposição do serviço como uma ferramenta para permitir que os desenvolvedores controlem as mudanças na aplicação sem reduzir a velocidade de mudanças. Controle das mudanças não necessariamente significa redução das mudanças – com as atitudes e ferramentas certas, você pode fazer mudanças frequentes, rápidas e bem controladas no software.

Quando você tenta quebrar um sistema em componentes, você toma a decisão de como dividí-lo em pedaços – quais são os princípios para essa decisão? A propriedade chave de um componente é a troca e atualização independentes [13] – o que implica olhar para os pontos onde podemos imaginar reescrever um componente sem afetar seus colaboradores. Muitos grupos de microsserviços levam isso ainda mais a sério, ao esperar explicitamente que os serviços serão sucateados em vez de evoluídos no longo prazo.

O site do The Guardian é um bom exemplo de uma aplicação que foi desenhada e construída como um monolito, mas está evoluindo na direção de microsserviços. O monolito ainda é o centro do site, mas eles preferem adicionar novas funcionalidades construindo microsserviços que usam a API do monolito. Essa abordagem é bastante útil para funcionalidades temporárias, como páginas especializadas para um evento de esportes. Essa parte do site pode ser feita usando linguagens de prototipagem rápida e removidas quando o evento acaba.Vemos abordagens parecidas em uma instituição financeira, onde novos serviços são adicionados para aproveitar uma oportunidade do mercado e descartados alguns meses ou semanas depois.

Essa ênfase em ser substituível é um caso especial de um princípio mais geral de desenho modular, que é direcionar a modularidade de acordo com a mudança [14]. Você quer manter juntos no mesmo módulo as coisas que mudam ao mesmo tempo. Partes de um sistema que mudam raramente devem estar em serviços diferentes das que estão em passando por uma agitação. Se você repetidamente tiver que mudar dois serviços juntos, é um sinal de que deveriam ser fundidos em um.

Colocar os componentes em serviços adiciona uma oportunidade para um planejamento mais granular das entregas. Com um monolito, qualquer mudança requer uma construção e implantação completa de toda a aplicação. Com microsserviços, você só precisa implantar o serviço que modificou. Isso pode simplificar e acelerar o processo de lançamento. O lado negativo é que você precisa se preocupar se as mudanças não vão quebrar outros serviços. A abordagem tradicional de integração é tentar lidar com esse problema usando versões, mas a preferência no mundo de microsserviços é só usar versionamento como último recurso. Podemos evitar muito versionamento ao desenhar os serviços para serem o mais tolerante possíveis com as dependências.

Microsserviços são o futuro?

Nosso objetivo principal em escrever esse artigo é explicar a maiorias das ideias e princípios de microsserviços. Tomando um tempo para fazer isso, achamos claramente que o estilo de arquitetura de microsserviços é uma ideia importante – uma que vale considerações sérias para aplicações corporativas. Construímos vários sistemas recentemente usando esse estilo e conhecemos outras pessoas que usaram e sugerem essa abordagem.

Aqueles que conhecemos que são, de alguma forma, pioneiros nesse estilo incluem Amazon, Netflix, The Guardian, o Serviço Digital do Governo do Reino Unido, realestate.com.au, Forward e comparethemarket.com. O circuito de conferências em 2013 foi cheia de exemplos de empresas que estão indo em direção a algo que se classificaria como microsserviços – incluindo Travis CI. Além disso, há muitas empresas que há muito tempo fazem o que classificamos como microsserviços, mas sem usar o nome. (Normalmente, são chamados de SOA – mesmo que, como dissemos, SOA apareça em formas contraditórias. [15])

Apesar das experiências positivas, não estamos afirmando que temos certeza de que os microsserviços sejam o futuro das arquiteturas de software. Por enquanto, nossa experiência foi positiva comparada com aplicações monolíticas, mas estamos conscientes de que não se passou tempo suficiente para termos um julgamento completo.

Muitas vezes, as verdadeiras consequências das decisões arquiteturais só ficam evidentes muitos anos depois. Vimos projetos onde uma boa equipe, com forte desejo de modularidade, construiu uma arquitetura monolítica que ficou decadente ao longo dos anos. Muitas pessoas acreditam que a decadência é menos provável com microsserviços, porque as fronteiras são explícitas e difíceis de contornar. Ainda assim, não podemos afirmar como a arquitetura de microsserviços amadurece antes de vermos um número suficiente de sistemas envelhecer.

Há algumas razões para esperar que microsserviços amadureçam de forma ruim. Em qualquer esforço de componentização, o sucesso depende de quão bem o software se encaixa em componentes. É difícil imaginar exatamente onde as fronteiras dos componentes devem ficar. O desenho evolutivo reconhece as dificuldades de acertar as fronteiras e a importância de ser fácil refatorá-las. Mas quando os componentes são serviços com comunicações remotas, refatorar é muito mais difícil que bibliotecas. Mover código através das fronteiras de serviços é difícil, qualquer mudança na interface deve ser coordenada entre os participantes, camadas de retrocompatibilidade devem ser adicionadas, e testar fica mais complicado.

Outro problema é se os componentes não se comporem claramente, então você muda a complexidade de dentro do componente para as conexões entre os componentes. E isso também move a complexidade para um lugar que é menos explícito e mais difícil de controlar. É fácil pensar que é melhor olhar dentro e um componente pequeno e simples, mas esquecer as conexões complicadas entre os serviços.

Finalmente, há o fator das habilidades da equipe. Novas técnicas tendem a ser adotadas por equipes mais habilidosas. Mas uma técnica mais efetiva para uma equipe habilidosa não necessariamente vai funcionar para equipes menos preparadas. Vimos vários casos de equipes menos habilidosas construindo arquiteturas monolíticas bagunçadas, mas demora mais tempo para ver o que acontece quando esse tipo de bagunça ocorre em microsserviços. Um time fraco vai sempre criar um sistema fraco – é muito difícil dizer se microsserviços diminuem a bagunça nesse caso, ou se pioram.

Um argumento razoável que ouvimos é que não deveríamos iniciar com arquitetura de microsserviços. Em vez disso, comece com um monolito, deixe-o modular, e separe-o em microsserviços quando o monolito se tornar um problema. (Mesmo que essa sugestão não seja ideal, uma vez que uma interface dentro de uma aplicação geralmente não é uma boa interface entre serviços.)

Então, escrevemos com um otimismo cauteloso. Até agora, vimos o suficiente sobre o estilo para sentir que é uma estrada que vale a pena. Não podemos dizer com certeza onde vamos terminar, mas um dos desafios do desenvolvimento de software é que você só pode tomar decisões baseadas nas informações imperfeitas que você têm atualmente na mão.


[13] De fato, Dan North se refere a esse estilo como Arquitetura de Componentes Substituíveis, em vez de microsserviços. Como isso se refere de um subconjunto das características, preferimos o termo microsserviços.

[14] Kent Beck salienta isso ccomo um dos seus princípios de design em Padrões de Implementação

[15] SOA está longe de ser a raíz dessa história. Lembro de pessoas dizendo “fazemos isso há anos” quando o termo SOA surgiu no início do século. Um argumento é que o estilo vê suas raízes como os programas COBOL se comunicavam por arquivos de dados nos primeiros anos da computação corporativa. Por outro lado, você poderia argumentar que microsserviços são a mesma coisa que o modelo de programação Erlang, mas aplicado no contexto de aplicação corporativa.

Anúncios
Marcado com: , , ,
Publicado em Microsserviços

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: