Kubernetes tools, auto-scaling strategies, and managing complexity

Bart: So, first things first: Who are you? What's your role? And where do you work?

In this transcript, I would link the company name to its website:

So, first things first: Who are you? What's your role? And where do you work at StormForge?

Reid: My name is Reid Vandewiele. I currently have the product lead role at StormForge. I recently transitioned from an engineering position and now lead product strategy. We specialize in automated right-sizing for pods and Kubernetes.

Bart: What are three Kubernetes emerging tools that you are keeping an eye on?

Reid: Three technologies I'm paying attention to right now are DRA and in-place pod resizing. These are directly relevant to what we do. I'm also paying attention to FinOps.org's FOCUS specification, which is an open specification for normalizing cloud usage data. They're about to add shared cost allocation to the spec. I'm paying attention to this because Kubernetes typically involves shared costs when examining bills.

Bart: Now, our podcast guest, Reid, is not a huge fan of Helm, because you don't necessarily know what changes will result in. What's your experience with Helm? Do you share similar concerns?

Reid: My experience with Helm is from when I was responsible for maintaining StormForge's Helm chart for distributing our software to on-prem customers. I have a mixed relationship with Helm. I think it's a great tool for some use cases. If you're a software vendor wanting to deliver software to someone else, it allows you to create a simplified and tailored user experience.

The problem with Helm is similar to C++ in the old days: as long as you know what not to do with it, Helm is great. I only fell in love with it after I realized how many things I should never try to do with it. I needed to keep it very simple.

Bart: Now, another guest of ours, Thibault, said before we had the Vertical Pod Autoscaler, resource management was a nightmare. What is your experience with resource management challenges before implementing automation?

Reid: We have an interesting relationship with right-sizing, as automated right-sizing is the focus of what we do. Before we had our own tool, we used Cluster Autoscaler for cluster right-sizing, but we didn't have anything for vertical scaling. We're essentially a managed service provider with one stack per customer, and every customer is unique.

The utilization of our stack varies widely. We have customers with hundreds of clusters and thousands of nodes that we're automating systems for, and others doing a free trial with just one cluster on their laptop. The usage profiles are vastly different.

Prior to automation, we would pick a standard t-shirt size across the board and manually respond when issues arose in larger clusters as usage ramped up. This approach was primarily driven by cost considerations. The typical tactic was to ensure reliability by sizing resources large enough to prevent problems, but this still required significant developer time to address issues as they emerged.

Bart: Thibault believes that auto-scaling is great because it provides relevant trade-offs, allowing you to fine-tune for good stability, efficiency, and response time. What's your advice on auto-scaling Kubernetes clusters?

Reid: I first want to say, Thibaut's interview was really interesting because he was describing a problem that occurred as a result of his auto-scaling VPA going haywire, but he was still a big fan of auto-scaling. The main advice is that it is still work. You're never going to completely get out of paying attention to resource utilization. However, auto-scaling lets you put it on autopilot. Autopilot is actually a great analogy: when you're cruising down the highway with cruise control, you can't stop paying attention, but it allows you to focus on many more things.

My advice for people looking at auto-scaling is to consider three dimensions: cluster auto-scaling, horizontal auto-scaling, and vertical auto-scaling. Pay attention to all three. There are great solutions out there, especially open-source options. For cluster auto-scaling, Carpenter is pretty amazing, with many people having great success. VPA, KEDA, and HPA are very mature at this point. Vertical scaling is a bit trickier—that's why we're trying to make it simpler for people. All three dimensions can bring value. It's not magic, but you still have to pay attention. It's worth looking into.

Bart: Kubernetes turned 10 years old last year. What can we expect in the next 10 years to come?

Reid: I'm laser-focused on what I'm doing right now, so I haven't looked up to see far ahead in a while. But if I were to hazard a guess, I really hope they buckle down on complexity. Kubernetes is incredibly powerful. The model of distributed complex systems is really interesting and, from a computer science background, engaging. Especially with AI coming onto the scene, I think we're going to see that many complicated tasks, like auto-scaling, will become simpler. I'm hoping that as Kubernetes matures, the complexity cost will be ratcheted lower and lower over time.

Bart: How can people get in touch with you?

Reid: Probably the best way to contact me is LinkedIn. I'm Reid Vandewiele and I'm pretty easy to find—there aren't many people with this name combination. I don't pay much attention to social media, so LinkedIn is best. Alternatively, you can probably find my email on the company website. I currently work for StormForge.

Bart: And last thing, can we add what's next for StormForge?

Reid: StormForge was acquired by CloudBolt in April. We used to focus just on right sizing, paying attention to CPU and memory usage. We're now looking at GPU, which is the next big thing for us next quarter. Whenever we talk to people about right sizing, they also want to know about costs. The CloudBolt merger gives us access to billing data. So the next thing for StormForge is probably combining all of that. We're not only going to automate right sizing, but we'll also be able to provide reporting on what that's actually costing in real dollars.

Potential additional context links:

• Vertical Pod Autoscaler (related to right sizing)

• Dynamic Resource Allocation (for GPU considerations)

• FinOps.org (for cost optimization context)