Istio Ambient Mesh for Beginners
In my recent talk, I tried to clarify the basic concepts of Istio in a way that beginners can understand. In this post, we'll look at the issues sidecar mode poses and how Istio Ambient Mesh creatively solves them by minimizing the use of proxies, simplifying scalability, and maintaining security. Let's figure it out.
Service Mesh as we know it today
In today's world, mobile phones have become ubiquitous, virtually the epicenter of our daily lives. We use our mobile phones to communicate, be it through messaging apps like WhatsApp and Twitter or traditional phone calls.
Some people have a curious habit of asking, “Where are you?” when calling. However, in most cases this is not the main purpose of our call, is it? This is just a common question. Our calls or messages often serve different purposes, and knowing the exact location of the interlocutor is not so important.
Consider international calls: they involve dialing a universal number format, which provides secure, encrypted communication that cannot be intercepted. Our phones contain a wealth of statistics, from call recordings to app usage and consumption data. They even allow us to block unwanted callers.
Given that we rely heavily on mobile phones and their standardized, user-friendly approach, why haven't we applied a similar philosophy to the many services running on our systems? Shouldn't we adopt a similar strategy for our digital services?
And that's essentially what it is Service Mesh. Instead of a mobile phone that the person owns, it is a proxy next to the application. In Kubernetes, since the proxy is deployed as a sidecar, this architecture is called sidecar mode.
Ambient Mesh, Concept
Now that we understand what can be called a Service Mesh based on mobile phones, let's take the discussion to a higher level.
Imagine that you are in the office and holding a meeting with remote colleagues. You and your local team gather in a conference room.
Given that we mostly communicate through our cell phones, does it seem logical for each person, including your teammates, to use their own separate cell phones in the meeting room? Or would it be more efficient to place a central speaker in the room, allowing everyone to use one device? Security concerns are reduced by physically enclosing the conference room.
This, in theory, is the essence of Ambient Mesh: a service mesh rearchitecture aimed at minimizing the number of proxies, simplifying scaling, and maintaining the level of security that sidecar mode provided. In Kubernetes, because this architecture doesn't force you to deploy a proxy for each pod, it's called sidecarless regime.
Inside the conference room, the walls form a secure perimeter, allowing for open communication. In a Kubernetes realm, a secure perimeter can be defined by two elements:
A cluster node that groups applications on one node, so encrypting this data exchange becomes pointless.
ServiceAccount, which groups multiple pods representing a service with multiple replicas of a single pod. This makes deploying a per-replica proxy ineffective.
By now you have already understood what the main advantage of the sidecarless approach is compared to the sidecar mode. However, that's not all. Over the years, as the community tested sidecar mode, certain issues arose that forced us to rethink the architecture.
3 main problems associated with sidecar mode
To demonstrate the advantages of sidecarless (ambient mesh) mode over sidecar (service mesh) mode as we know it today, let's look at these issues:
Resource consumption
One of the main issues with sidecar mode is resource consumption, and this issue is often raised by users exploring Service Mesh such as Istio.
To understand why this happens, you need to understand the origins of the Service Mesh. Initially, platforms like Netflix provided libraries (Hystrix, Zuul, Ribbon, etc.) for integration into applications at the build stage.
These libraries solved critical problems such as authentication, authorization, security, routing, service discovery, and observability. At first, everything worked within one application.
However, with the advent of cloud native approaches and Kubernetes, this paradigm has shifted towards the sidecar pattern. Instead of building these tasks into every application, they were added as sidecar proxies, located next to the application in the Kubernetes environment.
As a result, each pod now deploys its own proxy, which leads to a noticeable increase in resource consumption.
Expected vs. actual results
One of the main problems with Istio's sidecar mode is culture. Historically, there has been a bitter struggle between developers (devs) and operators (ops). You can often hear: “This is not my code, this is your machine.”
DevOps attempted to bridge this gap by bridging the two worlds, but it required a culture change that many businesses resisted. In large companies, change occurs more slowly. So even if they claimed to be “DevOps”, they often did not create fully end-to-end teams, which is a critical requirement of DevOps.
Now, with the advent of Service Mesh and sidecar architectures, this battle is heating up again. Typically, developers prefer to code rather than learn Kubernetes, which is typically managed by the operations (Ops) department. Ops creates simple YAML files for developers to deploy their applications to Kubernetes.
When you deploy exclusively to Kubernetes, everything contained in the YAML is deployed. If an application has one container, the developer sees only that container.
But in sidecar mode, when a developer deploys an application, he sees his application containers and two more: Istio and Istio-init. Quietly, Istio introduces its proxies and initiators.
The developer does not need to understand the intricacies of Istio. However, if his application crashes, he may suspect that this additional application is somehow conflicting.
For example, a user encounters a problem when an application uses port 15006. Without Istio, it worked fine in Kubernetes, but with Istio, it crashes because this port is reserved for proxies and cannot be changed.
Making changes to the proxy entails redeploying applications
A third intriguing challenge relates to Day-2 operations. In sidecar mode, the architecture combines the development lifecycles of two components: the application and the proxy, since they share the same pod.
When a new version of the application is deployed, the proxy in the same pod is also restarted. This is not a major problem since the changes occur in the application and not in the proxy.
The problem occurs when the proxy server needs to be updated. In such cases, the operations (Ops) team must ensure a smooth shutdown of the pod.
Although we live in a world of cloud native applications, not all applications on Kubernetes are 12-factor rules defining cloud native applications.
Factor number 9 in these rules relates to the startup and smooth shutdown of a 12-factor application:
IX. Recyclability
Maximize reliability with fast startup and graceful shutdown
12 Factor processes are recyclable, meaning they can be started or stopped at any time. This enables fast elastic scaling, rapid deployment of code or configuration changes, and robustness of production deployments.
For applications that are not 12-factor compliant, deploying a proxy may cause performance issues.
Why sidecarless architecture is needed
The main problems and difficulties are related to the sidecar pattern used in current Service Mesh implementations, which hinders the development and widespread adoption of Service Mesh.
To better understand the new architecture, let's go back to the era of object-oriented programming and SOLID principles. Many architects were once developers, and they applied the lessons learned from monolithic functionality design to design microservices-based solutions. One of the key principles is the single responsibility principle, which Martin Fowler defined as: “A class or module should have one, and only one, reason for changing.”
Applying this principle to our microservices-based solution, Service Mesh, raises questions. Why do we need to update the Layer 4 proxy (responsible for encryption, security, zero trust, etc.) if we are only changing Layer 7 functionality, such as authentication?
The logical conclusion is to separate Layer 4 proxies and Layer 7 proxies. The Layer 4 proxy serves as the foundation and goes through a separate development lifecycle compared to the Layer 7 proxy.
A Layer 7 proxy is created on demand and covers a group of workloads with the same level of security, typically based on a service account. Instead of having one proxy for each application replica, you have a proxy that scales differently to meet specific application needs.
Problem solving
Now let's evaluate how effectively this architecture solves the previously listed problems:
Resource consumption: In the worst-case scenario, we see a significant reduction in the number of deployed proxies compared to sidecar mode. Moreover, as applications scale, proxies no longer scale with them.
Expected results: By deploying Istio components separately, developers can work without the confusion caused by implementing Istio containers into their applications. This clarity in YAML files promotes better understanding and collaboration, eliminating conflict between developers and operators.
Updating Proxy and Deploying Applications: Separating applications from components Istio allows for different development life cycles. Therefore, changes to the proxy no longer require a redeployment of the entire application stack.
Final Thoughts
Ambient or sidecarless mode solved not only these three problems, but also brought significant innovation.
The complete separation of the two proxies led to the revolutionary development of Layer 4 proxies.
It now no longer relies on Envoy and its C programming language. Instead, the Layer 4 proxy is built using Rust, which provides superior performance. In addition, the libraries used in the proxy have been thoroughly tested in other products, demonstrating their reliability, which makes the additional latency of the Service Mesh almost negligible.
In conclusion, Istio Ambient Mesh represents the most significant improvement to Service Mesh in recent years and is the definitive answer in the debate about the best Service Mesh.
More serious problems, such as fully networked virtual machines or IoT (Internet of Things), cannot be solved without the use of Istio Ambient Mesh.
