Running Kubernetes in the public cloud is great. It’s easy and quick to get started with, integrates with other cloud services like object storage or existing VM-based applications, and takes away most of the work to create and maintain the Kubernetes clusters. However, using a public cloud service for Kubernetes is like getting a big box full of Lego. All the building blocks to create something beautiful are there, but you have to choose what you want to create, design it, build it, and manage it yourself. It’s not ‘Kubernetes-as-a-Service’.
And while for Kubernetes itself, that isn’t a major problem; but an enterprise container platform is so much more than just Kubernetes. Kubernetes doesn’t include identity and authentication, logging, monitoring, distributed tracing, network security, pipeline security, ingress networking, service mesh, secrets management and more itself; you need to add solutions on top of Kubernetes for each of these.
Simply put: you need all these elements to successfully adopt a Kubernetes-based platform in your enterprise, but it makes little sense to build this yourself. It’s just too complicated, and creating a one-off, unique-to-your-organization platform doesn’t have the economies of scale to be successful in the long run. The cost of toil and upkeep, lifecycle management, the complexity and the fragility of creating a one-off platform are just too high, and you’ll end up with a platform that will not deliver on the potential of Kubernetes, while being too expensive, sucking up engineering time that you’d rather spend on innovating and creating new applications, be insecure and non-compliant.
And so, we are at a crossroads with Kubernetes. Outsourcing it to the public cloud only solves the Kubernetes-specific part of the puzzle, and leaves you DIY’ing the rest. Many of the experimental, developer-led DIY platforms fail to scale across different teams and different use cases in the enterprise, due to the DIY platform’s complexity and difficulty to operationalize, upgrade and keep the lights on. In addition to being expensive to manage and operate a single, purpose-built platform, there’s also the ‘bus factor’ risk of being dependent on specific staff members. What happens when they get hit by a bus, or more realistically, leave? Reliability, security, cost-effectiveness and scalability were not enough to persuade IT Ops and DevOps teams to make the switch.
And this is where the friction with Kubernetes in the enterprise lies. It has a massive potential to unlock business value for digital products and services, but the toil of operationalizing Kubernetes at scale distracts engineers from realizing that business value. This complexity is what kills time-to-market and flexibility, creating future technical debt, and decreases developer productivity.
This is what makes the difference between a DIY-approach, and reclaiming the cognitive load and engineering capacity to work on more business-related projects. A true enterprise-ready container-based platform will take care of more than just Kubernetes, including the suite of development and operational tools to build and run cloud-native applications.
In addition to offering a complete suite of tools, a platform like this will take away the guesswork of creating your own unique platform, so you don’t have to worry about which tools to use, nor do you have to find the right experts to design, implement and manage your platform for you. And don’t forget, most users just want to use the functionality of a Kubernetes-based platform, regardless of which tools actually comprise the platform. Simply put: they would be happy to use an opinionated platform that makes considered, thought-through decisions.
One such platform is Mirantis Container Cloud, an opinionated Kubernetes-as-a-Service platform.
It is a feature-complete, cloud-agnostic approach to building and running cloud-native applications. It helps organizations leverage Open Source across on-prem, public cloud providers and service providers in an on-demand, self-service Kubernetes-as-a-Service experience. Check the link above to read about the 7 key requirements when choosing a solution to address cloud-native challenges today.
