Microsserviços prontos para a produção
Kindle Highlights
Escalabilidade requer simultaneidade e segmentação: duas condições que são difíceis de ser obtidas com um monólito.
Os balanceadores de carga mais comuns para este propósito são o Elastic Load Balancer da Amazon Web Services, o Netflix Eureka, o HAProxy e o Nginx.
todo microsserviço do Uber deveria ser estável, confiável, escalável, tolerante a falhas, de alto desempenho, monitorado, documentado e preparado para qualquer catástrofe.
A camada de comunicação (camada 2) do ecossistema de microsserviços contém: • rede • DNS • Remote Procedure Calls (RPCs) • endpoints • troca de mensagens • descoberta de serviço • registro de serviço • balanceamento de carga
O conceito básico de um microsserviço é simples: ele é uma pequena aplicação que executa uma única tarefa e o faz com eficiência. Um microsserviço é um pequeno componente que pode ser facilmente substituído, e é desenvolvido e implantado de forma independente.
Um microsserviço com endpoints do tipo REST, por exemplo, provavelmente irá interagir com outros microsserviços via HTTP, enquanto um microsserviço com endpoints do tipo Thrift pode se comunicar com outros microsserviços via HTTP ou por meio de uma solução interna mais personalizada.
A escolha do tipo de endpoint é um reflexo do funcionamento interno do próprio microsserviço e também ditará sua arquitetura: é difícil construir um microsserviço assíncrono que se comunique via HTTP usando endpoints do tipo REST, por exemplo, o que levaria à necessidade de adicionar aos serviços um endpoint baseado em troca de mensagens também.
A adoção da arquitetura de microsserviços resolve os desafios mais prementes apresentados pela arquitetura de aplicação monolítica. Os microsserviços não são assolados pelos mesmos desafios de escalabilidade, pela falta de eficiência ou pelas dificuldades de adotar novas tecnologias: eles são otimizados para escalabilidade, eficiência e velocidade de desenvolvimento.
Devido à natureza acelerada do desenvolvimento de um microsserviço, atribuir versões aos microsserviços pode facilmente se tornar um pesadelo organizacional, com os desenvolvedores de serviços para os clientes incorporando versões específicas (obsoletas e sem manutenção) de um microsserviço a seus próprios códigos. Os microsserviços devem ser tratados como coisas vivas e em constante mutação, e não como versões estáticas ou bibliotecas. Atribuir versões aos endpoints de uma API é outro antipadrão que deveria ser evitado pelas mesmas razões.
Empresas pequenas geralmente não têm a infraestrutura necessária em funcionamento para manter microsserviços, mesmo em uma escala muito pequena: uma boa arquitetura de microsserviços requer infraestrutura estável e frequentemente muito complexa. Tal infraestrutura estável requer uma equipe grande e dedicada, cujo custo só pode ser mantido de algum modo por empresas que tenham atingido desafios de escalabilidade que justifiquem a migração para a arquitetura de microsserviços. Empresas pequenas simplesmente não têm capacidade operacional suficiente para manter um ecossistema de microsserviços.