Are You Ready For Ingress-as-a-Service?

If you’ve ever deployed an app to Kubernetes, you’ve likely experienced firsthand the complexities of configuring and integrating Kubernetes with the tools necessary to make your app available to the outside world. Defining the traffic authorized to access your application can be especially confusing, even when using an ingress controller. Most Kubernetes ingress controllers today are self-managed—meaning that a lot of complicated configuration falls on you—but the future looks bright for ingress-as-a-service.

Why as-a-Service?

When was the last time you popped a DVD into a DVD player to watch a movie? Are you hanging onto all your old CDs, or have you completely transitioned to listening to music using a streaming service?

These days, like many consumers, most companies use third-party providers to manage email and workflow applications and leverage single sign-on solutions for security. The cloud itself is the ultimate as-a-service model, shifting the procurement and maintenance of hardware as well as myriad software services to cloud vendors.

For businesses, consuming a service rather than implementing it yourself offers many benefits, including:

• Reduced costs—Your IT team doesn’t incur the overhead of managing the service in-house, and you can pay for only what you use with pay-as-you-go subscription plans.
• Instant scalability—You can easily scale your workloads while allowing the third party to handle the necessary provisioning of resources. Additionally, you can typically scale faster when consuming a service than when rolling out new resources yourself.
• Instant expertise—You can take advantage of a vendor’s expertise in a particular area rather than developing an in-house expert, so your team can focus on your own core competencies.
• Operational agility: There’s no need to deploy, provision, configure and maintain any software in-house. You can scale your consumption up or down, equipping you with a high degree of flexibility.

Ingress-as-a-Service?

It’s likely you’ve outsourced at least some of your application’s critical functions, such as authentication and authorization, payment procurement and processing and logging and observability. Maybe you’re using infrastructure or database services hosted and managed by someone else. With so many utilities being consumed as a service, why not use ingress-as-a-service, too?

With ingress-as-a-service, you still need to install a controller in your Kubernetes cluster, but the service provider takes care of provisioning your resources in their network rather than your own, and you have far less to manage.

Ingress-as-a-service offers all the benefits of any other as-a-service offering. Let’s explore these benefits as they relate to ingress.

Enhanced Security and Resiliency

With ingress-as-a-service, the service provider intercepts traffic before it ever reaches your origin network, providing robust protection for your applications running in Kubernetes.

The service manages traffic ingestion, OAuth, load balancing and TLS termination on the provider’s network and only forwards authenticated traffic to your cluster. These functions execute on a global network with thousands of points-of-presence (PoPs), isolating your Kubernetes cluster from any unwanted traffic and mitigating the risk of a distributed denial-of-service (DDoS) attack. Additionally, since this global network sits closer to your customers, they will enjoy faster speeds, resulting in a superior user experience. Furthermore, with geo-aware load balancing and failover capabilities, you can ensure high availability to your apps. If an entire PoP is unavailable, client traffic is rerouted to another PoP that is operational.

Reduced Complexity

Ingress-as-a-service handles your networking and security configurations, reducing errors due to misconfigurations.

Since the service provider handles the network configuration for your cluster, developers don’t need to bother with the nuances of which IP addresses and subnets are at play or how to configure load balancers. The best part is that ingress-as-a-service works even if your cluster sits behind a NAT. Getting access to a cluster behind a NAT typically involves installing and configuring multiple pieces of software, but with ingress-as-a-service, it just works!

With a self-managed ingress controller, you’ll also need to install a separate certificate manager, whereas with ingress-as-a-service, your provider handles certificate management for you. The ingress service provider can also handle DNS, or you can integrate with external DNS servers. You can take certificate management, DNS and load balancers off the list of things you have to think about.    

With ingress-as-a-service, the provider usually manages the integration with various OAuth providers, allowing you to easily plug and play different authentication modules using annotations in your Kubernetes manifest file. You also have the flexibility to configure your own OAuth application, if you prefer. You decide the level of control and responsibility you want to push to the ingress service provider versus what you want to manage yourself.

Decreased Risk of Vendor Lock-In

Ingress-as-a-service provides a vendor-agnostic traffic management solution. The ingress controller can be deployed to any Kubernetes cluster on any platform, regardless of the cloud provider, since the provisioning of resources is handled by the service provider.

For example, an ingress controller in AWS may integrate with an Amazon Elastic Load Balancer (ELB), while an ingress controller in GCP might use a Google Cloud Load Balancer. Each of these load balancers has its own bespoke configurations, which means developers and DevOps teams have to build and maintain separate configurations for each environment where their apps are deployed. With ingress-as-a-service, not only can you use the same configuration with different cloud providers, but you can run it locally as well, creating a more seamless development experience. If you’re using AWS or GCP load balancers, you’re locked into running only in those environments, not to mention the fact that cloud load balancers can become very expensive, and spinning up new instances can take a considerable amount of time.

Ingress-as-a-service decouples your cluster’s north-south configuration from the environment where it runs. There’s no need to maintain configurations for each environment. You can achieve environment independence and portability with ingress-as-a-service.

Deliver production-grade apps with ingress-as-a-service

With the increase in security and reduction in complexity, ingress-as-a-service provides a better experience for your developers and your customers. All sorts of activities, from video streaming to note-taking, can be consumed as a service. Why wouldn’t you want to reap those same benefits with your Kubernetes ingress? Expect to see ingress-as-a-service offerings expand over the next few years.

To hear more about cloud-native topics, join the Cloud Native Computing Foundation and the cloud-native community at KubeCon+CloudNativeCon North America 2023 – November 6-9, 2023.