Hello Service Mesh Interface (SMI): A specification for service mesh interoperability

Hello Service Mesh Interface (SMI): A specification for service mesh interoperability

  • May 21, 2019
Table of Contents

Hello Service Mesh Interface (SMI): A specification for service mesh interoperability

Service Mesh Interface (SMI) defines a set of common, portable APIs that provide developers with interoperability across different service mesh technologies, including Istio, Linkerd, and Consul Connect. Today we are excited to launch Service Mesh Interface (SMI) which defines a set of common, portable APIs that provide developers with interoperability across different service mesh technologies including Istio, Linkerd, and Consul Connect. SMI is an open project started in partnership with Microsoft, Linkerd, HashiCorp, Solo, Kinvolk, and Weaveworks; with support from Aspen Mesh, Canonical, Docker, Pivotal, Rancher, Red Hat, and VMware.

For years, the mantra for network architecture was to keep your network pipes as dumb as possible and build smarts into your applications. The network’s job is to forward packets, while any logic for encryption, compression, or identity lives inside the network endpoints. The Internet is premised on that mantra, so you could say it has worked fairly well.

But today with the explosion of micro-services, containers, and orchestration systems like Kubernetes, engineering teams are faced with securing, managing, and monitoring an increasing number of network endpoints. Service mesh technology provides a solution to this problem by making the network smarter, much smarter. Instead of teaching all your services to encrypt sessions, authorize clients, emit reasonable telemetry, and seamlessly shift traffic between application versions, service mesh technology pushes this logic into the network, controlled by a separate set of management APIs.

Source: microsoft.com

Share :
comments powered by Disqus

Related Posts

Kubernetes Ingress Past, Present, and Future

Kubernetes Ingress Past, Present, and Future

This post was inspired by listening to the February 19, 2019, Kubernetes Podcast, “Ingress, with Tim Hockin.” The Kubernetes Podcast is turning out to be a very well done podcast overall, and well worth the listen. In the Ingress episode, the podcasters interview Tim Hockin who’s one of the original Kubernetes co-founders, a team lead on the Kubernetes predecessor Borg/Omega, and is still very active within the Kubernetes community such as chairing the Kubernetes Network Special Interest Group that currently own the Ingress resource specification.

Read More
AWS App Mesh—Service Mesh for Microservices Running on AWS

AWS App Mesh—Service Mesh for Microservices Running on AWS

The idea of a “service mesh” has become increasingly popular over the last couple of years and the number of alternatives available has risen. There are multiple service mesh open-source projects: Istio, Linkerd, Envoy and Conduit which can be deployed on any Kubernetes environment. The AWS App Mesh can be used with microservices running on Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Container Service for Kubernetes (Amazon EKS), and Kubernetes running on Amazon EC2.

Read More
The Future of Cloud Providers in Kubernetes

The Future of Cloud Providers in Kubernetes

Approximately 9 months ago, the Kubernetes community agreed to form the Cloud Provider Special Interest Group (SIG). The justification was to have a single governing SIG to own and shape the integration points between Kubernetes and the many cloud providers it supported. A lot has been in motion since then and we’re here to share with you what has been accomplished so far and what we hope to see in the future.

Read More