As the recent 2022 CNCF Cloud Native User-Survey highlighted, more companies are using Kubernetes than ever before. It’s being used in every industry and every region of the world, and the list of use cases continues to grow. And as we’ve seen from working with Solo.io’s customers, success in using Kubernetes tends to drive certain new behaviors and challenges.

• Cluster Sprawl: Many companies begin by using a large, centralized cluster because it aligns to existing IT patterns of centralized architecture and control. But over time, as application teams get more familiar with Kubernetes, they begin to request their own clusters. This eventually leads to both cluster sprawl and the challenges of multi-cluster communications.
• Inconsistent Operations and Security: As the number of clusters grows, it can become more difficult to deploy consistent best practices across clusters, and to learn and share best practices between teams. This is where deterministic operational models such as GitOps become critical to the success of growing the Kubernetes footprint.
• Multi-Kubernetes and Multi-Cloud: While many organizations may begin their Kubernetes journey on-premises, most eventually begin to find use cases that are better served by using Kubernetes in the public cloud. And just like the cluster sprawl challenge we mentioned above, the Kubernetes choice challenge arises when teams move to the public cloud. This is when they make their own independent decision about which Kubernetes to use in the cloud (e.g. Rancher, GKE, AKS, EKS, OpenShift), and oftentimes it will be different from what’s being used on-premises. While this may simplify operations and reduce costs, it can also create a consistency challenge for teams having to operate the clusters or share best practices.
• Efficiently Managing Microservices: Once teams begin deploying more applications onto Kubernetes, especially microservices-based containers, they often struggle to manage the new complexities that come from distributed applications. How to manage service discovery and connectivity? How to manage security between services? How to reach application services that are outside the local cluster?

As these challenges arise, many teams begin exploring the capabilities of a service mesh to try to bring order to what has often become a chaotic situation. The good news is that service mesh can bring value to each of the challenges listed above. The bad news is some teams may look at the breadth of capabilities that a service mesh can offer and feel overwhelmed. Do they need all the features? Will it fit into their existing operational model? How will it adapt to multi-cluster or multi-cloud environments, especially if different Kubernetes are being used?

Most people in technology are used to making tradeoffs. Product managers will often say, “Price, features or time-to-market….pick 2”. Database teams are familiar with CAP theorem, where they have to choose a database technology based on a priority of consistency, availability or partition tolerance….again, pick 2.

Luckily in the service mesh world, technologists aren’t faced with such a harsh set of choices. Service mesh can deliver speed, security, consistency, and observability without having to sacrifice any of them. And while they may not all be needed for every application, or by every team, technologies like Istio allow granular control over how those capabilities can be deployed to manage applications and APIs.

Speed: Istio can be used with a wide variety of computing platforms and network plugins (CNIs). Whether you need to use very large x86-based compute instances, or want to leverage the price/performance tradeoffs of ARM, Istio and Envoy Proxy can take advantage of any environment. And if you need to speed up network performance, eBPF-based CNI plugins can accelerate throughputs and reduce latency.

Security: Once an application team decides to start building microservices, they also have to figure out how to secure the communications between each service. This requires authentication of discovered services, but also authorization of service-to-service communication and managing of encryption keys to encrypt the service-to-service traffic (e.g. mTLS). This is another area where Istio can manage service discovery, authentication, authorization, key-management, and traffic encryption. It can also manage traffic termination and origination for advanced HTTPS and Layer 3 applications.

Consistency: While there are many choices for Kubernetes, both on-premises and in the public cloud, there are often nuances in how they work. Istio service mesh can help deliver consistent operations, security and observability across any Kubernetes. This allows application teams to stay focused on building new microservices to drive business growth. In addition, Istio allows DevOps teams to continue to use the GitOps tools and processes that they are already using to deploy Kubernetes clusters and applications.

Observability: Troubleshooting distributed applications can be challenging, especially if the observability tools can’t get close enough to the application traffic. Istio’s sidecar architecture allows observability tools to be co-located with the containerized applications, making it easy for applications and operations teams to identify latency problems, troubleshoot errors, and introduce ways to manage canary or blue-green deployment patterns.

As platform teams become responsible for the breadth of networking, security, and application needs of their Kubernetes environments, Istio service mesh can quickly become a very valuable layer in their platform stack. By enabling connectivity and performance, security, consistency, and observability, the service mesh allows different parts of the team to have the right tool for their daily tasks.

If you’d like to learn more about Istio, Envoy Proxy, or other technologies to help connect, secure, and observe modern applications and APIs, check out the free hands-on training, webinars, workshops, and certifications at Solo Academy.