A service mesh is a dedicated infrastructure layer that controls service-to-service communication.
In addition to connecting service across a network, service mesh also handles other functions like load balancing, security, and encryption.
A service mesh can standardize connections with third-party services such as a cart, order management, and PIM.
With service mesh, external services like fabric PIM integrate seamlessly with other services.
E-Commerce Service Mesh Definition
A service mesh describes infrastructure components that allow microservices to communicate. In contrast to an API gateway that sits in front of your public-facing HTTP layer, a service mesh connects the internal elements of your application and dictates how they can interact with one another.
Overview of an E-Commerce Service Mesh
The concept of service mesh became famous in 2010 when big companies like Google, Facebook, Netflix, and Twitter began to use microservices instead of monolithic applications to handle load efficiently. Back then, adopting loosely coupled microservices for any software development project was challenging. The tooling wasn’t as good as it is today, there weren’t nearly as many people using microservices at startups, and many of the terms we use now hadn’t been coined yet.
Things have come a long way in the past six years, and one of the most exciting developments is the rise of third-party API-based platforms and service meshes. Now, instead of building your microservices from the ground up, you can integrate with pre-built services to add backend functionality to your application.
The primary function of a service mesh is to connect services across a network. However, because service mesh touches all requests between services, it sits in a perfect spot to handle several essential application functions:
- Logging and monitoring: Tracing and debugging in microservices is challenging, but having a standardized service mesh can help.
- Security: Because the service mesh passes requests between services, it can enforce rules about which data is passable into or out of each service. It might also handle authentication between services.
- Encryption: Any communication over a network should be encrypted, and typically, a service mesh can facilitate this by administering keys and certificates for each service.
- Load balancing: If you have multiple instances of each service, your service mesh could be responsible for distributing traffic between them.
- Failover and rate-limiting: If one of your services goes down, your service mesh will be in an ideal spot to tell you about it. It might also help by rate-limiting requests to prevent you from accidentally DDoSing yourself.
How an E-Commerce Service Mesh Works
Let’s take a look at how a service mesh might connect the various microservices an e-commerce application is likely to use:
E-commerce service mesh ensures APIs can connect and stay active. It will handle encryption between the auth service and order service to keep user data safe and ensure product information management (PIM) service scales up or incorporates load balancing to handle failures. Also, it will log errors when an item without a price is added to the order.
To start building a service mesh for your e-commerce application:
- Start breaking down monolithic applications: Adopting third-party e-commerce microservices instead of building, managing, and updating monolithic applications makes it easier to scale with growing demands.
- Find an open source or third-party service mesh: Consul, Istio, and Kuma are good options if you’re using container-based microservices. Check out a list and comparison of other reliable service meshes here.
- Configure your service mesh and supporting tools: You’ll need to decide how to collect logs, install SSL certificates, and how load balancing will work between each instance of your services. Typically this means spinning up new containers (or sidecars) and data volumes in your Kubernetes cluster.
- Understand the technical considerations below: These will help you choose the right service mesh and configuration based on your needs.
Using a service mesh for third-party APIs
While typically used to marshal data between pieces of your core application, a service mesh is also helpful for standardizing connections to integral third-party services. For example, let’s say a company is building an e-commerce application. They might start with a cart service, order service, and a product information management (PIM) service:
As application and product catalog scales, they might realize that it’s a better investment of engineers’ time to focus on the user experience than building a PIM from scratch. So, the brand decides to integrate with a third-party PIM.
Next, they integrate with another third-party tool like Courier or Nexmo to deliver multi-channel notifications to users. The brand can use service mesh top proxy calls to these third-party services and control data flow to their existing internal services.
The service mesh pattern ensures that communication between internal and external services happens seamlessly and lets you swap between in-house and third-party solutions more easily as the application evolves. Because the service mesh acts as an interface between services, the brand shouldn’t have to refactor all services every time there is a need for an update.
Examples of E-Commerce Service Mesh
Criteo, an online advertising company that helps brands, retailers, and publishers meet their business goals, is an example of commerce media platforms whose adoption of service mesh changed its narrative. Before adopting microservices, Criteo’s extensive monolithic application had reached a point where it couldn’t evolve anymore.
Criteo has a massive infrastructure with 40,000 servers and over 4000 services operating in many instances. As the application became bulkier, Criteo had no choice than adding microservices in its design. However, this introduced another level of challenge: communication between applications.
Criteo needed to process requests quickly to avoid losing clients, so it adopted Consul, a service mesh architecture, to improve its communication. By adopting service mesh, Criteo built smaller APIs into its applications called CLSB for clients’ sites. With Consul service mesh, Criteo tackled scalability, reproduction, and sharing issues with little effort after using containerized deployments.
Auto Trader is UK’s largest digital automotive marketplace in the UK, selling both new and used cars. The complexity of its platform and changing requirements precipitated Auto Trader UK’s migration to containerized application. In addition, Auto Trader wasn’t satisfied with typical perimeter security; it also aspired to encrypt all traffic between microservices, including those in the same local network, using mutual-TLS.
After the AutoTrader platform team’s unsuccessful attempt with proof of concept implementation, the brand decided to experiment with a container-based solution that uses Istio service mesh to manage mTLS for an essential end-to-end slice of their microservice architecture. AutoTrader’s run their experiment on Google Kubernetes Engine (GKE), implementing encryption in the containerized project within a few days instead of weeks of implementing it on a private cloud.
E-Commerce Service Mesh FAQs
What is a service mesh?
A service mesh is a software architectural pattern that uses sidecar proxies to enhance communication between microservices and control data sharing between applications. Popular service mesh offerings are Istio, Consul, and Linkerd.
What is a service mesh architecture?
A service mesh architecture is a software architectural pattern used in microservices to implement functions like encryption, tracing, and load balancing functions. This leads to improved reliability, security, and observability.
Is a service mesh necessary?
If you’re building applications on Kubernetes or using the microservice architecture, you need a service mesh to provide observability, reliability, and security features. Service mesh ensures that communication across containers or pods is secure, fast, and encrypted.