The Kubernetes Hierarchy of Needs – InApps 2022

I’ve been fortunate enough in my career to work alongside some of the brightest minds and cutting edge companies in Silicon Valley. For the last few years, Kubernetes has dominated the mindshare of my customers. Most engineers I know are scrambling to work on Kubernetes projects to be a part of the movement and increase their market value. But even with this mad rush towards adoption of Kubernetes, I’ve witnessed many of these projects fall far short of achieving their original objective.

The fact of the matter is that Kubernetes is complicated. The ecosystem is rapidly evolving. This leads many teams to shift their focus to the tech stack. Teams end up debating each individual component and/or CNCF project, rather than shipping a product to their customer and iterating based on feedback.

Amongst all these failures, patterns have begun to emerge from the Kubernetes deployments that are successful — more specifically, the methodologies these companies used to take an idea from whiteboard to production. I have consolidated these learnings into what I call the “Kubernetes Hierarchy of Needs.”

The Kubernetes Hierarchy of Needs isn’t focused on individual technology components, it is a system of procedures that keeps teams focused on customer deliverables and aligned to achieve business success. The purpose is to stay one layer above the ever-changing landscape of underlying technologies and focus solely on identifying the phases that need to be addressed to get Kubernetes deployed and code out the door and in production.

The Kubernetes Hierarchy of Needs is made up of three sequential phases: Build, Deploy, Operate. The sequence is absolutely critical in building momentum. During each stage, a minimum viable product (or demonstrable function) has to be validated by your customer before moving on to the next phase. This accomplishes three things:

1. Serves as a forcing function to focus on deliverables versus individual technologies.
2. Rallies support from the business and your customers through the achievement of well-defined milestones.
3. Creates clear expectations between your team and key stakeholders, resulting in a continuous feedback loop necessary to drive progress and efficiency.

Let’s take a look at each phase of the hierarchy in more detail.

Build Infrastructure: You’ve got to get Kubernetes deployed. Not only does this serve as the first milestone to demonstrate progress, but it also gives you the first real-world experience for how to operate and interact with the system. You and your team will learn the nomenclature, building the credibility you’ll need to relate to and teach the Devs you’ll onboard during the deployment stage. At this point, it doesn’t matter whether you choose to deploy vanilla Kubernetes or a managed service like GKE. It’s all about getting to a state where services can be on-boarded.

Too often, I’ve seen developers try to answer later-stage questions before they have even built their Kubernetes environment. “Should I integrate with Istio? How will we provide service discovery across clusters across data centers?” Tackling these questions introduces unnecessary complexity.

Remember, this stage is all about delivering a usable cluster, and demonstrating your team’s mastery of its components. The faster you do so, the more credibility your team will have, and the more your customers will want to work with you.

Deploy Applications: This is where you start thinking about how your customers are going to provision applications on the platform. Prior to building anything, work with your customer to define base requirements. Then build to spec.

For example, if it’s a 12-factor, stateless app, then no need to immediately offer a solution for storage persistence. Rather than focusing on how you’ll address tenancy, first address how your users will interact with the API and push code. CICD pipelines will become relevant once you understand the lifecycle of the app and the capacity of your customer.

Surprisingly, in many instances, the application team is experiencing microservices for the first time while transitioning to Kubernetes. This is a huge opportunity for you and your team to serve as a guide. Keep the tech simple to make this process easier to debug and optimize. Don’t enforce processes or tool usage that may create additional learning curves.

If your customer isn’t excited to work with you, they’ll abandon the platform, impacting your team’s brand and your ability to recruit other internal customers.

Operate: Congratulations! Your users can now push code freely and are raving about the velocity in which they can experiment and implement changes. And you’ve been smart about who you onboard to the platform, making sure that your team understands customer requirements, only onboarding applications that are a good fit for existing platform functionality and scale.

Unfortunately, your job isn’t finished. You are now experiencing the downsides of microservices firsthand. If your team is organized like most that I’ve worked with, the core architects and SREs are on-call for every alert that hits PagerDuty. You’ve found that most of these metric-based alerts are no longer relevant. They are being triggered by other services that they depend on. Not to mention, it’s the wild wild west for SLOs, and you’ll be working hand-in-hand with application teams to define them. During an incident, you’ll find that much of the frustration will be in just locating the custom dashboards for each service to verify SLIs. This end result will be some of the largest war-rooms you’ve ever been a part of.

Don’t let this happen to you. Here, you’ll want to prioritize your incident response and establish SLOs. Work with your customer to develop a clear understanding of how your customer monitors their app, which workflows are most important, and if they have associated (and accurate) SLOs. No longer will your team be able to be an expert on the nuances and failure patterns of each service.

There are mature technologies and CNCF projects out there for logging and metrics, both still playing important roles in these environments. Tracing has also picked up a lot of steam in the monitoring of microservices, because of its ability to provide end-to-end visibility, dependency charts, and performance analysis. The best customers I’ve worked with have designed observability data pipelines and best practices to enable service owners to build higher-performing, more resilient applications. You may actually determine that you’re only going to be responsible for monitoring the infrastructure. That’s okay too, but make sure expectations are set out of the gate.

That brings me back to what brought us here initially. There was a business reason that funded this project in the first place. At the end of the day, it’s about delivering customer experiences faster.

Think about it from the business side. When your company decides to release a new product, they base it on customer requirements. These requirements drive prioritization of the features they deliver. There is a shared understanding of what will be delivered when, and customer feedback and adoption informs what will come next. Early product adoption drives continued investment and the evolution of the product. Treat your platform the same way. Use the Kubernetes Hierarchy of Needs to stay customer-focused and deliver a platform that delivers real customer value.

Feature image via Pixabay.