With the popularity of service mesh at an all time high, it is important to think about how it might affect your current architecture. You might think you have to completely rework your environment, that it might not be “mesh ready.” But in fact you can integrate a service mesh into your current stack and make it work for your organization.
This is where gateways can play a very important role. This blog post will explore the common ways to use gateways that work in your current architecture. I will be using Istio in this example as there are exciting new features in this open source mesh that make gateways even better.
What is a gateway?
Istio defines a gateway as “a load balancer operating at the edge of the mesh receiving incoming or outgoing HTTP/TCP connections.” This definition seems outdated as users should be embracing gateways on the edge as well as internally to your mesh. For now let’s just define a gateway as a load balancer that abstracts away the internals of an API or set of APIs from the microservices it fronts.
Modern gateways
Istio is evolving at an extremely fast pace and one of the areas getting a lot of attention is that of gateway setup and networking. With the introduction of the Istio Operator, users can easily configure any number of gateways for their workloads. This is a big deal. You have the ability to deploy and configure lightweight load balancers more easily than ever before. With the relative low cost and ease of use, we can now add gateways not just on the edge of our mesh but internally.
Deploying a bunch of gateways into your mesh is great but it’s only the first part. At Tetrate we want these gateways to be easily accessible and automatically discoverable. We want to give teams the ability to share their APIs internally and externally with ease. To do that the gateways need to be easily identifiable and often available between clusters or regions. Sometimes gateways may even need to be available between clouds as well.
Shared Ingress Gateways
When organizations first adopt Kubernetes they are exposed to a single ingress solution, Nginx ingress controller. For many, as they mature in their Kubernetes experience that single ingress point largely remains the same to the point that many teams may rely on it. Some may migrate to the Istio ingress gateway but the single point of ingress still persists. From a management perspective this seems logical but as more and more teams depend on it, it can become a single point of failure.
Instead we recommend an ingress gateway for every product offering (defined by you). This removed dependencies between teams and products that should not share failure domains. It also isolates errors from misconfigurations and upgrades. As we will see below, it also allows products to grow independently when they are ready for a multi-cluster offering. With Istio migrating to multiple gateways is very simple and can still be managed from a centralized location. I suggest starting here when working toward a multi cluster architecture.
Single Ingress Gateway
Ingress is shared between teams and products that should be isolated. In the following example the Payments team and Analytics team share a cluster and Ingress Gateway. They listen on two different hosts payments.my-company.io and analytics.my-company.io
Multiple Ingress Gateways
Isolating Ingress Gateways to the APIs and products they represent. We made the decision to add the Payments Gateway to the Payments Namespace as it was self containing of the entire product. Because the Analytics product spanned multiple products, we decided to put the gateway in an isolated namespace for easier management between them.
The payment service is growing…
Good news! The payment service is a smashing success but it’s also more important than ever within your organization. Clients are asking for more features… You need to break apart your microservices… You need to think about high availability… By adopting a gateway architecture you can better achieve these goals without impacting your clients.
Step 1: Inserting the gateway
By adding a product focused gateway, you have just made a single entrypoint for clients where you can abstract the API from the underlying microservices. Now you can grow your applications with the increased demand without impacting clients.
Achieved by:
- Adding a gateway into your namespace.
- Migrating internal clients to call gateway instead of individual microservices.
- Migrating external clients from the shared istio-ingressgateway to Payments Gateway
- Keeping API the same as to not disrupt client activity
Advantages:
- All users have single point of entry
- Can add/edit existing microservices without disrupting the clients.
- You can implement circuit breaking, authentication and authorization
- No longer rely on shared workload gateway
Step 2: Splitting up the microservices
Your microservices have grown too large in responsibility. You would like to break up the payments microservice into two (direct-deposit, credit-card). Now that you already migrated to a gateway this is easy as long as you still honor the API contract.
Step 3: High availability
Your boss has asked that you add another Payments API in a cluster in another availability zone. They say that your APIs need to be closer to the consumers and highly available. This is easy with your gateway architecture. Using Istio we can create ServiceEntries that now make both gateways discoverable. We can also use Istio DestinationRules to keep traffic locally to the cluster it originates.
In conclusion
Gateways are a great way to hide the internals of your API and to share a single point of entry for the functionality that you want to expose. Using gateways provided by Istio allows you to quickly and effectively deploy gateways closer to your applications. It also allows you to scale your architecture much more efficiently while keeping the same look and feel.
At Tetrate we are working to make this gateway architecture easier to implement, manage, and monitor. From adding multi-cluster support and routing to securing communications, we are automating a lot of the complex Istio configurations so you don’t have to worry about them.
If you would like to learn more see the links below.
