O conceito de uso de um service mesh para gerenciar comunicações service-to-service em um cluster começou a ser discutido em 2016, orientado em parte pela adoção de arquiteturas baseadas em microservices, e também pela aceitação do Kubernetes como o maneira prática de orquestrar contêineres.
Os microsserviços trouxeram muitos benefícios, como a capacidade de construir um sistema de serviços "poliglotas" que usava linguagens adequadas para cada tarefa. No entanto, essa tendência arquitetônica também introduziu desafios inerentes a sistemas distribuídos que transferem dados por uma rede não confiável e heterogênea, como a dificuldade de implementar preocupações de comunicação cruzadas anteriormente incluídas na base de código monolítica, como segurança, confiabilidade e observabilidade. A máxima maximização dos microservices de criação de "terminais inteligentes e tubos burros" agora evoluiu, e service meshes estão competindo para colocar inteligência suficiente de volta nos tubos.
Para cooptar o slogan de William Gibson, o futuro dos service meshes já está aqui - e ele não é distribuído de maneira uniforme. O objetivo deste guia é remover parte da confusão e ajudar a escolher se, quando e como implantar um service mesh. Agradecemos qualquer feedback e siga os desenvolvimentos futuros do tema seguindo o tópico no InfoQ.
A eMag do InfoQ - Service Mesh: Passado, Presente e Futuro inclui::
- Linkerd v2: como a adoção em produção serviu de lição para reescrever o Service Mesh – O Linkerd 2.0 introduziu uma grande reescrita de código no service mesh, usando Go e Rust. Neste artigo vamos discutir as lições aprendidas com a adoção em produção, e como essas lições serviram como base para a implementação, design e filosofia do Linkerd 2.x.
- API Gateways e Service Meshes: abrindo a porta para a modernização de aplicações – A modernização de aplicações, separando-as da infraestrutura subjacente na qual estão executando, pode permitir inovação, reduzir custos, e melhorar a segurança. Um API Gateway pode dissociar aplicações de consumidores externos, e um service mesh desacopla as aplicações de consumidores internos.
- É ou não é para multicluster: Comunicação entre clusters usando um service mesh – A comunicação dentro dos clusters Kubernetes é um problema já resolvido, mas a comunicação entre clusters exige mais design e gera sobrecarga operacional. Antes de decidir se vamos ou não implementar um suporte multicluster, devemos entender o caso de uso da comunicação.
- Integração de Aplicações para Arquiteturas em Microservices: Um Service Mesh não é um ESB – Um service mesh destina-se apenas a ser usado como infraestrutura para comunicação entre serviços, e os desenvolvedores não devem criar nenhuma lógica de negócios dentro de um service mesh. Outras estruturas e bibliotecas podem ser usadas para implementar padrões de integração de aplicativos corporativos nativos em nuvem.
- O potencial uso de service mesh na comunicação orientada a eventos – Neste artigo é discutida uma das mais desafiadoras e inexploradas áreas da arquitetura de service mesh; o suporte à comunicação orientada a eventos. Há dois padrões principais discutidos no artigo: O protocol proxy sidecar e o HTTP bridge sidecar. Independentemente do pattern utilizado, o sidecar facilita a implementação de funcionalidades como a observabilidade, rastreamento, etc.
As eMags são uma coletânea de conteúdo popular do InfoQ disponível para download - artigos, entrevistas, apresentações e pesquisas - cobrindo as mais recentes tecnologias, tendências e tópicos de desenvolvimento de software profissional de alta senioridade.