Venha entender o que é service mesh!
Esse documento foi escrito originalmente em inglês para um job, mas vou aproveitar para colocar aq no blog, se esqueci de traduzir algo me avise ;)
## 1. O que é service Mesh e para que serve isso?
Você provavelmente já ouviu falar sobre isso, e normalmente na mesma frase que alguém cita o tal do "service mesh" geralmente vem junto um "IstIO" ou "Linkerd", ambos implementações bastante populartes desta camada de abstração de rede.
Antes de entrar no modelo de abstração em si, vamos falar de algo realmente importante que permite o uso útil do service mesh, e neste caso, falamos especificamente dos microserviços.
Nos últimos anos essa é outra das buzzwords que tem dominado as conversas nos corredores de TI, mas é bom entender desde já que microserviços e containers não são a mesma coisa não dependem um do outro, contudo, ainda assim, microserviços em containers fazem todo o sentido, tal como juntar o queijo com a goiabada.
Ainda assim, microserviços podem rodar fora de containers, sem nenhum problema.
## 2. Entendendo os microserviços
Essa tendência de migração para microserviços – a qual tem se tornado muito popular na última década, basicamente se refere a decompor ou quebrar grandes monolitos de software em pedaços menores e independentes, chamados então de microserviços.
Pense no seguinte exemplo, imagine uma empresa área que rodava toda sua operação em um grande monolito que fazia tudo de ponta a ponta, contudo, tal monito era igualmente indomávele e difícil de escalar, atualizar, manter e operar. Depois de algum tempo a empresa decidiu decompor o monolito em pedaços menores, separando serviços como pagamento, atendimento do passageiro, atividades dos comissários, atividades dos pilotos, atividades dos mecânicos, venda de passagens, despacho de bagagem e marcação de assentos em pedaços únicos, independentes, que se comunicam entre si, conforme necessidade, utilizando para essa comunicação as API's, geralmente do tipo REST.
Ao decompor esse grande monolito, por um lado, é reduzida a complexidade em alguns pontos, o que facilita a evolução de determinados aspectos do negócio, reduz o risco e acelera a entrega. Além disso, os microserviços permitem que se utilizem técnicas de escalabilidade horizontal, o que faz muito sentido para o universo de containers, clusters de containers e orquestradores de clusters de containers.
Nem sempre redução da complexidade é um benefício bem aceito, muitos defendem que aumenta a complexidade, isso você poderá julgar e formar opinião com o tempo :)
## 3. Vantagens dos microserviços
Podemos ter times específicos e dedicados a manter um determinado serviço do negócio.
Como os componentes são independentes, uma vez definidos padrões de comunicação, interoperação, monitoramento, observação, operação e entrega, cada time tem mais liberdade de escolher a "melhor" STACK para criar e manter o serviço, desde que esta esteja aderente aos "macro" padrões previamente definidos pelos arquitetos.
O custo de operação – a médio e longo prazo - e manutenção tende a ser menor.
A disponibilidade do serviço - a médio e longo prazo – tende a ser maior.
A velocidade de entrega tende a ser muito maior.
O LEAD time (tempo da ideia de uma feature ao momento de entrar produção) tende a ser MUITO menor.
O tempo de recuperação (MTTR) de um incidente ou falha tende a ser menor.
A curva de aprendizado do time que vai manter o software é significantemente menor pois ele vai focar nos padrões definidos e nos requisitos de negócio do serviço de que seu time é responsável.
A atualização se torna mais simples e com menor risco, afinal você não está mudando o monolito inteiro, está mudando apenas a versão de um serviço, e pode inclusive retornar a versão anterior sem grandes e elaborados processos de mudança.
A escalabilidade horizontal passa a ser uma opção, permitindo em momentos de pico de acessos, aumentar o tamanho e a quantidade de microserviços atendendo requisições dos clientes, e após o pico, retornar ao tamanho e oferta normal de atendimento das requisições.
Quem ainda não está rodando nesse modelo, está se preparando para isso, ou já está em transição para ele.
Quem não está rodando nesse modelo, nem no processo de transição, nem se preparando, provavelmente sumirá do mercado em breve – de verdade.
## 4. Nem tudo são flores nos microserviços
O processo de decompor é complexo, necessita de apoio de arquitetos, engenheiros, desenvolvedores, analistas e também de recursos computacionais, financeiros, de aprovações em N níveis, além de um amplo entendimento e também da vontade de todos para fazer a transição funcionar da melhor forma.
Decompor demais também pode ser um problema, é preciso ter equilíbrio ou você gera novamente complexidade devido a imensa quantidade de serviços interconectados, onde, caso ocorra um problema, o nível de abstração aumenta imensamente a complexidade e o alcance do troubleshooting para resolução do problema.
Esse modelo também pode ser bem mais caro – normalmente
é – do que previsto no início – devido a incertezas, contudo, de médio a longo prazo os resultados são muito visíveis, do ponto de vista financeiro, operação e disponibilidade.
Monitoramento e operação também precisam estar afinados com todo o processo, a cultura SRE, DevOps, DevSecOps, GitOps e FinOps trazem experiências e indicam os caminhos e os possíveis percalços, permitindo desviar das estradas ruins, ainda assim, os engenheiros tem que dominar o conceito da infraestrutura como código, infraestrutura imutável, continuous integration, continuous delivery, containerização e orquestração de containers para que quando alguém comite código no lado esquerdo, algo saia rodando lá na ponta do lado direito de forma natural, controlada e com visibilidade plena.
Nesse processo de transição, a segurança tem que estar contida desde o dia zero no mindset de cada desenvolvedor e engenheiro, bem como a exposição de métricas e informações, tudo visando garantir o monitoramento e a observabilidade, bem como a adoção de uma madura cultura de testes que devem ser integrados a esteira.
No final, posso dizer que a transição funciona, está comprovado, tem cases fantásticos, mas não é fácil e não é simples como iniciar um novo projeto já com esses conceitos incutidos, mas dá para fazer, tenha certeza disso.
## 5. Mas oq é esse tal de service mesh afinal?
Service Mesh é basicamente uma camada de infraestrutura criada para controlar a comunicação serviço a serviço em um arquitetura de microserviços.
Ele controla a entrega das requisições para outros serviços, atua como load balancer, pode criptografar dados, descobrir serviços e agregá-los ao load balancer de sua APP.
Apesar de você poder determinar em seu código a lógica de comunicação de seu microserviço, o service mesh atua como uma abstração desta lógica, em uma camada paralela de infraestrutura, dedicada a isso. O funcionamento é bastante simples, ele injeta sidecars proxy em cada serviço.
O sidecar proxy oferece ao controlador mesh os dados do serviço e permite a troca de informações entre os serviços. O controlador service mesh em posse desses dados pode fazer todo o plano de funcionamento e comportamento da aplicação e seus serviços disponíveis. A aplicação de service mesh tem um "control plane" próprio e também oferece uma API que te permite gerenciar o tráfego, resiliência da rede, segurança, autenticação e telemetria de cada serviço.
## 6. Pq eu preciso desse service mesh?
### 6.1. Performance e roteamento
Se você tem uma aplicação que atende uma demanda bastante grande, sendo essa aplicação composta de diversos microserviços se comunicando entre si, o fluxo de comunicação pode se tornar um desafio, uma vez que as requisições entre os serviços podem crescer de forma exponencial, neste caso você provavelmente vai precisar de um roteamento sofisticado e inteligente para manter a comunicação fluindo corretamente, e principalmente para manter a performance dentro dos padrões esperados, evitando degradar a comunicação entre os serviços.
### 6.2. Segurança
Você pode desejar que a comunicação entre os serviços seja segura com TLS mútuo, o que chamamos de mTLS.
### 6.3. Melhorar a sua estratégia DevOps
Permite que os times gerenciem as políticas de segurança e acesso através de código e integre isso nas pipelines CI/CD que entregam o software para o cluster.
## 7. Quais os principais benefícios do service mesh?
### Observabilidade
Normalmente times usam diferentes métodos e tecnologias para manter a visibilidade em relação ao tráfego, log, métricas, tracing e controles de segurança. O service mesh já traz tudo isso de forma centralizada e organizada.
### Resiliência
O service mesh oferece mecanismos como Circuit Breaker, Latency Aware Load Balancing, um descobrimento de serviço bastante consistente e robusto, permitindo ainda configurar retries, timeouts e deadlines nestes serviços.
### Traffic Control & Circuit Breaker
Podemos controlar de forma muito granular o roteamento de tráfego de rede para determinar de forma objetiva por onde as requisições serão roteadas. O circuit breaker permite detectar problemas e definir regras precisas que dizem quando ejetar um POD do load balancer e quando recolocar.
### Security
A maioria dos service meshs oferece um mecanismo CA que gera certificados de forma dinâmica para cada serviço, garantindo uma comunicação segura serviço a serviço.
### Deploy strategies
Quando você precisa utilizar estratégias de deploy como Canary, Blue/Green, Dark Launch e não quer construir essa lógica na sua APP ou preparar isso em infraestrutura do zero.
### Delay, rate control & fault injection
A maioria dos service meshs oferece forma de configurar latência e falhas para simular oq aconteceria no mundo real. Dessa forma você vai verificar qual o comportamento dos seus serviços no caso desse tipo de cenário. É possível também configurar rate limit para um determinado serviço.
### Less code para Devs
Os recursos contidos no service mesh reduzem sensivelmente a quantidade de código que precisa ser produzida pelos devs pois muita coisa já está pronta e disponível nesta camada de abstração que conecta os serviços.
### Less code para Ops
Da mesma forma os OPs não precisam demandar aos Devs formas de coletar métricas, logs, falar sobre retries, timeouts, disponibilidade e performance, pois esse conjunto de informações e configurações já é oferecido nativamente pelo service mesh.
## 8. Quais os principais drawbacks para o cliente e para a operação?
Aumenta a quantidade de pontos de falha - não tem jeito, é mais um componente central que precisa ser considerado, operado, gerido e atualizado.
Os principais projetos relacionados a service MESH estão em constante evolução, muita coisa nova está sendo criada, testada, e vamos navegar nesses mares com muitas coisas novas, atualizações podem ser desafiadores conforme a tecnologia evolui.
Aumenta a complexidade da operação de seu ambiente, pois agora além de pods e réplicas, precisamos pensar no service mesh e sua arquitetura.
A implementação inicial é simples, mas a personalização para as necessidades do clientes requer bastante esforço.
A curva de aprendizado pode ser de média a longo prazo até o time dominar o serviço e sua arquitetura.
O service mesh resolve as coisas dentro de nossa infraestrutura, dentro de nossa operação, contudo ao desacoplar sua APP e iniciar a migração para o modelo microserviços, isso normalmente traz junto a necessidade de implementar um API Gateway, especialmente se você tem um grande número de microserviços a expor para fora da sua infra, isso tem de ser considerado e provavelmente será o próximo passado.
## 8. Quando não usar service mesh?
- Quando você não sabe para que serve
- Quando você não enxerga como isso vai ajudar sua operação
- Quando você não enxerga como isso vai ajudar sua app do ponto de vista de disponibilidade
- Quando você não enxerga como isso vai ajudar sua app do ponto de vista de peformance
- Quando você não enxerga como isso vai ajudar sua estratégia de negócio
- Quando o discovery default do K8S é suficiente para você
- Quando o rollout default do K8S é suficiente para você
- Quando você não tem um grande número de microserviços para gerenciar
- Quando você não tem microserviços, mas acha que tem
- Quando você não tem um fluxo massivo de requisições para lidar
- Quando você não precisa de comunicação segura entre os serviços
## 9. O que vem por aí?
Vamos dar uma olhada a 20 mil metros de altura no Istio e Linkerd e comparar os dois.
## 10. Refs
- https://en.wikipedia.org/wiki/Service_mesh
- https://www.cncf.io/blog/2017/04/26/service-mesh-critical-component-cloud-native-stack/
- https://www.cncf.io/blog/2021/07/15/networking-with-a-service-mesh-use-cases-best-practices-and-comparison-of-top-mesh-options/
- https://www.nginx.com/blog/what-is-a-service-mesh/
- https://buoyant.io/what-is-a-service-mesh
- https://www.dynatrace.com/news/blog/what-is-a-service-mesh/
- https://www.bmc.com/blogs/service-mesh/
- https://glasnostic.com/blog/service-mesh-istio-limits-and-benefits-part-1
- https://glasnostic.com/blog/service-mesh-istio-limits-and-benefits-part-2
- https://www.plugandplaytechcenter.com/resources/what-service-mesh-and-why-should-you-care-about-it
- https://www.limepoint.com/blog/5-reasons-why-you-should-consider-service-mesh
- https://enterprisersproject.com/article/2019/7/service-mesh-how-to-make-case
- https://www.xenonstack.com/insights/what-is-a-service-mesh
- https://www.mulesoft.com/lp/whitepaper/api/service-mesh-api-management
- https://thenewstack.io/when-you-do-and-dont-need-a-service-mesh/
Gostou do conteúdo?
Você também me encontra nessas redes!
Mastodon
@gutocarvalho@bolha.us
PixelFed
@gutocarvalho@bolha.photos
Lemmy
@gutocarvalho@bolha.forum
WriteFreely
@gutocarvalho@bolha.blog
@notamental@bolha.blog
@poesias@bolha.blog
@contos@bolha.blog
Bookwyrm
@gutocarvalho@bolha.review
Peertube
@gutocarvalho@bolha.tube
Friendica
@gutocarvalho@bolha.network
Quer saber mais sobre mim?
Visite meus sites!
E meus blogs:
Conhece o Coletivo Bolha?
Então vem conhecer o bolha.io ou bolhaverso!
- fediverso
- chat
- vídeo
- frontends
- translations
- editors
- secrets sharing
- pastbin
- terminal recorder
- anti paywall
Nós temos muito mais para compartilhar contigo!
Quer apoiar nosso trabalho? Você pode!
Te vejo no mastodon da bolha.us!
[s]
