With the release of Webscale CloudFlow’s patented Kubernetes Edge Interface (KEI), it’s important to step back and look at why organizations need a solution that makes it easy to move application workloads to the edge. What are the benefits of distributed multi-cluster Kubernetes topologies over centralized cloud or data center deployments for modern organizations? Granted KEI makes it simple, but why go through the effort at all?
We recently published a white paper on modernizing applications with distributed multi-cluster Kubernetes that dives deep into these topics, discussing everything from topology definitions to differing application architecture approaches. But at its heart, it outlines seven key benefits to distributed multi-cluster deployments. In this post, we’ll explore the first three. Stay tuned for the final four… or feel free to check out the white paper to read ahead.
As noted in the white paper, organizations who have embarked on the path of containerizing their applications are faced with many decisions around how and where to deploy their containerized workloads. Many follow a maturity model that is characterized by a series of progressive transitions from single cluster to centralized multi-cluster to distributed multi-cluster to, ultimately, multi-region edge deployments. The question is: why? What are the advantages and benefits of a distributed topology over centralized clusters? As importantly, does the breadth of distribution matter? Are organizations that adopt a multi-region, multi-provider approach gaining advantage over those that don’t?
Let’s dive in.
Availability and Resiliency
By mirroring workloads across clusters, you increase availability and resiliency through elimination of single points of failure. At its most basic level, this means using a secondary cluster as a backup or failover should another cluster fail. As you increase cluster distribution outside of a single data center/cloud instance to stretch across clouds and providers, you further minimize risk – from failure of single endpoints within a provider network, or even failure of an entire provider network – by ensuring your application can fail over to other endpoints or providers.
Every year there are reports of wide swaths of the internet ‘going dark’ and taking down well-known brands and applications. Invariably, those issues are traced back to problems within a particular provider network. Distributed multi-cluster deployments help mitigate those risks.
Vendor Lock-in
Avoiding reliance on a single vendor is an operational mantra for many organizations, making the ability to distribute workloads not only across locations, but across providers a key advantage. This multi-vendor approach improves pricing flexibility, as well as ensuring better continuity and quality of service. Similarly, this can help mitigate data lock-in, whereby it can become prohibitively expensive to migrate data off a provider’s network.
In fact, a distributed multi-cluster, multi-vendor approach even helps mitigate managed Kubernetes lock-in, ensuring you are not committed to a particular provider’s version of Kubernetes and any proprietary extensions supported by a specific provider’s managed Kubernetes service.
Performance and Latency
According to a recent survey of IT decision makers by Lumen, 86% of organizations identify application latency as a key differentiator. And the single best way to reduce latency is to reduce geographic distance by physically placing applications closer to the user base.
Distributed multi-cluster Kubernetes facilitates this strategy, allowing organizations to use an edge topology to process data and application interactions closer to the source. This becomes especially important – in fact, arguably a necessity – for applications that have a global user base, where multi-region edge deployments can geographically distribute workloads to best reduce latency while efficiently managing resources (e.g. spinning up/down infrastructure to adapt to “follow the sun” or other regional and ad hoc traffic patterns).
Organizations that elect a centralized approach are, by definition, treating users outside of the primary geography as second-class citizens when it comes to application performance. In fact, this is the primary consideration when organizations choose a particular cloud instance for deployment (e.g. AWS EC2 US-East): where are most of my users based, so those within or close to that region will enjoy a premium experience? The unspoken corollary is that as customers get geographically further from that particular region, application performance, responsiveness, resilience and availability will naturally degrade. In short, this is the default “good enough” cloud deployment for application workloads that cater largely to a home-grown user base. As these applications mature and broaden adoption, this strategy becomes increasingly tenuous, and organizations find themselves compelled to move workloads to the edge.
Check out the final four benefits in our next blog post – or, if you’ve heard enough and you’re ready to get started, drop us a line and let us show you with Webscale CloudFlow how easy it can be to move to the edge using your familiar Kubernetes tools, workflows and processes.
