Up until the beginning of this month, life seemed clear. And so did the clear choice for service mesh: Istio. Following on the heels of the Kubernetes acquisition in 2016 by CNCF came the development of Istio by Google, IBM and Lyft, an open source service mesh, and of Envoy by Lyft, an open source edge and service proxy. Together, the three became almost unanimous together, with most other platforms in the cloud native landscape providing support for Istio as the de facto service mesh layer. With its first commit in the open source GitHub repository six years ago by a team from Google, Kuberenetes use today is constantly on the rise and has, for all intents and purposes, become the industry standard for container orchestration. One of the factors that set this in stone was the acquisition of Kubernetes by the Cloud Native Computing Foundation (CNCF) in 2016 as the first official CNCF project accepted to the foundation by its Technical Oversight Committee (TOC)[1]. This was surely also one of the major factors leading to the successful grouping of Kubernetes with Envoy and Istio as the default supported set by most other cloud native platforms as well. In parallel however, it became clear that Istio would face competition, as offerings such as Linkerd, Kuma and HashiCorp Consul Connect were also chosen among many early service mesh adopters. With this, and the fact that some major enterprise vendors had not yet chosen a preferred solution, the service mesh market seemed lacking in an acceptable industry standard and became somewhat fragmented over time. Still, no one was really expecting the market earthquake that was about to happen. Lasts month brought a storm surrounding the current, already divided service mesh landscape. Microsoft announced that it is donating its homegrown service mesh to the CNCF following the surprising decision by Google to donate Istio to its new Open Usage Commons foundation[2]. While some have noted that this could be an advancement towards collaboration around multi-cloud interoperability standards[3], others have raised an eyebrow at the deepened confusion caused for users of Kubernetes that is most likely the direct and most immediate consequence of these changes and additions. Here at Cisco Cloud Native Security Solution, we were surprised as well. So we decided that while we wait to see what happens on the market, and if an industry standard ultimately develops, we’ll share with you our insights about the current options available for network layer 7 protection.

1. https://www.cncf.io/announcement/2016/03/10/cloud-native-computing-foundation-accepts-kubernetes-as-first-hosted-project-technical-oversight-committee-elected/
2. https://thenewstack.io/google-launches-organization-to-protect-trademarks-for-istio-angular-and-other-open-source-projects/
3. https://searchitoperations.techtarget.com/news/252487237/Microsoft-unveils-Open-Service-Mesh-vows-donation-to-CNCF

What is a service mesh?

The service mesh is a networking model that forms an infrastructure layer (layer 7) within your application architecture. The following diagram shows a reference architecture implementation of the entire Kubernetes network, including the positioning of the service mesh.  (A reference architecture for cloud-native enterprise systems; Source: dzone) As part of container application development, users must combine a collection of microservices to create a full application; hence the need for a security mesh. The service mesh is made up of a data plane, which contains the proxies that manage network traffic, and a control plane. The service mesh enables centralized communication for the multiple microservices that teams manage, rather than needing to monitor each individual service separately. The control plane component enables this centralization. Users configure, control and manage the service mesh from the control plane, used to generate and deploy the configuration, as can be seen in the following diagram:  (The control plane in a service mesh distributes configuration across the sidecar proxies in the data plane; Source: NGINX) The control plane also tracks and records interactions between objects. The proxies are at the center of the architecture (also in the above illustration), performing core tasks:

• communication between services
• delivery of application services
• monitoring of the constantly-changing state of service instances
• spreading the load across the dynamic service mesh layer

These proxies, that together make up a service mesh, are sometimes called “sidecars” because they are executed in parallel to, and not within, each service, with the most well-known sidecar being Envoy. The service mesh manages service-to-service communication in the network, enabling communications between pods, preventing illegitimate communications by isolating pods (microservices) from each other, tracking performance metrics, and helping users create more efficient and reliable service requests. It delivers vital application services such as load balancing, traffic management, routing, health monitoring, and security capabilities. These security capabilities include monitoring, encryption of service-to-service communication (mutual TLS), circuit breakers, fault injection, and service and user authentication, and protection against intrusion and DDoS attacks. For more reading about the service mesh as a network layer 7 security component, check out our posts.

A little extra info about Istio

