Kubernetes: When You Need It And How to Scale It

Whether you’re years deep into the Kubernetes experience or just dipping your toes into the water, there’s no such thing as too much perspective. After all, Kubernetes is poised to become a foundational element of enterprise infrastructure, and it’s evolving fast. Mistakes made today could lead to some gnarly fixes down the road.

That’s why the latest episode of our Cloud & Culture podcast is a must-listen: It features VMware staff architect Josh Rosso discussing some major considerations for organizations to consider as they’re deciding whether to adopt Kubernetes, which distributions and tools to choose, and how to scale from pet project to production cluster (and beyond). Rosso is a particularly valuable source of insights on this topic, having worked at two pioneering Kubernetes startups prior to VMware, and having helped a good number of large banks, retailers, and other large organizations succeed with their enterprise-scale Kubernetes efforts.

Standardized ops for the win

“A lot of these big organizations . . . are really thinking through, ‘How do I standardize on an application platform where we can have this consistent experience to onboard apps and get things deployed and scale them out and have really solid declarative APIs?’

“And I think what a lot of these larger organizations are seeing is Kubernetes is kind of a natural evolution for them to get to that state. And, and to be clear, Kubernetes is part of the puzzle for these groups: Kubernetes is the container orchestrator layer. It’s not like they should be going in and saying, ‘We’re going to introduce Kubernetes and our problems will be solved.’

“More so the problem is, ‘We need to think about how we schedule and think about workload, so we’ll use Kubernetes as that foundational orchestration layer. And then for monitoring, we’ll add this piece in and for source-control management and continuous delivery, we’ll add this GitOps-type flow in with these tools, and so on.’

“. . . I’m very lucky to say I’ve seen a lot of organizations see this process all the way through. And for many of them, they’ve gone from developers putting in a ticket and getting a virtual machine 14 days later, that’s misconfigured, and then they have to open up another ticket so that they can finally get their app on it. They’ve gone from some of those really old legacy models to this completely API-driven, container-based system that has enabled them to ship software a lot faster. It has enabled them to have easier primitives for scaling and monitoring and traceability.

“So it’s a really inspiring direction for most enterprises for most organizations. But I think timing is everything . . . you really have to figure out ‘Is this the right time for you?’.”

An audio excerpt of Rosso discussing how Kubernetes now hosts many stateful workloads.

Platform teams: Remember that devs are your customers

“If you’re building out an application platform on top of [Kubernetes] where you’re going to be having monitoring, maybe a service mesh, maybe X, Y, and Z things to benefit the apps—make sure you’re engaged with your development teams during that process. It might seem obvious, but it’s super sad how many times I go to large organizations that have a build-it-and-they-will-come mentality. And then they wonder why platform adoption kind of lags. It’s because you built something in a silo and you misaligned some of your decisions with what developers actually need and want.”

There’s no free lunch with open source

“If you look at something like the cloud native landscape, there’s tons of logos for all types of projects and products out there. So the one thing that I’m oftentimes telling folks as they scale and choose these different tools is, ‘Really think wisely and honestly about the onus it puts on you to run some of these projects.’ The common thing . . . that people say [is] ‘free as in puppy, not free as in beer’ for open source. It’s very true: open source is free as in puppy.

“Sure, it’s free for you to download and deploy your cluster. But when your container-networking solution . . . breaks down on you, who’s on the hook for solving that problem? Who’s on the hook if a critical bug comes up and sends your production system spiraling? . . . Not that you need enterprise support [which many projects offer], but the question really is: Do you have the operational maturity that when you scale out and something goes wrong, you understand how to work the project, how to work the code, how to fix bugs, how to solve problems? Those are really honest and big things to solve for.”