Migration to the cloud and containers has left a scattered ingress landscape. As a result, modern infrastructure architectures rely on several different networking technologies and tools. Most infrastructures utilize four major networking tool categories: load balancers, reverse proxies, ingress controllers, and API gateways. However, many seemingly separate ingress tools have overlapping functionality. Identifying these overlaps brings an opportunity for significant cost savings.
These tools aim to simplify your overall routing strategy, primarily concerned with processing ingress traffic. They also balance traffic across multiple back ends, whether those are multiple applications or just multiple copies of our servers. All four tools also offer health checks to ensure they only route to valid healthy instances on the backend. What’s more, if we zoom in on reverse proxies, ingress controllers, and API gateways (excluding the load balancer), all of those use some combination of routing rules, providing a single entry point for multiple applications or APIs on the backend.
So, how do all these pieces play in as part of a networking stack, and how does a consolidated approach work?
The state of networking
In the complex world of cloud networking, it’s easy to end up with separate ingress controllers, proxies, load balancers, and other tools with overlapping functionalities. The diagram below shows a representative example of the infrastructure used by many organizations running a networking stack, for instance, in a public cloud provider.
The example architecture above includes a Kubernetes cluster with a number of pods that are running, user applications, as well as API services. These apps and services live behind an ingress controller in the cluster and a cloud load balancer that fronts the ingress controller itself. This infrastructure also includes a collection of API services running outside of Kubernetes — those could be running on virtual machine (VM) instances or containers outside of a Kubernetes orchestration platform. And last but not least, a set of virtual machine instances is used to run applications.
In this scenario, you would implement a reverse proxy in front of those VM applications, a load balancer across the copies of our API server, and an API gateway in front of the API instances and API pods in your cluster.
As you can see, this is getting complicated quickly, having to configure and manage different tools deployed into your stack that, in many cases, handle relatively similar or overlapping functionalities.
The multitude of tools used in an infrastructure like this one often translates to a multitude of different vendors, which in turn increases costs, configuration, and management complexity. Managing that level of complexity often requires a significant amount of internal IT resources in the form of dedicated representation for each tool or asset. Communication between different tools and vendors is also tricky and may require a lot of internal resources to implement workarounds that guarantee each tool works the way you need it to.
Webinar: From Chaos to Controlled Learn how to simplify multi-cluster networking for all your applicationsWatch the WebinarKey considerations for consolidation
Consolidating tools is a process that takes time to happen. You and your team need to identify tools that can take over multiple roles within your network (effectively replacing the various tools you currently use), fill gaps where needed, and formulate a migration plan. But how do you reach the decision to consolidate? How and when is it the right option for you? And where to begin? Here are five key questions that will help you kick off your consolidation efforts.
- Where do tool functionalities overlap in my network architecture?
- Which tools are flexible enough to fill multiple ingress network roles?
- What constraints exist that inform where tools can be consolidated? (networking rules, compliance, performance)
- Where should my consolidated network stack run primarily?
- Do I need multiple layers of load balancing?
Once you have answered these questions with the help of your IT team, move on to the four main steps of consolidation.
- Diagram network flows. Visualize your infrastructure by mapping out your network flow.
- Identify duplicate components within the diagram of your architecture.
- Pick a tool to use as a consolidated ingress.
- Plan migration approach from current routing to consolidated routing.
The last step of consolidation (i.e., migration) is the most critical. This process is not something that you can plug and play overnight and magically solve all your issues. Teams have multiple projects to handle, sprint schedules to adhere to, deadlines to meet, etc. Migrations are never easy but sometimes necessary, the timing of a consolidation effort should be planned so that minimal downtime is achieved.
As it is universally accepted, time is money. The complexities of managing different tools and vendors weigh in on the time management of your IT staff. That is why consolidating your networking tools into a unified platform or tool that handles all of these major categories (load balancers, reverse proxies, ingress controllers, and API gateways) can be a game changer.
Let’s revisit that architecture diagram we went through earlier and take a look at how that
example architecture can be condensed down to a more streamlined, consolidated approach.
In the consolidated version of the example architecture, you can see that the separate tools for load balancer, reverse proxy, API gateway, and ingress controller are consolidated down to a single component.
While that component is within the Kubernetes cluster, labeled in the diagram as an ingress controller, it’s actually handling all of those different functionalities, doing load balancing to your instances on the backend, handling routing based on the reverse proxy-like rules either to your pods within the Kubernetes cluster, or the resources outside of it, and handling the routing for your non-Kubernetes workloads. It also handles the API gateway type functionality, so it handles your security measures — like authorization and authentication — or the rate limiting and more sophisticated traffic handling functionalities.
Note: In the example diagram, not every functionality has been consolidated down into a single ingress tool — the load balancer still lives in front of the consolidated ingress controller. The reason for this is that, in many cases, multiple layers of load balancing may need to happen. So, that means having a consolidated ingress tool handling most of your routing and load balancing for your existing APIs and applications but still needing some load balancing for the ingress controller components.
At this point, it is important to note that consolidating all the separate tools into a single component requires a tool that is flexible enough to route to all those different instances — whether that means plugging in different service discovery mechanisms, being able to route statically to the different instances, handling higher level functions like security, authorization, and authentication, and any other functionality that’s going to be critical in selecting exactly what we’re going to consolidate on.
Consolidation with Traefik Enterprise
Consolidating your networking tools may sound like a lot of work, but its benefits come in many different forms. In my day-to-day talks with customers, there are the main benefits that I most encounter that resonate with them as their key reasons for moving to a consolidated networking solution like Traffic Enterprise:
- Cost-saving in the form of reduced cloud spend or on-prem hardware reallocation
- Time-saving on the management of separate networking tools
- Fewer network hops and reduced latency improves overall performance
- Easier enforcement of security standards
Traefik Enterprise is a unified enterprise-grade solution for ingress and API gateway functionality with a distributed architecture for High availability and enables you to scale with your business needs. With these features in mind, let’s revisit that initial architecture diagram once more and look at how exactly you would use a tool like Traefik Enterprise to be the consolidated ingress and API gateway solution in this type of consolidated network architecture.
Traefik Enterprise leverages the multiple providers that can be used for service discovery — i.e., the ingress definition for your routing rules or an ingress route custom resource. Outside of Kubernetes, Traefik Enterprise leverages a file provider or a KV store to point to your non-Kubernetes workloads while still being able to route all of those different routing rules from a single consolidated ingress rule. It also allows you to handle those API gateway-type functionalities — handling various methods of authentication and authorization through middlewares, handling, automated TLS, termination, and certificate management, as well as rate limiting, and a bunch of other features you would expect from an API gateway.
If you want to learn more about how Traefik Enterprise can help your team reduce infrastructure costs, don’t hesitate to book a demo with us or start your free 30-day trial today!
Secure, manage, & scale all your APIs. Want to simplify API management and security? Request a demo today and see Traefik Enterprise in action.Request a demo
This is a companion discussion topic for the original entry at https://traefik.io/blog/reducing-your-infrastructure-costs-by-consolidating-networking-tools/