Like we noted at the beginning of this post, up until recently almost every major software vendor has prioritized an Istio solution or integration over those of other alternative service meshes[1]. Furthermore, the Istio open source community far surpasses any others in terms of activity and contributions[2]. These, and the fact that the solution is backed by the giants Google, IBM and Lyft, means that even in light of the introduction of Microsoft’s competing platform, Istio is and will most likely continue to be a leading option on the market – at least for the time being. In fact, the 2019 CNCF survey reported that the majority of users had implemented Istio, and those running evaluations were considering Istio as one of their top options. Istio has proven to be complex, which may be the biggest differentiator for Microsoft. At the same time, so far it seems that this learning curve has yet to stop Istio adoption, though this could also simply be attributed to the number of supporting vendors who offer Istio integrations before any other, forcing users to take the leap. Indeed, there’s a very strong ecosystem surrounding Istio deployment, and this makes adoption of Istio an advantage over other options. “We want Istio to be like Kubernetes — ‘boring’ infrastructure for microservices,” said Lin Sun, IBM’s technical lead for Istio. “That’s our high-priority goal for 2020: To be able to move services to service mesh faster without [requiring] as many configuration changes to microservices.” obstacle to widespread Istio adoption is a major architectural change introduced in version 1.5 earlier this year[3]. With the introduction of Istio v1.5, the solution seems to promise a slightly smaller gap to overcome with a single centralized control plane offering as part of a monolithic architecture, a move from their former distributed microservices architecture. The feature, coined Istiod, still has a way to go before being accepted by the industry with high expectations for the release of v1.6, along with continued advancements related to Envoy developments.

1. https://thenewstack.io/the-top-3-service-mesh-developments-in-2020/
2. https://github.com/istio/istio
3. https://windowsadmins.com/istio-service-mesh-revamp-may-ease-use-or-sow-confusion/

Microsoft OSM, industry standards and SMI

Microsoft has released (in alpha) the open service mesh (OSM), is a service mesh implementation that complies with the SMI specification. OSM offers the standard service mesh technology features such as canary releases, secure communication, and application insights, similar to other service mesh implementations like Istio. OSM implements the service mesh interface (SMI), which is a set of standard APIs used to deploy a service mesh in Kubernetes. In the alpha release, OSM offers traffic shifting policies, secure mTLS communication within services, granular access control policies, application metrics, external certificate managers, and sidecar Envoy proxy injection automatically. OSM uses Envoy as a sidecar proxy to communicate with other services in the mesh, and it also allows any service discovery protocol reverse-proxy compatibility in order to also employ advanced Envoy features. When a user creates a pod, OSM catches the API with a mutating webhook, and then injects it with the Envoy sidecar proxy. An init container from OSM then uses iptables to ensure that all the traffic flows through Envoy. OSM handles access control rules, routing policies, encrypts communication, and collects metrics that, by default, can be seen in Grafana and Zipkin.  (Traffic Access Control Illustration — SMI; Source: itnext.io)

OSM vs. Istio

Table: Service mesh platform comparison matrix

Conclusions

Already last year, GlobeNewswire report joined the analysts and experts in noting just how confusing all of this seems to be for users. Going back to the 2019 CNCF survey, it seems Istio is indeed still the current leading option. At the same time, all that might change given the wide implementation of HashiCorp Consul Connect, the fierce competition Linkerd has put up so far, and also given the addition of OSM to the list, not to mention a handful of up and coming stars. At Cisco Cloud Native Security Solution, we’re aware of how confusing this can be too. So we’ve put together this comparison to try and give you a helping hand in choosing the mesh that’s right for you. Cisco Cloud Native Security Solution works with the service mesh layer of your Kubernetes cluster, to implement runtime policy management. Today, you can deploy our solution on a cluster already running the Istio mesh, or on a cluster without it. Cisco Cloud Native Security Solution deploys and continually updates the Istio service mesh to connect, manage and secure the traffic between your microservices. We delivers a simple, intuitive policy advisor that leverages Istio to encrypt the communication between your microservices. In addition to the Istio support, Cisco Cloud Native Security Solution aims to be an agnostic security tool designed for any Kubernetes implementation. As such, we’ve got other options in our integration roadmap and we plan on keeping you updated as we release them.