Scaling enterprise Kubernetes adoption

Kubernetes is all the rage — and with good reason: It's a flexible, accessible tool for orchestrating containers and automating deployment. Or at least that's what it says on the box. 

Despite its capabilities, k8s can't automatically solve all your problems. If you want to adopt it successfully at enterprise scale, you need some form of conceptual structure.

So how can you chart a course to cloud success? I've pondered the same question for over a decade at companies like Ernst & Young, PwC India, and Accenture. Here's what I think you should expect, where things can go wrong, and some handy solutions.

The state of enterprise Kubernetes adoption

There's no disputing that Kubernetes is the de-facto standard for cloud computing: A 2022 CNCF survey found that 96 percent of responding organizations were either using it or considering it. While it's not the only — or always the most appropriate — option, it's by far the most popular among enterprises.

So who counts as an enterprise? Although the CNCF says that k8s is making massive inroads everywhere, including emerging markets, we'll focus on the big players, like General Electric, Walmart, and United Health Group. These adopters bring a unique perspective to the table — one you probably won't see at a high-performing startup with only 100 coders or engineers. 

Larger enterprises share many common features, like multiple locations, hundreds of teams that don't always communicate, and globally distributed workforce hierarchies with clear labor divisions. It's the perfect mix of ingredients for a complicated, challenging adoption process!

Defining scale

One common characteristic of enterprise-level K8s adoption efforts is that they tend to happen at scale.

Most big organizations aren't just setting up a few clusters here and there. Instead, they're embarking on full-fledged digital transformations where decisions can impact hundreds of teams and thousands of engineers. To complicate things further, they also move at extremely high velocity.

Facing the learning curve

Many enterprises that start with Kubernetes adopt a kind of learn-as-you-go attitude. The prevalence of online resources and the infrastructural control devs enjoy make it easy for a team to dive in and start building. Unfortunately, this approach has serious downsides. 

After creating something new, pioneers typically evangelize about their great experiences. This leads to more teams self-onboarding the same way: organically and without much central governance. 

Eventually, things start to break. What comes next? The organization is left holding the pieces with no real understanding of why. 

This all-too-common scenario dissuades new adopters. It also contributes to the widespread but erroneous perception that Kubernetes is too hard to be worthwhile. 

I like to call this the "Great Kubernetes Divide." Teams work in silos and find it very hard to cross the gap to reach an ideal state — one where everyone's on the same page regarding patterns, practices, and guidelines. 

Why scaling K8s is hard

Make no mistake: Scaling Kubernetes is tough partially because Kubernetes itself is tough. 

I've also seen a few challenges inherent to how people use k8s:

• There aren't many well-tested, enterprise-grade platforms for managing Kubernetes. 
• Kubernetes is young enough that many organizations haven't invested in the material and human resources needed to achieve genuine mastery. 
• Loosely coupled, stateless, distributed applications based on microservices — a primary use case — take more skill to maintain than monoliths. 
• Best practices for k8s are still maturing.

9 smart solutions for fixing your adoption 

Fortunately, there's an alternative to traveling down the path to a doomed adoption — in fact, there are nine of them:

1. Work toward standardization

Enforce standardization at the cluster and team levels. Every cluster your enterprise provisions ought to start from the same template, script, or automation pipeline, and your devs shouldn't deviate from approved baselines. 

Another way to put this is that your teams should never have to write their own scripts to set up or operate new clusters. Of course, that raises the obvious question of how to achieve maintainable, flexible standards, which brings up my next solution... 

2. Empower self-service

I usually advise building an internal IT service catalog or marketplace that accommodates devs' need to create, manage, and maintain clusters. Your teams must be able to use these tools easily by logging in to a convenient visual portal, picking their preferred k8s parameters, and deploying with minimal hassle.

Achieving this right away isn't always practical, but that doesn't mean you shouldn't strive to get there eventually. A smart move involves populating your self-service catalog with widely used offerings to facilitate the highest possible level of developer autonomy. For instance, you might include options like scaling clusters, creating service accounts, provisioning standalone clusters, and other routine tasks.

3. Build a catalog of k8s offerings

It's critical to build a thorough understanding of your target users. For instance, different projects might require unique services, like dedicated clusters for production and non-production environments or shared clusters with on-demand namespaces for smaller applications. 

