DEVOPSdigest

Companies want to implement modern applications that can be used anytime, anywhere by always-connected users who demand instant access and improved services. Developing and deploying such applications requires development teams to move fast and deploy software efficiently, while IT teams have to keep pace and also learn to operate at large scale.

While the concept has been around for a couple of decades, containers staged a comeback in the last 3-4 years because they are ideally suited for the new world of massively scalable cloud-native applications. Containers are extremely lightweight, start much faster (than VMs), and use a fraction of the memory compared to booting an entire operating system. More importantly, they enable applications to be abstracted from the environment in which they actually run. Containerization provides a clean separation of concerns, as developers focus on their application logic and dependencies while IT operations teams can focus on deployment and management without bothering with application details.

Deploying and managing containers is still a significant challenge, however. In the past couple of years, Kubernetes burst onto the scene and became the de facto leader as the open-source container orchestrator for deploying and managing containers at scale. The hype has reached such a peak now that there are as many as 30 Kubernetes distribution vendors and over 20 Container-as-a-Service companies out there. All the major public clouds (AWS, Azure, and Google Cloud) provide Container-as-a-Service based on Kubernetes.

With more than 30 Kubernetes solutions in the marketplace, it's tempting to think Kubernetes and the vendor ecosystem has solved the problem of operationalizing containers at scale. Far from it. There are six major pain points that companies experience when they try to deploy and run Kubernetes in their complex environments, and there are also some best practices companies can use to address those pain points.

Pain Point 1 - Enterprises have diverse infrastructures

Bringing up a single Kubernetes cluster on a homogenous infrastructure is relatively easy with the current solutions in the market. But the reality is that organizations have diverse infrastructures using different server, storage, and networking vendors. In this situation, automating infrastructure deployment, setting up, configuring, and upgrading Kubernetes to work consistently is not easy.

One way to address this challenge is to deploy a unifying platform that abstracts the diversity of underlying infrastructure (physical server, storage, and networking) and offers standard open API access to infrastructure resources. This greatly simplifies the IT burden when it comes to provisioning Kubernetes.

Pain Point 2 - One Kubernetes cluster doesn't address all needs

Organizations have diverse applications teams, application portfolios, and sometimes conflicting user requirements. One Kubernetes cluster is not going to meet all of those needs. Companies will need to deploy multiple, independent Kubernetes clusters with possibly different underlying CPU, memory, and storage footprints. If deploying one cluster on diverse hardware is hard enough, doing so with multiple clusters is going to be a nightmare!

To address this pain point, the IT team should be able to set up logical business units that can be assigned to different application teams. This way, each application team gets full self-service capability within quota limits imposed by the IT team, and each team can automatically deploy its own Kubernetes cluster with a few clicks, independently of other teams.

Read 6 Kubernetes Pain Points and How to Solve Them - Part 2