essa é uma tradução do texto MicroservicePrerequisites de Martin Fowler, por favor poste nos comentários alguma crítica ou sugestão da tradução.
https://twitter.com/martinfowler
28 de agosto de 2014
Quando eu falo com as pessoas sobre como usar um estilo de arquitetura de microserviços eu percebo muito otimismo. Os desenvolvedores gostam de trabalhar com unidades menores e têm expectativas de melhor modularidade com monolitos. Mas como com qualquer decisão de arquitetura, existem suas vantagens e desvantagens. Em particular, com os microserviços, há consequências graves para as operações, que agora têm de lidar com um ecossistema de pequenos serviços, em vez de um monolito único e bem definido. Consequentemente, se você não tiver determinados pré-requisitos na linha de base, você não deve considerar o uso de microserviços.
Rápido provisionamento: você deve ser capaz de iniciar um novo servidor em questão de horas. Naturalmente isso se encaixa com Cloud Computing, mas também é algo que pode ser feito sem um serviço de nuvem. Para ser capaz de fazer esse rápido provisionamento, você precisará de muita automação – pode não ter que ser totalmente automatizado no início, mas para fazer microserviços importantes ele deve ficar sem falta.
Monitoramento básico: com muitos serviços de baixo acoplamento que se conversam em produção, as coisas podem dar errado de maneiras que são difíceis de detectar em ambientes de teste. Como resultado, é essencial que haja um regime de monitoramento para detectar problemas graves rapidamente. A linha de base aqui é detectar problemas técnicos (contador de erros, disponibilidade de serviços, etc), mas também vale a pena monitorar problemas de negócios (como detectar uma queda nos pedidos). Se um problema aparece de repente, você precisa para garantir que pode rapidamente restaurar tudo (fazer um rollback), portanto …
Rápido deploy de aplicações: com muitos serviços para gerenciar, você precisa ser capaz de fazer o deploy rapidamente, tanto para testar ambientes como para produção. Normalmente, isso envolve um pipeline de deploy que pode demorar no máximo algumas horas. Alguma intervenção manual é aceitável no início, mas você deve automatizar tudo em breve.
Essas capacidades implicam em uma mudança organizacional importante – muita colaboração entre desenvolvedores e operações: a cultura DevOps. Essa colaboração é necessária para garantir que os provisionamentos e os deploys possam ser feitos rapidamente, também é importante garantir que você possa reagir rapidamente quando o monitoramento indicar algum problema. Em particular, qualquer gerenciamento de incidentes precisa envolver a equipe de desenvolvimento e operações, tanto na resolução do problema imediato quanto na análise da causa raiz para garantir que os problemas sejam corrigidos.
Com este tipo de configuração funcionando, você está pronto para ter um primeiro sistema usando alguns microserviços. Fazer o deploy desse sistema e usá-lo em produção, espere aprender muito sobre como mantê-lo no ar e garanta que a colaboração devops esteja funcionando bem. Leva tempo para fazer tudo isso, aprenda com a situação, e cresça mais a sua capacidade antes de acelerar o seu número de serviços.
Se você não tem esses recursos agora, você deve garantir que você vai desenvolvê-los para que eles estejam prontos pelo tempo que você colocar um sistema de microserviços em produção. Na verdade, esses são requisitos que você deveria ter para sistemas monolíticos também. Embora esses recursos não estejam universalmente presentes em todas as organizações de software, existem muito poucos lugares onde eles não deveriam ser uma alta prioridade.
Ir além de um alguns de serviços requer muito mais. Você precisará rastrear as transações de negócio por meio de vários serviços e automatizar seu provisionamento e deploy adotando a entrega contínua . Existe também a mudança que precisa ser iniciada de formar equipes especializadas em produtos. Você precisará organizar seu ambiente de desenvolvimento para que os desenvolvedores possam trocar facilmente entre vários repositórios, bibliotecas e linguagens. Alguns dos meus contatos estão percebendo que o uso do modelo de maturidade pode ser útil para ajudar as organizações conforme eles assumem mais implementações de microserviços – devemos ver mais sobre isso nos próximos anos.
Agradecimentos
Essa lista veio de algumas discussões com meus colegas da ThoughtWorks, particularmente aqueles que participaram do microservice summit no começo desse ano. Eu estruturei e finalizei a lista na discussão com Evan Bottcher, Thiyagu Palanisamy, Sam Newman e James Lewis.
Como sempre existem comentários valiosos de nossa lista de email interna de Chris Ford, Kief Morris, Premanand Chandrasekaran, Rebecca Parsons, Sarah Taraporewalla e Ian Cartwright.
