# envoy-proxy Published articles for envoy-proxy. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## The Road to an Envoy Service Mesh DevFeed: [The Road to an Envoy Service Mesh]() Original publisher: [Read original article]() Author: Snow Pettersen Published: 2019-03-29T15:36:51Z Content type: article Language: en Sources: [Square Corner Blog]() Topics: [microservices architecture](), [Architecture & Design](), [interoperability](), [Remote Procedure Call (RPC)](), [Go Language](), [Java](), [Ruby](), [Ruby on Rails](), [gRPC](), [Code]() Tags: [architecture](), [automatic](), [discovery](), [engineering](), [envoy-proxy](), [failover](), [go](), [http](), [interoperability](), [java](), [microservices](), [microservices-architecture](), [routing](), [rpc](), [ruby](), [service-mesh]() ### AI overview Square describes its evolution from a Ruby on Rails monolith to a microservices architecture and explains the interoperability challenges created by its Java, Ruby, and Go stack. The article outlines its Protobuf-based Sake RPC framework, its routing, failover, traffic-shaping, and service-discovery features, and Square's migration toward a full service mesh. ### Source excerpt Heads up, we've moved! If you'd like to continue keeping up with the latest technical content from Square please visit us at our new home https://developer.squareup.com/blog At Square we've been running a microservices architecture for years, primarily using three different languages: Java, Ruby and Go. Running such a diverse stack can make interoperability between the different languages/frameworks challenging, and in this post I'll talk about how Square has handled this in the past and where we're at today -- actively migrating towards a full service mesh. The Old World Square started off, like many other companies, just running one large monolith. For Square this was a big Ruby on Rails service, that handled everything that Square did. A monolith makes service to service communication completely unnecessary: everything runs in the same code base on a single database, so everything can be implemented without making any outbound network calls (except to third parties outside of Square). After a while, Square decided to move more towards a service oriented architecture to reduce the reliance on a single, large application. To do this Square decided to build their own Protobuf based RPC framework, inspired by Google's Stubby. This was years before gRPC was created, so there weren't any open source options at the time. This RPC framework, called Sake, was implemented for Java and Go as these were the languages used for higher availability services, while regular REST HTTP was used between services that didn't understand Sake. (Incidentally, Sake became a part of gRPC's DNA) Over time this framework became fairly sophisticated, with many features not generally available: Smart retries with automatic failover Prioritized routing based on upstream health Traffic shaping and service discovery This ended up working well, but relied on fat client/server libraries, so extending support to other languages was hard. Attempts were made to bring feature parity between languages i ## Keycloak and Istio DevFeed: [Keycloak and Istio]() Original publisher: [Read original article]() Author: Sébastien Blanc Published: 2018-02-26T00:00:00Z Content type: tutorial Language: en Sources: [Keycloak Blog]() Topics: [istio](), [Keycloak](), [JSON Web Tokens](), [Architecture & Design](), [proxy]() Tags: [envoy-proxy](), [http](), [idm](), [istio](), [jwt](), [kerberos](), [keycloak](), [ldap](), [load-balancing](), [openid-connect](), [proxy](), [saml](), [service-mesh](), [sso]() ### AI overview This short blog post describes early trials of combining Keycloak with Istio. It explains how Istio's Envoy sidecar and JWT authentication filter can take over some security tasks traditionally handled by Keycloak adapters, while noting that the replacement is not yet complete. ### Source excerpt This short blog post is to share the first trials of combining Keycloak with Istio. What is Istio? Istio is an platform that provides a common way to manage your service mesh. You may wonder what a service mesh is, well, it's an infrastructure layer dedicated to connect, secure and make reliable your different services. Istio, in the end, will be replacing all of our circuit-breakers, intelligent load balancing or metrics librairies, but also the way how two services will communicate in a secure way. And this is of course the interesting part for Keycloak. As you know Keycloak uses adapters for each of the application or service that it secures. These adapters make sure to perform the redirect if needed, to retrieve the public keys, to verify the JWT signature etc ... There are a lot of different adapters depending on the type of application or technology that is used : there are Java EE adapters, JavaScript adapters and we even have a NodeJS adapter. The end of the adapters? Following the Istio philosophy, these adapters would not be needed in the end because the Istio infrastructure will take care of the tasks the adapters were doing (signature verification etc ...). We are not yet there for now but in this post we will see what can already be done with Istio and how much it already can replace the role of the Adapters. The Envoy Sidecar We won't dive into the details on how Istio works but there is one main concept to understand around which Istio is articulated : the Envoy Sidecar. Envoy is a high performance proxy deployed alongside with each deployed service and this is the reason we call it a "sidecar". Envoy captures all incoming and outgoing traffic of its "companion" service, it can then apply some basic operations and also collect data and send it to a central point of decision, called the "mixer" in Istio. The conifugration of Envoy itself happens through the "pilot" an other Istio component. Envoy Filters To make it easier to add new functionnality to t