- Home
- >
- Software Development
- >
- The Who, What and Why of Service Mesh – InApps 2025
The Who, What and Why of Service Mesh – InApps is an article under the topic Software Development Many of you are most interested in today !! Today, let’s InApps.net learn The Who, What and Why of Service Mesh – InApps in today’s post !
Key Summary
This article from InApps Technology, published in 2022 and authored by Phu Nguyen, explores the role of service meshes in managing large-scale, containerized microservices architectures. Featuring insights from Matt Klein (creator of Envoy), Varun Talwar (CEO of Tetrate and co-creator of Istio), Andrew Jenkins (CTO of Aspen Mesh), and analyst Tom Petrocelli, the article clarifies that service meshes are essential only for organizations with mature microservices and dozens of developers. A service mesh enhances observability, resilience, and security by using sidecar proxies to handle tasks like monitoring, logging, traffic routing, and encryption, freeing developers to focus on business logic. Comprising a data plane (e.g., Envoy) and control plane (e.g., Istio), service meshes standardize these functions across services. While alternatives like client libraries work for smaller, single-language apps, they falter in diverse environments. The article notes that service meshes, still immature (e.g., Istio not fully production-ready), face challenges like complex upgrades and learning curves, but their adoption is expected to grow as containerized systems proliferate.
- Context:
- Author: Phu Nguyen, synthesizing insights from Matt Klein, Varun Talwar, Andrew Jenkins, and Tom Petrocelli.
- Theme: Service meshes solve critical problems in large-scale microservices but are unnecessary for smaller or less mature systems.
- Source: InApps article, referencing Envoy, Istio, Linkerd, and other service mesh technologies.
- Key Points:
- What is a Service Mesh?:
- A system to manage communication, observability, and security in containerized microservices via sidecar proxies that form a network mesh.
- Comprises:
- Data Plane: Handles traffic routing (e.g., Envoy, a CNCF project).
- Control Plane: Manages policies and provides observability (e.g., Istio, not CNCF-hosted, or Linkerd, which includes both planes).
- Other players: Nginx, Solo.io, HashiCorp Consul.
- Why Use a Service Mesh?:
- Observability: Provides insights into communication issues and supports compliance audits.
- Resilience: Ensures reliable traffic routing and service interactions.
- Security: Automates encryption and certificate rotation, reducing developer burden.
- Developer Efficiency: Frees developers from coding repetitive tasks, focusing on business logic.
- When is it Needed?:
- Essential for large-scale companies with mature microservices (dozens of developers, complex clusters).
- Not needed for smaller or less complex systems; client libraries suffice for single-language apps.
- Petrocelli’s Prediction: As containerized applications grow, service mesh adoption will balloon.
- Challenges:
- Immaturity: Envoy is mostly production-ready, but Istio is not, despite heavy promotion by Google.
- Complexity: Requires collaboration between developers and network engineers, plus managing upgrades and multiple meshes.
- Alternatives:
- Client Libraries: Effective for small, single-language apps but impractical for multilingual, enterprise-scale systems.
- Future Outlook:
- Service meshes will become standard in cluster-based architectures for security and observability.
- Challenges to address: installation complexity, multi-mesh management, and learning curves.
- What is a Service Mesh?:
- InApps Insight:
- InApps Technology, ranked 1st in Vietnam and 5th in Southeast Asia for app and software development, specializes in microservices and service mesh implementations, using React Native, ReactJS, Node.js, Vue.js, Microsoft’s Power Platform, Azure, Power Fx (low-code), Azure Durable Functions, and GraphQL APIs (e.g., Apollo).
- Offers outsourcing services for startups and enterprises, delivering cost-effective solutions at 30% of local vendor costs, supported by Vietnam’s 430,000 software developers and 1.03 million ICT professionals.
- Relevance: Expertise in containerized architectures and cloud-native solutions aligns with deploying service meshes like Istio or Envoy for scalable, secure applications.
- Call to Action:
- Contact InApps Technology at www.inapps.net or sales@inapps.net to develop microservices or service mesh-based applications for enhanced observability and security.
Read more about The Who, What and Why of Service Mesh – InApps at Wikipedia
You can find content about The Who, What and Why of Service Mesh – InApps from the Wikipedia website
If you’ve been hearing about service mesh — perhaps you’ve noticed that Istio seems to be everywhere — you might be wondering if you need a service mesh. Here’s a message everyone in-the-know agrees on, from the creator of Envoy, to the leaders of Tetrate and Aspen Mesh who are building companies on service mesh support to technology analysts: If you’re wondering about service mesh, you don’t need one. Period. If you’ve reached the scale and microservice maturity level that requires a service mesh, you will be actively — perhaps desperately — searching for a solution and it will be abundantly obvious that a service mesh is necessary.
“I think we have a tendency to chase the shiny object, in the sense that X company does Y, therefore I must do Y, even though I don’t have any of X company’s problems,” explains Matt Klein, the creator of Envoy, an open service mesh.
Service meshes solve legitimate problems — we’ll get into that in just a minute. Most companies just don’t encounter those problems until they are both working on a mature microservices architecture and are large enough to employ at least several dozen developers. “Companies like that are actually sort of the exception to the rule,” explains technology analyst Tom Petrocelli. “Your average bank doesn’t have massive clusters out there.”
But while most companies don’t need a service mesh right now, Petrocelli thinks it’s a market poised to balloon, because he sees the number of large-scale companies with mature, containerized applications increasing dramatically in the next several years.
So what is a service mesh? What problems does it solve?
Observability, Resilience and Security
A service mesh is a way to increase the observability, resilience and security in a large-scale containerized application. “Part of the attraction for working with a service mesh is that you get all three in one,” explains Varun Talwar, CEO of Tetrate and one of the creators of Istio.
“There are a lot of common functions that you need to implement in every service, like monitoring, logging events, tracing requests, executing and encrypting all outbound calls, routing traffic to the service,” Talwar explains. In a service mesh, a sidecar proxy is attached to each service and handles all of these standard functions that every service needs. It’s called a “mesh” because the sidecar proxies handle all communications between the services in the application, creating a network “mesh” of services.
With the sidecar proxy handling all mundane tasks, developers no longer have to code those functions into the service. That frees up developers time to work on other things. More importantly, a large organization no longer has to rely on individual developers to ensure that communication is properly encrypted, that security certificates are rotated or that logging is properly set up. The observability the control plane provides also makes it possible to debug communication problems, as well as to get the information needed to pass compliance audits. “The application developer wants to focus on business logic, what makes the business money,” explains Andrew Jenkins, chief technology officer at Aspen Mesh. “They don’t want to implement the certificate rotation story over and over and over again. A service mesh means you only have to do it once and it’s part of your infrastructure.”
The service mesh is made of up two components: The data plane and the control plane. The data plane actually implements the service mesh and does the actual traffic routing, while the control plane has the user interface — it’s where you set the policies for the data plane and the lens through which you get the observability.
In some cases, the data plane and control plane components of a service mesh are decoupled, as is the case with Envoy (a data plane project that is hosted by the CNCF) and Istio (a control plane project created by Google that uses Envoy, but is not hosted by the CNCF). “It’s not true that you can mix and match anything, but there is some mixing and matching going on,” Jenkins explains. Linkerd, the other major open-source service mesh option, includes both the data plane and control plane together. Other players in the service mesh ecosystem include Nginx, Solo.io and HashiCorp’s Consul.
The other way companies handle creating a standardized way to handle communications and observability is through client libraries. For smaller applications that only use one or two languages, this can be an easier way to ensure all the security, logging and communications code is always included, in a consistent way, in each service. In a real-world enterprise scenario, however, in which services are written in many languages, this technique tends to break down.
The Future of Service Mesh
“I think eventually you will see service meshes in the majority of applications,” explains Petrocelli, the technology analyst. “I can’t imagine a bank implementing a cluster-based architecture and not having a service mesh. That would be crazy. Not only for the routing, but simply for the encryption and observability in the network layer.”
As more big businesses move to mature, containerized systems, they will be looking for a service mesh to keep those applications secure and compliant. In the meantime, it’s a good idea to keep in mind that service mesh technology is still fairly immature, too. While Envoy is mostly production-ready, it’s still quite difficult to get up and running correctly. Istio, on the other hand, isn’t production-ready, in spite of Google’s massive promotionally effort — a fact both Petrocelli and Talwar, Istio’s creator, agree on.
As service meshes become more common, they’ll have find a way to address issues like how to install upgrades, how to manage multiple meshes over multiple deployments and how to address the learning curve issues, including the fact that successful implementation requires more collaboration between developers and network engineers than you generally see at most companies.
“There’s a lot of work to be done in service mesh, it’s early days,” Talwar explains. “Most people are talking value and are clearly sold on the value, which is good, but there are still challenges that need to be addressed.”
List of Keywords users find our article on Google:
service mesh 2022 |
service mesh |
istio |
Source: InApps.net
Let’s create the next big thing together!
Coming together is a beginning. Keeping together is progress. Working together is success.