The following is an excerpt from our white paper on The Edge Experience – Streamlining Multi-Cluster Kubernetes Deployment & Management.
Complexity is frequently cited as one of the main challenges in adopting a multi-cluster topology, and the more distributed that topology, the more complex it can be to manage. This creates a conundrum, because as explained in our earlier paper, the more distributed your multi-cluster environment, the more benefits you reap.
Take latency, for example. This is one of the most important considerations for user experience, and one of the factors that’s directly impacted by edge computing. Simply put, the closer your application is to your user base, the more responsive that workload will be to user requests. This holds true regardless of whether your base is concentrated in a single region or spread globally; but the broader the distribution, the more latency and workload placement need to be carefully considered.
Yet no less an authority than Google says that, while latency is one of the biggest factors in selecting compute regions (so important, they say, that you should regularly reevaluate and rebalance regions to reduce latency), concern over complexity can prevent addressing this issue. According to Google’s Best Practices for Region Selection “Even if your app serves a global user base, in many cases, a single region is still the best choice. The lower latency benefits [of distribution] might not outweigh the added complexity of multi-region deployment.”
Clearly, complexity (and inherent cost) is a major challenge for distributed deployments, particularly when those deployments are federated – so much so that it can prevent organizations from making decisions that are clearly in their best interest. Where does this complexity come from?
Two factors are in play. The first involves the tools and processes that are used to run the application workload itself in a multi-cluster Kubernetes deployment. The second is the management and operation of the underlying edge network, which gets progressively more complicated and cost-sensitive as distribution (across regions and networks/operators) increases.
While there is considerable overlap in a modern DevOps environment, the development team (the app owner) tends to be more focused on the process pipeline, while the operations team (the infrastructure owner) wrestles with cluster management and network optimization.
Image source: edureka
Both are important to how organizations manage overall application delivery, and each has its own complexity challenges to overcome.
Application Deployment at the Edge – The Developer View
Moving application workloads to the edge differs from a centralized cloud deployment on two vectors: first, it’s multi-cluster instead of single cluster, and second, it’s distributed (and as part of that, often federated across different regions/operators). From a developer’s perspective, this distributed multi-cluster Kubernetes deployment impacts four elements of application ownership:
- CI/CD Integration
- Cluster Discovery
- Orchestration and Failover Between Clusters
- Credential Management
Application Management at the Edge – the Ops View
Not surprisingly, managing multiple distributed clusters is much more complex than managing a centralized deployment, especially as those clusters spread across regions and operators in a federated environment. The things that ops teams are concerned about include:
- Cluster Connection and Tracking
- End-to-End Security
- Policy Lock-Down (RBAC, etc.)
- Resource Management
For deeper insight on these challenges, and how you can dramatically simplify deployment, please read the paper on Streamlining Multi-Cluster Kubernetes Deployment and Management – or even better, talk with someone at Section!
