Organizations have the need to connect, secure and observe the services running in their environments, whether they be on-premises, or running in the cloud, or hybrid environments.
More specifically, "connect, secure, and observe" means having:
- Control over how traffic is routed.
- Secure, authenticated, and authorized network communications.
- The ability to observe and monitor, and analyze traffic, and the behavior of a system.
Furthermore, organizations need standard methods for implementing policy control, where policies can be reviewed, updated, and enforced. Second, they need the flexibility to modify policies at any time; policies cannot, for example, be coupled to the configuration of running applications. Finally, organizations require the ability for application teams to self-service, for example, the configuration of traffic rules, and of authorization rules pertaining to the services they maintain.
Cloud native connectivity anti-patterns
In his six-part series titled Common patterns for solving cloud-native connectivity, Solo.io CTO Louis Ryan walks through a list of ways in which organizations have dealt with these needs, by employing certain anti-patterns, from "DIY" solutions to L3 networking solutions, to a practice called "hair-pinning."
To summarize briefly, the "do it yourself" anti-pattern involves application teams fending for themselves to connect, secure and observe their applications by means of introducing software libraries that provide traffic routing, telemetry, and secure communications capabilities. This approach has many problems, including language diversity, library consistency, library maintenance, and dynamism – the inability to effect a policy change in a timely fashion.
The Layer 3 networking solutions anti-pattern involves attempting to secure network communications through firewall rules and other layer 3 attributes that associate workloads to network identity (e.g. IP addresses). Problems include:
- IP churn – the fact that identity coupled to network identity doesn't work in environments where the assignment of IP addresses to workloads is dynamic,
- Ticket ops – the need to submit tickets to the platform or infrastructure team to effect a policy change,
- Being limited to Layer 3/4 networking (not Layer 7), and
- Hybrid impedance mismatch – inconsistencies in terms of how rules are applied across environments (cloud vs on-prem, for example).
The "hair-pinning" anti-pattern involves routing internal traffic through the API gateway as a means of obtaining policy enforcement. Problems with hair-pinning include:
- The gateway becomes a single point of failure,
- Increased latency in calls between services having to be routed through a gateway,
- Locality outage when services are unable to reach the API gateway in a different environment due to a network communication issue, and
- Cost explosion due to the way that many API gateway solutions are priced.
Sidecar-based service mesh
Louis goes on to describe how service meshes have helped organizations achieve their cloud native connectivity objectives by introducing proxies as sidecars alongside workloads. But sidecar-based service meshes introduce problems of their own, including:
- Users have no choice but to deploy a proxy alongside every single workload, whether their layer 7 capabilities are required or not. Adopters almost always deploy more proxies than they need. This increases resource utilization and cost.
- From a security standpoint, the layer 7 sidecars represent a larger attack surface.
- Sidecars are part of the mesh infrastructure, and are coupled at deployment time to applications. In Kubernetes, every pod has a sidecar injected alongside the application workload. The implication is that upgrading or patching the sidecar disrupts the operation of the running application, for example.
- The coupling of application workload and sidecar complicates operations. Patching a CVE in Envoy requires restarting your entire fleet of applications.
- As the number of services in the mesh grows, the control plane has to do more and more work to keep all of the proxies' configurations up to date.
Istio Ambient Mesh
Service meshes continue to evolve, and the Istio project today offers two modes: the older sidecar-based implementation, and a newer approach: ambient mode.
Istio's ambient mesh was developed as a response to the problems encountered with sidecar based installations. In ambient mode:
- Mesh infrastructure is separate from running applications.
- We can enable mutual TLS & zero-trust without deploying any Layer 7 proxies (no Envoys). Ambient mesh's ztunnel component acts as a per-node Layer 4 proxy that efficiently and securely routes traffic between services.
- The Kubernetes Gateway API supports the ability to deploy waypoints on-demand where we need them, and scaled to the volume of traffic, not the number of pods being proxied.
When using Istio in ambient mode, cost is consequently dramatically lower, and operations are dramatically simpler. In his blog How Ambient Mesh Delivers Advanced Resource and Cost Savings, Brian Jimerson does a deep dive into those cost savings by providing several cost comparisons between running a sidecar-based service mesh and Istio ambient mode.
Summary
If today your organization is running Istio in sidecar mode, or if your organization is in a situation where it employs one of the above-referenced anti-patterns to implement cloud native connectivity, ambient promises to dramatically improve both the costs and complexity of your architecture.
To facilitate migration from Istio sidecar mode to ambient mode, Solo.io publishes a free migration tool, which can be downloaded from ambientmesh.io. Louis Ryan & James Ilse (principal solutions architect @ Solo.io) demonstrate this migration tool in a recently conducted webinar titled From sidecars to Ambient: A practical guide to migrating your service mesh. Separately, How to migrate workloads from sidecar to ambient mesh with zero downtime provides yet another demonstration of the use of the migration tool.
%20a%20Bad%20Idea.png)
%20For%20More%20Dependable%20Humans.png)
