A malha de serviços é uma abordagem para operar um ecossistema de microsserviços seguro, rápido e confiável. Ela tem sido um importante passo para facilitar a adoção de microsserviços em escala. Oferece descoberta, segurança, rastreamento, monitoramento e processamento de falhas. Fornece recursos interfuncionais sem a necessidade de um ativo compartilhado, como uma API gateway ou bibliotecas baking em cada serviço. Uma implementação típica envolve processos de proxy reversos leves, também conhecidos como sidecars, implementados junto com cada processo de serviço em um contêiner separado. Os sidecars interceptam o tráfego de entrada e saída de cada serviço e fornecem os recursos interfuncionais mencionados acima. Essa abordagem aliviou os times de serviços distribuídos de construir e atualizar os recursos que a malha oferece como código em seus serviços. Isso levou a uma adoção ainda mais fácil da programação poliglota em um ecossistema de microsserviços. Nossos times têm usado essa abordagem com sucesso em projetos de código aberto, como Istio, e continuaremos a monitorar outras implementações abertas de malha de serviços, como Linkerd, de perto.
As large organizations transition to more autonomous teams owning and operating their own microservices, how can they ensure the necessary consistency and compatibility between those services without relying on a centralized hosting infrastructure? To work together efficiently, even autonomous microservices need to align with some organizational standards. A service mesh offers consistent discovery, security, tracing, monitoring and failure handling without the need for a shared asset such as an API gateway or ESB. A typical implementation involves lightweight reverse-proxy processes deployed alongside each service process, perhaps in a separate container. These proxies communicate with service registries, identity providers, log aggregators and other services. Service interoperability and observability are gained through a shared implementation of this proxy but not a shared runtime instance. We've advocated for a decentralized approach to microservices management for some time and are happy to see this consistent pattern emerge. Open source projects such as Linkerd and Istio will continue to mature and make service meshes even easier to implement.
As large organizations transition to more autonomous teams owning and operating their own microservices, how can they ensure the necessary consistency and compatibility between those services without relying on a centralized hosting infrastructure? To work together efficiently, even autonomous microservices need to align with some organizational standards. A service mesh offers consistent discovery, security, tracing, monitoring and failure handling without the need for a shared asset such as an API gateway or ESB. A typical implementation involves lightweight reverse-proxy processes deployed alongside each service process, perhaps in a separate container. These proxies communicate with service registries, identity providers, log aggregators, and so on. Service interoperability and observability are gained through a shared implementation of this proxy but not a shared runtime instance. We've advocated for a decentralized approach to microservice management for some time and are happy to see this consistent pattern emerge. Open source projects such as linkerd and Istio will continue to mature and make service meshes even easier to implement.
As large organizations transition to more autonomous teams owning and operating their own microservices, how can they ensure the necessary consistency and compatibility between those services without relying on a centralized hosting infrastructure? To work together efficiently, even autonomous microservices need to align with some organizational standards. A service mesh offers consistent discovery, security, tracing, monitoring and failure handling without the need for a shared asset such as an API gateway or ESB. A typical implementation involves lightweight reverse-proxy processes deployed alongside each service process, perhaps in a separate container. These proxies communicate with service registries, identity providers, log aggregators, and so on. Service interoperability and observability are gained through a shared implementation of this proxy but not a shared runtime instance. We've advocated for a decentralized approach to microservice management for some time and are happy to see this consistent pattern emerge. Open source projects such as linkerd and Istio will continue to mature and make service meshes even easier to implement.
