Microsoft pushed further into the increasingly entertaining service mesh space with its Open Service Mesh (OSM) project that builds on its already established Service Mesh Interface (SMI) initiative. The launch comes just weeks after Google made a controversial hosting decision for its Istio service mesh platform.To get more news about mesh architecture, you can visit boegger.net official website.

Michelle Noorali, a senior software engineer at Microsoft, explained in a blog post that the open source OSM project is designed as a “lightweight and extensible service mesh that runs on Kubernetes.” It provides a control plane that is compatible with the SMI specification, and it taps the widely used Envoy proxy for the data plane.

A service mesh is a dedicated layer for managing, controlling, and monitoring service-to-service communication within an application. The use of a service mesh has become increasingly important for the construction of containers supporting microservice architectures.

OSM allows users to configure traffic shifting for common deployment methods, uses mutual transport layer security (mTLS) to secure service-to-service communication within the microservices environment, and enforces access control policies for services. It also has observing metrics for debugging and monitoring of services, can integrate with native or external certification management platforms, and uses automatic sidecar injection to onboard application onto the mesh environment.

Tom Petrocelli, a research fellow at Amalgam Insights, explained in an email to SDxCentral that the model was interesting in that the OSM “handles all the main service mesh control plane functions while allowing for special needs extensions using the SMI. So, it’s going to be open source, open governance, and open design.”Microsoft did clarify that the special needs extensions mentioned by Petrocelli are “handled by allowing bailout to raw Envoy APIs.”

Microsoft unveiled the SMI project last year. It provides developers with interoperability across different service mesh technologies running on Kubernetes. It does this by defining a set of common, portable APIs that support interoperability across service mesh technologies like Istio, Linkerd, and Consul Connect.

This interoperability remains an important cornerstone for the service mesh space as there has yet to be a platform that has gained a dominate market share.