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 virtual router 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 and 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, or fail to attract contributors. However, they are also more likely to remain relevant for longer periods if 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, promoting 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:
- Istio is an open source project. Users can participate in discussions relating to the development and implementation of features, uncovering of bugs, and can contribute patches.
- Istio part of the Cloud Native Computing Foundation (CNCF), ensuring a neutral playing field for all contributors.
- Istio is a CNCF -graduated project, proving it meets best practices for a community open source project and has the best chance for continued success
- Istio has a seven year track record
- Istio has seen steady adoption, has a strong community and is used widely.
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:
- Install Istio alongside App Mesh. That includes the Istio CRDs, istiod, and if applicable, deploying gateways.
- Label the namespaces for Istio sidecar injection.
- Some mesh features, such as mutual Tls, will be automatically "in play" once the workloads become part of the Istio mesh.
- 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.
- Restart the workloads to trigger Istio sidecar injection, and the subsequent configuration of Envoys in the dataplane.
- 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 or Fargate?
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 providing a greater degree of flexibility. Learn more in this blog from AWS: "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, try Solo's Istio-based solution Gloo Mesh and get in touch with the Solo.io team.