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

Introducing kube-iptables-tailer: Better Networking Visibility in Kubernetes Clusters

Introducing kube-iptables-tailer: Better Networking Visibility in Kubernetes Clusters

At Box, we use Kubernetes to empower our engineers to own the whole lifecycle of their microservices. When it comes to networking, our engineers use Tigera’s Project Calico to declaratively manage network policies for their apps running in our Kubernetes clusters. App owners define a Calico policy in order to enable their Pods to send/receive network traffic, which is instantiated as iptables rules.

Read More
Pod Priority and Preemption in Kubernetes

Pod Priority and Preemption in Kubernetes

Kubernetes is well-known for running scalable workloads. It scales your workloads based on their resource usage. When a workload is scaled up, more instances of the application get created.

Read More
AWS App Mesh

AWS App Mesh

AWS recently released a new service App Mesh during the 2019 summit which has generated a lot of interest from developers world-wide. This service is a great example of how Amazon is highly customer-focused in delivery of products/features to the market. Besides that, there is no additional charge for using the service!:-)

Read More