Kubernetes and Challenges in Cloud-Agnostic Strategies
Stephen Abdo and Pete Tian examine cloud-agnostic strategies and explore common challenges and misconceptions.
Overview and Industry Trends
Over the past several years there has been an increased focus on adopting cloud-agnostic strategies. Some common reasons to do this are to avoid becoming dependent on any one cloud provider and the freedom to pursue a best-of-breed ecosystem. Kubernetes is one technology that has been used to accomplish these goals. Microsoft has even been making more and more PaaS services available in Kubernetes to aid in that effort. However, we sometimes see customers who are not only pursuing a containerization strategy with Kubernetes, but also attempting to achieve a portable solution that targets the Kubernetes offering on all major cloud service providers (CSPs) at the same time (namely, AKS, EKS, and GKE). Achieving this portability is perceived as a strategy to avoid vendor lock-in and to minimize financial risk through negotiating power.
Although to minimize financial risks, the ability to leverage partnerships and discounts from long-term commitments should be considered first, another question remains: does portability minimize technical risk? If an organization is already using Kubernetes and investing in cloud agnostic tooling for provisioning and automation– to what extent is having a solution that is deployable in AKS, EKS, and GKS achievable? What is the return on investment? What level of complexity is an organization capable of handling?
Cloud Agnostic Strategy and Kubernetes
Kubernetes has been evolving since its birth. Open-source communities and cloud service providers are creating add-ons for various purposes like ease of management, feature enhancements, security hardening, and performance improvements. Tools with overlay features from different market competitors provide various options to architects to build their clusters (e.g.- weighing Azure Application Gateway/NGINX Ingress Controller, Azure Active Directory vs Okta).
Understandably, users choose open-source products over cloud native solutions in cloud agnostic context. Thinking beyond a proof of concept (POC), it’s important to consider Operational and Product Support.:
- Is a team self-sustaining with troubleshooting when problems arise on compatibility, updates and conflict of roadmap?
- Is a team willing to dive deep into the product nuances of different cloud service providers?
By definition, being cloud agnostic means your applications should be freely deployable in Kubernetes clusters of different CSPs. Your application must be completely decoupled from the native features and services offered by CSPs. However, Kubernetes is an open framework for CSPs and as well as Open-Source Software enthusiasts to add their own solutions to challenging problems. To facilitate innovation, it does not enforce constraints to minimize risky behaviors that might compromise the security and resiliency of the platform. Therefore, CSPs must create their own native, proprietary solutions to harness the environment and provide the security that their enterprise customers need. So here comes the conundrum in decoupling– are you going to build your own, or use third party solutions to replace the native services?
Staff readiness & Complexity of the solution
Starting from several basic services as a platform, product lines in public clouds are growing rapidly as more customers adopt them in enterprise computing environments. IT professionals work hard to keep up with emerging technologies and products through training or self-education. It’s easily to be overwhelmed by the ocean of training courses if one wants to be an expert on every product from a single CSP. People rarely claim themselves “cloud experts”, rather, experts of certain features or services. Most cloud architecture teams need a group of experts with deep knowledge and wide expertise for any single CSP. The size of a team could be easily triple when tackling platform agnostic architectural design and solution implementation. Challenges are introduced not only to the knowledge level of the tech team, but also the coordination among internal sub-groups in development and deployment processes.
The complexity increases significantly when a new CSP’s platform is added to an enterprise computing eco-system. If we consider the challenges from a decade back with corporate mobile app development –creating business apps for iOS, Android and mobile web simultaneously, there are some similar trends. Building multiple solutions can be expensive, requires a lot of expertise, and are difficult to maintain. At the same time, you might not want to limit a solution to one platform. Cross-platform frameworks attempt to solve this problem, but often cannot support native features that give you better capabilities to compete and differentiate your solution. Similar to cross-platform mobile frameworks, there are plenty of products that are attempting to provide the same abstraction for cloud providers, enabling multi-cloud capabilities with some similar trade-offs.
Unlike mobile devices though, cloud solutions typically don’t depend on end-user hardware. In most cases, users are not even aware of the platform where these apps are running. While you might have to consider decisions like where data resides (regional restrictions) or be required to deploy your solution in a specific CSP determined by your customer, it begs the question –what is the extra value that cross-platform solution brings to your customers and your business? Does that outweigh the benefits and agility of cloud native solutions and the ability to build depth cloud expertise?
Using tools that have not been properly tested and tuned up in an integrated environment
CSPs have an army of development teams to build native solutions on their own platform with rigorous testing in product environments with continuous improvements based on internal and external feedback. Many OSS products built by development communities lack the resources for the same level of test efforts. Enterprise users must exercise due diligence to have OSS software fully tested in their own integrated environment.
One ought to be mindful that third-party monitoring tools are consumers of the clusters, often taxing computing resources. In extreme cases, they may consume more CPU cycles and network bandwidth than the applications that provide direct business value. Assigning the proper portion of computing resource for necessary, but ancillary tooling, may requires many iterations to properly configure and tune in live environments. The learning curve can be lingering as there’s no universal formula.
Things to Consider
A multi-cloud strategy to achieve a high level of portability demands greater investment in tooling, higher organizational and staff readiness, and more defined isolation between the system’s abstraction layers. While being cloud-agonistic is something to consider and evaluate, it should be done on app-by-app basis to balance the effort to value equation. Your enterprise cloud strategy should begin by answering the following:
- Are you mapping your solution’s desired capabilities to the services available from a CSP or a technology?
- Have you considered the cost of a multi-cloud strategy?
- What benefits could a cloud native solution offer in terms of productivity and efficiency?
Light
Dark
0 comments