Innovation and Changes in the Service Mesh Landscape — an Invitation to SoloCon – InApps is an article under the topic Software Development Many of you are most interested in today !! Today, let’s InApps.net learn Innovation and Changes in the Service Mesh Landscape — an Invitation to SoloCon – InApps in today’s post !
Read more about Innovation and Changes in the Service Mesh Landscape — an Invitation to SoloCon – InApps at Wikipedia
Idit is the founder and CEO of Solo.io. She is a former CTO for the cloud management division at EMC and was a member of its Global CTO office, where she focused on management and orchestration (M&O) over the entire stack, microservices, cloud native apps, and platforms as a service. Idit has been recognized as a leading contributor to a variety of cloud open source projects, and is an expert in cluster management (Kubernetes, Mesos and DockerSwam).
At Solo.io, we have been focused on managing and orchestrating service meshes at scale since we launched SuperGloo — an opinionated abstraction layer and the ancestor of Gloo Mesh — in late 2018. Since then we have understood the importance of service mesh in the microservices architecture, especially with Kubernetes.
Fast forward more than two years and we have seen a lot of innovation and changes in the service mesh landscape. Here are some observations about the past few years and predictions for the near future.
1. Istio is becoming the de-facto service mesh, as Istio and Kubernetes are moving closer together.
Many years ago, there was a debate on which container standard would become the de-facto standard. Today, it is clear that Kubernetes was the winner. I also see this debate playing out with service mesh. There are a lot of open source projects, but based on discussions with our many customers, I think that Istio is becoming the de-facto standard. So I expect it will soon dominate the cloud native landscape.
There is also a “symbiosis” between Istio and Kubernetes. Istio has been adopting Kubernetes service APIs to replace its existing networking API. The Kubernetes service APIs are designed to help users transition smoothly from Kubernetes to any service mesh which implements them, so we expect Istio’s move to further increase its adoption.
2. Istio can readily be extended with enterprise-grade features at the edge.
Many of our customers started working with Istio’s built-in ingress but eventually found that they needed advanced security features — such as WAF and DLP, request and response transformation, advanced external auth, sophisticated rate limiting, and more. Fortunately, Istio’s architecture provides ample opportunities to extend it with all these features and thus transform it into an enterprise-grade API gateway.
3. Web Assembly extensibility will be a game-changer for Istio.
I cannot overemphasize the importance of being able to tailor Istio to a customer’s specific needs. WebAssembly (Wasm) is a fast, efficient, portable binary instruction format, providing an embeddable and safe execution environment for platform extensions. With Wasm, users can write (in any language) modules that extend their service mesh proxy in a way that best fits their needs. I think that in the near future Wasm will become the technology of choice for dynamically extending cloud native applications, with Istio leading the way.
4. The service mesh environment can quickly become complex.
Taking the first steps with a service mesh can be challenging, as it requires attention to traffic management, policies, security and observability. Once these basics are understood, users are ready to deploy the service mesh in their multicluster environment. This raises a new set of challenges, however, including the coordination between multiple instances of the service mesh. In such cases, it is important to have the tools and policies to simplify and unify the configuration, operation and visibility across clusters.
5. All the right ingredients, but can you assemble them correctly?
Istio has many powerful security features for protecting your applications from malicious actors inside and outside of your network. Organizations rely on Istio features to meet various compliance standards designed for the protection of sensitive data environments. These include encryption, authentication, authorization, monitoring tools, and control of ingress and egress traffic. Unfortunately, enabling and using these features is not as simple as clicking a checkbox. Configuring these policies correctly — especially across multiple clusters — requires a deeper understanding of default behaviors, installation settings and the Istio CRDs, as well as debugging Envoy configurations. Failure to configure properly can result in data breaches or unintended behaviors.
Join Us at SoloCon for More Service Mesh Discussions
The new developments in the service mesh space — and especially those within the Istio community — elevate my enthusiasm and faith in this architecture. This is why we at Solo.io remain committed and active members of the Istio community. We are committed to helping enterprise customers adopt and operate their service mesh with advice and support, and with our Gloo Mesh platform.
This is also the goal of the upcoming SoloCon, where we, our customers and our open source community will share our experiences with Istio. If you would like to learn more about Istio, the trends shaping the service mesh community, and how Gloo Mesh is designed to help you in your service mesh journey, I invite you to join us at SoloCon on March 23-25. The conference is designed to provide education on Istio, service mesh, edge gateway and many topics in between.
Let’s create the next big thing together!
Coming together is a beginning. Keeping together is progress. Working together is success.