Migrating to AWS App Mesh Alternative, Istio.

The software technology space moves quickly, with new offerings that technologists must rapidly learn, test, and evaluate to determine if they solve existing problems well enough to be adopted. Amazon Web Services (AWS) was an early market leader and has remained a reliable choice for enterprises hosting applications in the cloud. AWS's simplicity and interoperability within its rich ecosystem often make it an attractive choice over alternatives.

However, enterprises should always plan for changes within their environments. Large vendors like AWS may deprecate underused tools in their ecosystems, and rapidly changing market or architectural standards within an organization may force teams to seek newer, feature-rich solutions that better meet their needs.

In the case of AWS’ App Mesh, organizations who adopted and integrated it into their architecture unfortunately are placed in a difficult position with AWS announcing its decision to discontinue App Mesh on September 24, 2024.

Background of AWS App Mesh

AWS App Mesh, introduced at AWS re:Invent 2018 provided application level, core mesh capabilities like service discovery, load balancing, and traffic management across environments. For example, it allowed traffic to shift between service versions via VirtualRouter configurations.

App Mesh followed a sidecar model, with the Envoy proxy in the data plane for routing and client-side load balancing, while the control plane was fully managed by AWS. It operated across all AWS compute environments—EC2 (VMs), ECS (Containers), and EKS (Kubernetes)—and integrated with AWS services like CloudWatch, X-Ray, and CloudMap for monitoring, distributed tracing, and service discovery.

Over time, App Mesh added features like managed ingress with Virtual Gateways and support for mutual TLS. It was particularly attractive to organizations heavily invested in AWS, offering seamless integration with services like CloudWatch and IAM.

The Rise and Fall of Technologies 

External factors, such as acquisitions, bankruptcies, or competition, can cause the adoption of a technology to decline. In the fast-moving IT space, technologies often fall out of favor as new ones emerge. We've seen shifts from mainframes to minicomputers to personal computers, and many operating systems, hardware architectures, and programming languages rise and fall. In the cloud space, technologies like Cloud Foundry, Docker Swarm, and Apache Mesos have come and gone, and companies like AWS and Google often discontinue products after reassessing the market.

Even open-source technologies are subject to the product life cycle; they can lose support, mismanagement, or fail to attract contributors. However, they are also more likely to remain relevant for longer periods because they are not tied to a single entity, development is transparent, and contributions come from a diverse community. This openness allows others to build on the code, ensuring its continued evolution.

On the cost of change, and how Istio’s design guards against it

Choosing a platform carries the risk of discontinuation or displacement, which can be costly for enterprises as platforms are foundational and often integrate with multiple systems. Technologists must carefully evaluate options when migrating applications, a task that can be highly challenging.

With the rise of distributed environments and microservices, service meshes are becoming integral to modern application architectures, with Istio standing out as a prominent choice, especially for enterprises using cloud-native stacks.

Istio offers several advantages:

1. Istio is an open source project.  Developed in the open, is a part of the CNCF.
2. One can participate in discussions relating to the development and implementation of features, uncovering of bugs, and can contribute patches.
3. Istio is a CNCF-graduated project, and with a track record.  Istio is seven years old.
4. Istio has a strong community, is actively used.
5. Istio has seen steady adoption.

Istio is also a type of platform without very many strings attached.  Let’s explain further through the following analogy:

Before the era of microservices, application development frameworks were all the rage.  New contenders would come and go (anyone remember Struts?).  One framework, the Spring framework, stood out.  Its authors realized the cost of adopting a framework, and decided to minimize that cost by introducing a pattern that came to be known as dependency injection:  the code you wrote did not depend on the framework.

Other frameworks had dependencies, in terms of base classes that you had to inherit from, or specific APIs that you had to implement.  With Spring, it was the other way around:  the framework discovered and was aware of your code.  This made code portable, and lowered the cost of taking and running it in a different environment.

