This is the first in a series of articles on Tetrate Enterprise Gateway for Envoy (TEG), the enterprise-ready distribution of Envoy Gateway, the cloud-native service gateway. Get access to TEG today and sign up for our intro to Envoy Gateway webinar ›
Introduction
When you create software that is more than a self-contained script, you start to think about how the different parts of your software connect with each other, followed by how you secure that connection and make it stable. If you are running in Kubernetes, you are likely asking yourself when to start using a service mesh, like Istio, or if a gateway, like Envoy Gateway and Tetrate Enterprise Gateway, fits your needs.
“What is the chattiest part of your system?”
If most of your network calls come from outside the system, you primarily deal with North-South Traffic. If most of your network calls are between services in your system, you mainly have East-West traffic.
Mainly North-South Traffic: Use a Gateway
The Monolith
If your frontend app wants to call a single backend, you should use a gateway. These architectures are often referred to as monolithic, where all the functionality on the backend is in a single runtime. This is a reasonable architecture for smaller and less complex systems.
Smaller Systems
If you only have a handful of backend services calling each other locally, a service mesh is possibly overkill, and a gateway is likely an appropriate solution. If your system is split up into a few large backend systems called by your apps, managing them without a service mesh is often easier than adopting a service mesh early on. These might be systems split up into two common subsystems: the end user system and the internal admin system.
Mainly East-West Traffic: Use a Service Mesh
Large Microservices Architectures
Consider a service mesh if you have many backend services calling other backend services. This architecture is typical in more complex systems with subcomponents that must scale independently based on system usage. These systems are composed of microservices, and you are looking to manage how these interact at scale securely and get consistent observability of the system.
When you have a lot of services, the service mesh is a component that helps you design a resilient architecture. If you want to learn more about using a service mesh to build resilient architectures, you should check out Building highly available (HA) and resilient microservices using Istio.
But What About…?
If you are considering a gateway, these questions likely pop into your head:
- If I use a gateway, how do I handle encryption of data in flight?
- But doesn’t a service mesh provide an ingress/gateway to Kubernetes?
- If I start with a gateway, how hard is adopting a service mesh later?
If I use a gateway, how do I handle encryption of data in flight?
Sometimes, there’s a misconception that you need a service mesh with mTLS (aka 2-way TLS) to have data encrypted in flight. However, remember that TLS (aka one-way TLS) provides encryption of data in flight, where only the intended recipient can decrypt the request. So, you do not need a service mesh if your only goal is to ensure encryption of data in flight.
The key difference between mTLS and TLS is that with mTLS, you have a “caller ID” – you know which system is calling.
Regardless of mTLS or TLS, the data is encrypted in flight, and only the intended receiving system can decrypt the request.
The “caller ID” that mTLS provides is important in service meshes. Because the service mesh allows you to control which services are allowed to call a service, which with a large number of services becomes critical.
But doesn’t a service mesh provide an ingress/gateway to Kubernetes?
Service meshes also enable north-south traffic from outside the cluster to the services running inside it. Suppose you are already using a service mesh. In that case, you will only adopt another gateway solution if the gateway’s features fill other needs for you that the service mesh’s ingress/gateway isn’t handling.
On the other hand, if you do not currently have a service mesh and do not need its features, it might not be worth taking on the operational overhead, installation, and maintenance of a service mesh. This is especially true if you have a monolithic architecture with only a few services that your frontend calls.
If I start with a gateway, how hard is adopting a service mesh later?
The good news is that this is not an either-or question but rather about finding the appropriate solution for you at the right time. Adopting a service mesh will not be more complicated because you have a gateway. Sometimes, it is easier because you are more familiar with the features you are using and the Kubernetes Gateway API.
Overall, a gateway is easier to operate, upgrade, and manage than a service mesh, especially a lightweight Gateway such as Envoy Gateway, which can be configured with the Kubernetes Gateway API.
###
If you’re new to service mesh, Tetrate has a bunch of free online courses available at Tetrate Academy that will quickly get you up to speed with Istio and Envoy.
Are you using Kubernetes? Tetrate Enterprise Gateway for Envoy (TEG) is the easiest way to get started with Envoy Gateway for production use cases. Get the power of Envoy Proxy in an easy-to-consume package managed by the Kubernetes Gateway API. Learn more ›
Getting started with Istio? If you’re looking for the surest way to get to production with Istio, check out Tetrate Istio Subscription. Tetrate Istio Subscription has everything you need to run Istio and Envoy in highly regulated and mission-critical production environments. It includes Tetrate Istio Distro, a 100% upstream distribution of Istio and Envoy that is FIPS-verified and FedRAMP ready. For teams requiring open source Istio and Envoy without proprietary vendor dependencies, Tetrate offers the ONLY 100% upstream Istio enterprise support offering.
Get a Demo