Kubernetes Clusters: Buy, Rent , or DIY

Published on March 14, 2024 | 4 Mins Read

Imagine you are in the middle of a meeting in which everyone is bringing in their opinions, biases, and justifications on whether to build, buy, or abandon any efforts when it comes to Kubernetes.

You carefully decided to wait to gather all the different perspectives and share your experiences. From your previous role, you learned that building clusters from scratch is a time-consuming and engineering challenge endeavor but it pays off in the long term by having more flexibility, control, and cost efficiency.  Also, it requires Kubernetes-savvy engineers who are willing to roll up their sleeves and solve problems as there’s not much support except from the community. 

On the other hand, you noticed your colleagues debating using one of the cloud providers' managed services to use them on-demand or buying one of the enterprise solutions from vendors such as Mirantis Kubernetes Engine, Red Hat OpenShift, or VMware Tanzu and hosting them wherever it makes sense.

The meeting is about to end and no decision has been made. The committee decided to meet again in a few weeks to gather notes and develop recommendations for the business unit. While the corporate enterprise team has a cloud-first approach, they allow every business unit to decide when it comes to building, buying, or where to host.

The good news is that you’re not alone. Many IT executives are in the same boat as there are many factors to consider before deciding on this matter.  In this guide, I discuss five key factors to consider when deciding. A simple decision tree is shown here to guide you and your team throughout the decision-making process.

View fullsize

1. Use Options to Face Off Complexity

The classical way of thinking in the enterprise is deciding between build vs. buy(or not)  isn’t very effective here since there are so many things to look into including the type of apps you’re running, whether they’re mission or business-critical, and security and compliance among other things. 

In a business unit in a mid-sized or large enterprise, we are talking about hundreds if not thousands of different applications and it’s unlikely there is one size fits all. 

An alternative way of thinking is to look at this as a range or spectrum giving options to the teams to choose from based on the different factors as follows:

• Do It Yourself (DIY)

• Vendor Managed 

• Cloud Managed Service 

• Cloud + Vendor 

• No Option 

The last one  “No Option” here is intentional. Sometimes, the team or organization is not ready for an enterprise-level adoption of Kubernetes or it’s not a good fit for the type of applications used.  Using the crawl, walk, and run approach here is helpful. Starting with application containers without necessarily using any orchestration might be a good starting point and then assessing down the road if running application containers at scale is a feasible idea and hence considering Kubernetes.  

2. Kubernetes Expertise and  Engineering Effort 

Lack of training is among the biggest challenges in using and deploying containers, according to the CNCF 2022 annual survey. You carefully want to consider your team's skill level and experience building and running application containers, Kubernetes, and cloud native technologies.

When working with teams in enterprise companies, looking at several data points can give an idea of the team’s capabilities:

• Contributors to CNCF projects 

• Past enterprise-level projects building or running application containers in production  

• Past experiences working at companies in the cloud native ecosystem

• Engineers with the Kubernetes  certifications

Contribution to CNCF projects is powerful as the team members get to build skills, relationships, and most importantly the tenacity to roll up their sleeves and submit a pull request to fix an issue and vote for a new feature. Plus, it’s a good sign that this learning team can hack the code and fix the issue.

Past experiences and projects also help to be familiar with the overall ecosystem and understand the different challenges with cloud native. This means the team worked with containers in production and that’s an irreplaceable experience.

Unquestionably, there is no substitute for hands-on experience. However, pursuing Kubernetes certifications helps to keep the team skills up to date and maintain a baseline of knowledge to build on.

3. Cost Efficiency 

Although Kubernetes is open source, it requires a reasonable amount of time, effort, and investment to build, maintain, and operate given the value businesses capture from it. When talking about cost, we have to consider the total costs involved including but not limited to skilled staff, licensing, auxiliary tooling, infrastructure, operations, training, tech support,...etc.  

Also, keep in mind that this is going to be a long-term investment as it can take 6 to 24 months or even more to start realizing value in an enterprise environment running containers at scale on Kubernetes. 

Although DIY seems the cheapest option and provides the utmost flexibility, it requires a tremendous amount of engineering effort and comes with a high risk of not delivering on time and within budget.  

On the other hand, a cloud or managed service enables teams to focus on development and ease day 2 operations. For many, this is half the battle. However, associated cloud costs are rising and you might want to curb Kubernetes cloud costs. 

Not paying attention to cost from the outset and having an approach and tooling to monitor and measure it can prove disastrous and lead to shying away from Kubernetes.

4. Security & Compliance

We don't talk about Kubernetes without looking into Security & Compliance. Many believe that Kubernetes is wide open and insecure by default.  The bottom line is that It boils down to your risk level.  For example, running a cluster that’s exposed to the public internet is more vulnerable than running a cluster behind the firewall or in an air-gapped environment.

Today, misconfiguration is one of the top cloud security threats. Bad actors love to exploit a vulnerability or an ill-patched system to gain access to data and Kubernetes isn’t an exception since there are many components, YAML files,..etc that increase the opportunity for misconfiguration.

There have been tremendous efforts on cloud native security lately given that’s one of the common ways to build and operate modern software. For example, CNCF published the Cloud Native Security Whitepage and the software supply chain best practices paper. 

Also, US government agencies like the National Security Agency (NSA) and the Cybersecurity and Infrastructure Security Agency(CISA) jointly published a Kubernetes hardening guidance. 

This is particularly important for companies in regulated industries such as banking, financial services, and insurance that are more vulnerable to cyberattacks.    

5. Focus on Core Business:

It’s naive to think that in an enterprise setting, a unified solution is going to be adopted across the board. Although having similar solutions might eventually make it easier to control costs, and become more efficient, there are always going to be different requirements, needs, and use cases. 

By opting for a managed Kubernetes service, you can offload some of the operational overhead and focus on your core business objectives, leaving the infrastructure management to the vendor or cloud provider. 

For some companies who are planning to invest heavily in Kubernetes in the future, building a Center of Excellence (CoE) might be feasible. This is usually an internal team of cross-functional contributors including a solution architect, product manager, DevOps engineer,  and SRE engineer working together to stay on top of Kubernetes and cloud native trends to fulfill the Kubernetes-related needs of teams across the enterprise. 

Not all organizations need to build a CoE or a platform team to be successful with Kubernetes. However, it’s particularly important to decide from the outset whether to invest in building one or focus on the core business by delivering products and services and ultimately value back to the business stakeholders. 

For some teams, building their own Kubernetes clusters is a journey worth taking that eventually enables them to control performance, operational cost, features, and capabilities. For others, the operational nightmare that comes with managing a production cluster is not worth it. 

At the end of the day, there’s no right or wrong.  We should provide options to different teams in the enterprise to consume  Kubernetes in any way they desire. In the meantime,  we should have a set of guiding principles to enforce security and compliance while focusing on the business value and supporting the teams to improve their skills. 

Ready to discuss this further? Feel free to share your comments and ideas or schedule a free assessment to talk about your journey. 

---