Istio operates similarly: your workloads have no direct dependencies on it. Applications within a microservices architecture continue making calls to other services as usual, unaware of the Envoy sidecar or any Istio API. This keeps the cost of adopting Istio as a service mesh low, and if Istio were to disappear tomorrow, there would be no need to untangle your applications from it.

Istio continues to evolve to meet market needs, now offering a sidecarless option through ambient mode. Workloads in ambient mode remain compatible with those using sidecars, so you're not forced to fully transition away from sidecar mode. Better yet, workloads require no configuration changes to run on ambient mode. This flexibility highlights the strength of Istio's design: it reduces both the risk and cost of adoption.

The benefits of Istio

Istio can deliver immediate benefits to your applications without requiring changes:

• The mesh automatically generates telemetry and integrates with open observability tools, eliminating the need for application instrumentation.
• Workloads are assigned and automatically rotated cryptographic identities.
• Network communication is transparently upgraded to mutual TLS.
• Security teams can enforce authorization policies based on workload identity without involving application teams.
• Network resilience features like retries are applied automatically, with additional options configurable independently of the applications.
• Traffic management capabilities, such as zero-downtime upgrades via canary deployments, enhance application reliability and make teams more efficient.

Applications don’t need to be modified—in fact, they often become simpler. You can eliminate outdated logic, retry mechanisms for network failures, or custom routing dependencies.

Separation of concerns and lower coupling, long-standing principles for developers, are just as critical at the platform level, where they have an even greater impact. For users needing to migrate away from App Mesh, Istio provides an excellent alternative.

Migrating from App Mesh to Istio

AWS App Mesh and Istio share similar designs: both use the Envoy proxy for managing communication between microservices and a control plane to configure the Envoys in the data plane. App Mesh relies on an AWS-managed control plane, while Istio uses istiod.

Compared to App Mesh, Istio provides more fine-grained configuration capabilities, whether it be configuring retries, circuit breaking, or the myriad other configuration options that Istio exposes for network communications, resilience, traffic management, or security.

Here is an outline for migrating from App Mesh on EKS to Istio:

1. Install Istio alongside App Mesh.  That includes the Istio CRDs, istiod, and if applicable, deploying gateways.
2. Label the namespaces for Istio sidecar injection.
3. Some mesh features, such as mutual Tls, will be automatically "in play" once the workloads become part of the Istio mesh.
4. Draft Istio mesh configurations matching the existing AWS App mesh configurations.  That includes routing rules, both in the mesh and also at ingress, and resilience configurations (retries, timeouts, etc..).  Solo will be introducing a tool to help translate your existing App Mesh configurations to Istio.
5. Restart the workloads to trigger Istio sidecar injection, and the subsequent configuration of Envoys in the dataplane.
6. At this point, you are free to remove the App Mesh configurations.

Our whitepaper, "Transitioning from App Mesh to Istio for AWS EKS", provides a concrete example of migrating a sample application from App Mesh to Istio.

What if my workloads run on EC2?

Istio was originally designed to run on, and to extend Kubernetes, but it also supports VM workloads.  That is, workloads running on VMs can have Envoy proxies installed as sidecars, and can be configured as first-class citizens in an Istio mesh.

The general advice used to be to begin by migrating most workloads to Kubernetes.

The recent introduction of ambient mode in Istio provides opportunities to construct a mesh with workloads spanning different compute environments, with ztunnel and waypoint proxies providing greater degree of flexibility.  For additional information, look out for an upcoming article on this subject titled "Transforming Istio into an Enterprise-Ready Service Mesh for Amazon ECS".

Conclusion

If you’re looking for an alternative to AWS App Mesh, Istio is a great option that can adapt to existing AWS applications and environments easily and enable users to get the same plus more functionality as they experience with AWS App Mesh. The team at Solo are experts on service mesh and networking technology and continue to contribute to Istio.  If you're looking for enterprise support, or added enterprise features get in touch with the Solo.io.

‍