Istio service mesh is an open-source platform that simplifies the security and network of cloud-native applications. It abstracts the network and security layer from the application into the infrastructure layer. This is helpful in securing and managing communication between microservices, improving developer experience, and achieving zero trust networks.
There are two operating models for Istio: DIY and managed Istio with enterprise support. The DIY approach, where organizations deploy and manage Istio on their own, is prone to some challenges, such as lack of technical expertise, resource availability, etc.
In this blog, we will explore the challenges of self-managing Istio in detail and see how enterprise Istio support can bring immense value.
Challenges of self-managing/DIY Istio
Self-managing any open-source software comes with a set of challenges. A complex piece of software like Istio is no exception to this.
Below are the 5 dimensions of challenges enterprises will face while implementing Istio in the DIY operating model:
1. Ownership problems
Most open-source products are not plug-and-play solutions. Implementing them requires someone or a team to take full ownership of their implementation and maintenance. Otherwise, it may lead to suboptimal performance, unpatched security vulnerabilities, and downtime.
So the following questions have to be addressed before considering Istio or any other open-source solutions:
- Who will analyze if the product is hardened and ensure it does not compromise enterprise security?
- Who will perform the required experimentation or chaos engineering?
- Who will troubleshoot when the software breaks?
- Who will be in charge of fixing vulnerabilities and bugs?
- Who will take care of the product’s lifecycle management?
- Who will collaborate with multiple departments for its enterprise-level implementation?
Ideally, Istio owners also need to closely follow Istio’s development to keep the product up-to-date with the latest releases and security patches.
But the problem is that it takes time for the community to patch specific bugs and fix security vulnerabilities. Waiting for the fix to be released and letting the infrastructure be vulnerable meanwhile is not a brilliant solution.
So Istio owners will have to investigate and resolve the issue themselves, which requires an in-depth understanding of Istio’s architecture and underlying infrastructure.
Assuming DevOps has learned Istio in full capacity to implement and maintain it, it brings the question: What should DevOps ultimately do? Should they spend most of their time troubleshooting and maintaining Istio? Or should they set up CI/CD pipelines, and perform automation, infra engineering, and R&D?
2. Learning curve
Enterprises that are confident in their IT teams’ competency usually venture into the idea of handling Istio by themselves. However, operating Istio in the DIY model may backfire, given its complexity.
Istio is a heavy-weight platform that abstracts the network and security infrastructure. Understanding it completely — including its shortcomings and making enhancements to it — requires crossing a huge learning curve.
On top of learning Istio itself, there is the data plane, which is implemented using Envoy proxies. Envoy proxies are powerful and configurable proxies that have their own set of features, configurations, and capabilities that need to be understood separately.
Above all, in general, DevOps folks also have to understand the following concepts to learn Istio properly:
- Kubernetes API controller
- CNI (Container Network Interface)
- Ingress and egress
- Multicluster configurations
- API gateway integrations
- And the list goes on.
Note that I am not saying this to overwhelm and restrain anyone from learning Istio, but to shed some light on the reality of the learning curve in the DIY model of service mesh. And it is true whether you are using Istio or Linkerd.
3. Documentation problems
We can consider documentation pages the “soul” of any open-source project. It helps users to understand the product and use it effectively. Some solutions, such as Kubernetes, are popular for maintaining a comprehensive documentation page.
In a sense, the documentation makes or breaks an open-source product. If the steps outlined on the page are constantly throwing errors, the users will eventually hesitate to dig deeper and stop using the product.
Istio has a well-maintained documentation page with clear instructions and step-by-step tutorials. However, there are a few problems here and there.
For example, those who had followed Istio multi-cluster with multi-network setup a few weeks back must have gotten errors while implementing and configuring Istio, until Ravi Verma, CTO of IMESH, fixed it recently.
The challenge here is that there is a lack of volunteers to update and maintain the documentation page on time. The speed at which Istio evolves is also another reason adding to this.
The rapid evolution has made some documentation or examples outdated, maybe because of functionality changes or interface changes. They will no longer be accurate or applicable to the current version of Istio you are using.
In such a case, when the documentation is not working as expected, DevOps teams will have to reach out to Istio maintainers through the Slack channel to sort it out. This can be a time-consuming process and result in delayed troubleshooting.
4. Customization challenges
Open-source solutions are tested in a specific environment. They are suitable only for environments similar to the ones in which it is tested (not unique to open-source).
In real-life scenarios, enterprises run different environments and the requirements vary from one to another. They will need a lot of customization to make the product seamlessly integrate with their existing tech stack.
With Istio, there are no one-size-fits-for-all use cases. Organizations will have different requirements, and it takes some amount of resources to make Istio fit their needs.
Below are some what-if scenarios where heavy customization is required:
- The latest version of Istio (v1.17) supports K8s versions 1.23, 1.24, 1.25, and 1.26. What if you have an older version of K8s?
- What if you need to implement Istio in hybrid environments — Fargate/Lambda/GKE/on-prem VMs?
- Update on October 19, 2023: As of now, Istio does not work with AWS Fargate/Lambda. We tried to deploy Istio in Fargate for a few clients but there were many roadblocks with almost zero integration support from AWS. With limited configuration allowed for AWS Fargate, it prevents routing initialization for Envoy proxy and running DaemonSets (needed for CNI mode).
- To give context to why Istio does not work with AWS Fargate:
- Elevated access is not supported for pods, which is required by init container to initialize routing rules.
- DaemonSet is not supported, which is another option to run Istio in CNI mode.
- See this thread for more details.
- For now, we recommend DevOps and architects to migrate Fargate workloads that need to be part of Istio service mesh to EC2/EKS. IMESH can provide managed Istio support for that.
- What if you have to integrate Istio with AWS CA or DigiCert Enterprise PKI Manager or any other certificate manager to implement certification rotation for mTLS?
- What if you are already using an API gateway, such as Kong, Mulesoft, or Apigee? How to make the Istio integrate with an already invested infrastructure?
- What if you are using AuthN/AuthZ providers like Microsoft AD with x versions for which Istio does not provide out-of-the-box support?
- What if you are using Spinnaker or Argo CD or Tekton CD for deployment and want to configure Istio and Envoy as resources for deployment into multiple clusters?
- What if you want a complicated architecture like Istio-on-Istio deployment?
These are only a few of the custom requirements/integrations enterprises require while configuring Istio. Sometimes they can be much more complicated.
5. Version upgrades
Challenges are plenty in upgrading versions of open-source solutions that are implemented enterprise-wide. Upgrading to a new version may introduce compatibility issues with existing applications and infrastructure, and this can lead to unexpected downtime.
Having enough technical expertise is inevitable to carry out version upgrades so that it does not break customizations and integrations. Otherwise, it will end up in application outages.
(Trust me, this is the first thing that comes to everyone’s mind during Istio version upgrade conversations.)
Istio is one of the most popular projects in CNCF, with over 500 companies including Google, Microsoft, and IBM contributing to it. The active community of contributors of Istio leads to faster releases of new features.
However, dealing with upgrades itself can become a problem for DevOps. For instance, matching the Istio version to the underlying version of Kubernetes can be painful and time-consuming.
There are many questions DevOps, architects, and cloud platform teams need to ask themselves:
- Is your current Istio version inadequate to meet your requirements?
- Does the new version, say v1.17, have all the features to help achieve your security and network management goals?
- Is the new Istio version stable?
- Will the new features significantly outweigh the cost of migrating to the new Istio version?
- What is the estimated cost of running the latest version of Istio?
- What is the estimated impact of the new version of Istio?
- What are the CVE risk mitigation strategies? How to ensure FIPS compliance?
Finding all these answers can be overwhelming for a team, and the discussion can stretch for months. Meanwhile, there is another major Istio release.
Recently, Istio launched ambient mesh, which has a completely different architecture aimed at making Istio more resource-efficient by adopting a sidecar-less pattern. Istio ambient mesh will be very compelling for existing Istio users to cut down their cloud bills.
But the DIY model will only generate more problems in hand for DevOps to leave their core work and focus on upgrading Istio.
How enterprise Istio support can help
The negative impact of managing Istio in a DIY operating model can be catastrophic at times, such as resulting in unexpected downtime.
And since the DevOps folks maintaining Istio have to spend too much time learning and troubleshooting Istio along with their core work, the possible degradation of developer experience cannot also be overlooked.
One ideal solution to avoid all the challenges of self-managing Istio and its negative impact is to choose enterprise Istio support.
We have done a detailed comparison between the top 7 vendors providing enterprise Istio support. You can check it out here and choose the one that is the best fit for you: Istio Service Mesh Vendor Evaluation Guide.
Enterprise Istio support from IMESH
The enterprise Istio support solution is there to make the implementation of Istio and its management painless. IMESH provides enterprise Istio support, and here are three ways we can help.
1. Faster Istio implementation for multicloud and multicluster
Enabling Istio to secure multicluster and multicloud apps can cause endless troubleshooting in the DIY approach. Although Istio is Kubernetes-native, it needs careful planning and engineering to enable traffic management between multiple clusters and VMs.
IMESH offers support for all kinds of workloads deployed in private or public clouds, Kubernetes, or VMs. Watch the video below to have a peek at how to get started with multicluster Istio in EKS and GKE:
2. Enterprise customization for production usage
Each enterprise requires custom integrations to implement Istio because they have different processes, tools, security standards, and governance policies.
IMESH offers pre-built integrations and customizations for over 40 DevOps tools. We also integrate with CD tools, such as Spinnaker and Argo CD, to help you deploy the security and network policies rapidly into target clusters.
(Non-exhaustive) List of software that IMESH can integrate Istio service mesh with:
- Data centers: AWS/GCP/Azure/On-prem VMs
- Kubernetes: On-prem K8s/EKS/AKS/GKE
- API Gateway: Mulesoft/APIgee/Kong/
- Ingress controllers: NGINX/HA proxy/Ambassador
- CD tools: Spinnaker/GitHub Action/Tekton
- GitOps tool: Argo CD/ Flux CD/ Argo Rollouts
- SCM: Git/Bitbucket/GitLab
- SSO(IAM): Google SSO/OAuth2.0/SAML/OKTA
- RBAC: LDAP/Azure AD
- Key management: Vault
- Certificate management: Lets Encrypt/AWS CA/ GCP CA/ SPIRE
- Monitoring: Prometheus/Zipkin/Skywalking/Stackdriver
- Logging: Datadog/Splunk
- Tracing: Jaeger
- Notification: Slack/Jira/MS Teams/PagerDuty
- Configuration management: Terraform
3. Istio experts for lifecycle management and CVE fixes
There is a problem VPs and Directors of Engineering face when they have got someone who is doing a good job with Istio.
Let us say if a team member in your organization is in charge of everything Istio, what happens when they leave suddenly? This can lead to operation disruptions and downtime, especially if you have configured Istio for multicluster/multicloud communications.
From our interactions with various enterprises, we can say for sure that it happens quite a lot; Istio experts are hard to find and even harder to retain.
With IMESH enterprise Istio support, you can ensure the availability of Istio experts around the clock. They are specialized in setting up Istio for enterprise applications across multicloud and environments.
Istio experts from IMESH can also help in seamlessly onboarding your developers, Ops, SRE, and Platform teams to Istio. Regardless of your team size, environment size, or cluster size, IMESH’s Istio support team is obsessed with quickly providing value.
To understand the level of expertise our team has and experience it firsthand, you can watch some videos from IMESH YouTube channel where our Istio experts show demonstrations around Istio.
Benefits of IMESH enterprise Istio support
IMESH provides Istio training, administration, and operation training. Besides, we provide advanced concepts training to developers, application/platform teams, SecOps, and SREs.
Some major benefits of IMESH enterprise Istio support include the following:
- 3X faster time to implement Istio for your Kubernetes and VM workloads within SLA
- $2Mn savings in the cost of ownership of maintaining Istio and Envoy with faster time to vulnerability fixes
- 100% security of traffic and data-in-transit with faster implementation of certificates and authorization and authentication in your environment.
Interested in trying enterprise Istio (free pilot)?
Open-source solutions are not cheap. It takes a huge amount of resources to deploy and manage them. As we saw above, Istio is no exception to this pattern.
Our experts will help you deploy Istio in a pilot environment to determine the security benefits it can bring to your fleet of microservices:
- Check the core Istio features
- Implement mTLS
- Experiment with advanced network strategies
- Visualize network performance and behavior
- Evaluate the cost, time, and risk for the project
Book the free Istio pilot here: https://imesh.ai/book-istio-service-mesh-pilot.html