Artigos
5
min de leitura
8 de setembro de 2020

Service Mesh é um elemento essencial para as aplicações empresariais modernas - aqui está o porquê

Gibson Pasquini Nascimento
Head of Solutions, EMEA
Com sede em Dublin. Com mais de 14 anos de experiência em Software Desenvolvimento, Metodologias Ágeis e Arquitetura. Sou especialista em APIs e já trabalhei em vários setores (Varejo, Farmacêutico, Seguros de Saúde, Bancos e alguns outros) para apoiar a mudança da abordagem de integração e da estratégia API.
Mais sobre o autor

Originalmente publicado em Computing.co.

Clique aqui para verificar

As aplicações nativas das nuvens são coleções de serviços fracamente acopladas - e alguém precisa manter os canais de comunicação abertos. Entre no service mesh

Um service mesh é cada vez mais visto como um elemento essencial para as organizações que desejam monitorar, gerenciar e controlar suas comunicações de serviço a serviço. Um componente crítico da pilha nativa da nuvem, este modelo de rede (também descrito como uma camada de infraestrutura) melhora online a capacidade de resposta, o desempenho e a confiabilidade. Ele permite, entre outras capacidades, a comunicação entre serviços complexos que suportam aplicações modernas e nativas das nuvens.

Em tais aplicações, pode haver centenas de serviços com milhares de variações que mudam constantemente quando orquestrados em uma plataforma como a Kubernetes. Um service mesh usa ferramentas de roteamento dinâmico para se conectar ao serviço correto e encontrar a fonte de informação que, historicamente, tem fornecido a resposta mais rápida. Se essa fonte não responde, o service mesh encontra outra fonte; se um erro é retornado, ele remove a fonte do pool de balanceamento. Se o prazo de solicitação não for cumprido, ele registra uma "solicitação falhada" em vez de loading o sistema com mais tentativas, impedindo que ele caia.

Ao automatizar a comunicação entre as diferentes partes da aplicação, um service mesh melhora o tempo de atividade, o desempenho e a resiliência da aplicação como um todo.

Evolução do service mesh

Então como esta ferramenta, que usa aplicações web para gerenciar as comunicações de serviço a serviço, evoluiu?

Em 1992, um dos primeiros modelos de arquitetura software (ainda amplamente utilizado hoje), foi o modelo Model View Controller (MVC). Mudanças nos padrões de distribuição resultaram em Arquitetura Orientada a Serviços (SOA) em 2000 e em event-driven architecture em 2003. Dez anos depois, quando o desenvolvimento de software exigiu soluções mais robustas e escaláveis, Microsserviços chegou, seguido por plataformas sem servidores em 2015.

No entanto, ainda havia uma tendência a desenvolver aplicações orientadas por processos que espelhavam as estruturas de comunicação existentes das organizações baseadas em silos. É verdade que o software foi dividido em pedaços menores (o indivíduo Microsserviços), mas também havia mais dele distribuído por mais sistemas. Estes pedaços menores de software e a comunicação entre eles são mais complexos de manusear, que é onde entra service meshes .

Um service mesh funciona apoiando a comunicação inter-processo (IPC) - o mecanismo que um sistema operacional utiliza para gerenciar e compartilhar dados.

Ela aborda todos os problemas de rede que os desenvolvedores normalmente têm que considerar ao implementar um microserviço, por exemplo, balanceamento de carga, disjuntores, novas tentativas, time-outs e roteamento inteligente, e permite técnicas avançadas de implementação, tais como canário releases e lançamentos escuros. Ao fazer isso, um service mesh nega a necessidade de codificação de aplicativos de infra-estrutura, dando aos desenvolvedores mais tempo para se concentrarem na lógica comercial.

A telemetria é outra característica do service meshe; a atividade é observada e registrada através de métricas e carregada em um banco de dados central. Algumas soluções service mesh integram-se com as ferramentas de monitoramento software, e também podem substituir as bibliotecas de comunicação normalmente usadas para lidar com balanceamento de carga, latência, tolerância a falhas e problemas de rede de failover.

Norte, Sul, Leste, Oeste

Embora service meshe seja perfeito para lidar com a comunicação muitas vezes complexa e variada serviço a serviço (também conhecida como tráfego leste-oeste), as solicitações originadas de redes externas, por consumidores de APIs expostas (tráfego norte-sul), devem ser gerenciadas por um API gateway. Este último fornece a segurança necessária, o controle de acesso e as capacidades de governança para proteger a infra-estrutura interna.

Não há bala de prata para tratar de todas as questões tecnológicas das organizações, mas software arquitetos e desenvolvedores têm agora acesso a novas ferramentas para apoiar o ciclo de vida do desenvolvimento software .

E à medida que mais empresas migrarem para uma arquitetura Microsserviços , organizando seu software em torno de suas capacidades em vez de silos orientados por processos, service meshes será cada vez mais necessário para ajudar as aplicações a evoluir de acordo com o crescimento dos negócios.

Obrigado pela leitura!