Keep your catalog flexible by ensuring it features sufficiently configurable options. Instead of mandating practices — which will likely fail — learn what most of your business users need early and start with those demands to prevent devs from seeking suboptimal alternatives.

4. Create a k8s center of excellence

Cultivate a central governance team directly responsible for management, oversight, and operation of k8s workloads. Taking this vital step will help you control what happens across your entire enterprise. 

Your governance team is the source of both thought leadership and support — not just one or the other. It'll devise guidelines and enforce architectural best practices that set the tone for your entire organization. It should evangelize and encourage proper adoption by maintaining training materials, holding workshops, and providing developer guidance. Finally, it ought to centrally manage and review all your clusters to enforce required security, continuity, and other standards. 

This step often gets overlooked due to budget constraints and other reasons, but it's critical to successful adoption and better developer experiences. Without a Center of Excellence (or whatever you decide to call it) it'll be extremely hard for anyone to take ownership, hindering your forward progress.

5. Create a documentation repo for k8s consumption

Knowledge promotion is another essential role of your governance team. In addition to fundamentals, like how to get started, this repository needs to include best practices, tutorials, and other guides.

As with everything the governance team does, enhancing the developer experience must be a constant theme. Many enterprises publish general knowledge guides that focus on infrastructure or DevOps and call it a day. Take things a step further by addressing real-world situations — like how devs should troubleshoot services, connect to clusters from their laptops, and surmount other known hurdles. 

6. Centralize management of cross-cutting concerns

Some concerns are broadly applicable to all of your enterprise projects. For instance, disaster recovery, compliance, service discovery, and log aggregation are just a few areas where everyone in your organization needs to satisfy certain minimum standards.

As I touched on earlier, managing these universal concerns is a job for your governance team. The flawed alternative is to leave these issues to the individual teams, but remember: While the front-liners should still have ownership and accountability, you're better off handling these big-ticket items uniformly, and that means centrally.

7. Establish a consistent support model

In addition to or as part of your governance team, you should create a centralized SRE or k8s operations team. These stakeholders will manage and monitor workloads, and they need to do so as consistently as possible. 

In many real-world cases, this equates to some kind of 24/7 support model. How you do it and the level of service you provide are up to you, but the support team should have ownership over keeping the k8s platform running smoothly.

8. Support containerized application development and deployment through automation

Automation is a cornerstone of most successful k8s adoptions because it augments your ability to support typical development and deployment tasks. There's a huge difference, however, between simply automating things and being able to orchestrate containerized applications well.

Being able to deploy standardized clusters is just part of the picture. Your automation should also facilitate the easy deployment of containers and management of pods on these clusters. For instance, you might make proven CI/CD pipelines readily available or store hardened container images in an enterprise-wide repo. 

The common theme here is to go beyond supporting the infrastructure itself. Take a holistic, end-to-end view of the broader process. Once again, you want to keep people from doing things from scratch.

9. Central governance and compliance

By now, you should get that governance and compliance benefit from centralization, but what does this look like? In practice, your core governance team will not only manage concerns like security but also bear responsibility for how policies make it to the clusters — ideally by being pushed from a central repository. 

Tools like Helm charts, automation, and different pipeline components play a big role here, but don't get confused. The differentiator isn't your deployment process: It's the code itself. 

As mentioned earlier, the process should be standardized, including how you propagate security and other policies. From there, individual customers can enact supplemental, granular changes as needed.

Four final takeaways

Keep these big-picture concepts in mind as you pursue the previous objectives:

• Structure your central governance team properly: Hire the right talent. Support healthy collaboration with your product engineering teams, architecture practice, cloud solution practice, and other workforce divisions. 
• Aim for cloud-agnosticism: Keeping your enterprise k8s offerings and components cloud-agnostic boosts adoption and keeps people from straying off-path.
• Think beyond workloads and focus on the developer experience: The cluster isn't the primary focus. Consider the entire k8s journey — from IDE integrations to CI/CD pipelines: Your internal developer platform is one of your most important assets.
• Solicit buy-in: When high-level leaders get invested in a particular approach, dev teams naturally align to follow. 

Sticking to these four rules can make your scaling journey far more rewarding. There are many paths to successful Kubernetes adoption, so it's up to you to assess what fits your situation. Proactively building a rigorous conceptual and operational framework is the best way to thrive at enterprise scale.