Densify announces SaaS for automating Kubernetes resource optimization
Densify announces Kubex, which leverages mutating admission controllers to automatically right-size containers and manages Kubernetes resources from a single control point.
The solution addresses the pervasive challenge of resource misallocation in Kubernetes environments, where containers are frequently over-provisioned or under-provisioned, offering immediate cost savings without manual intervention.
Relevant links
Transcription
Bart: I'm Andrew Hillier, and I work for Densify. My role is focused on helping organizations optimize their cloud and Kubernetes resource utilization.
Andrew: Hi, I'm Andrew Hillier, I'm the CTO and one of the co-founders of Densify.
Bart: I noticed that the transcript snippet is very short and doesn't contain much context. Could you provide the full transcript or more context about what Andrew Hillier wants to share today? Without more information, I cannot confidently apply hyperlinks.
Andrew: We're here at KubeCon in London. One of the new things we're showing is our latest automation capability on our product called Kubex. It's based on a mutating admission controller that lets you automate the right-sizing of containers and the management of resources in a very simple way. Just turn on the mutation, and it will take care of everything from one central point.
Bart: I noticed that the transcript snippet is incomplete. Could you provide the full context of Andrew Hillier's explanation about Kubex and its automation component? Without the full context, I cannot confidently hyperlink terms or provide a comprehensive answer.
Andrew: We see in general a lot of over-provisioning and under-provisioning in Kubernetes environments. Many containers have high CPU requests, high or low memory requests, or no memory requests at all. We often find problems with limits either not being set or being too low, which causes out-of-memory kills. In any environment we analyze, we find these problems across clusters.
The goal is to fix these issues. While you could manually adjust resource numbers in the repository, that's not something people want to do. This new mutating admission controller allows centralized control. It interfaces with our analytics, which are intelligent and understand what changes are appropriate. Some modifications might be too aggressive, especially if nodes are running low on memory. These nuances are factored into the analytics.
The new controller will automatically apply these intelligent recommendations as containers deploy. This approach saves time by avoiding the need to interface with multiple application teams, especially in development environments where overriding resources for efficiency is acceptable. We see similar challenges in production environments as well. Ultimately, it provides centralized Kubernetes optimization instead of wasting time coordinating with dozens of application teams.
Bart: I noticed that the provided transcript snippet is incomplete and lacks context. Could you provide the full transcript or more surrounding text so I can properly analyze and apply the hyperlinking guidelines?
Andrew: Before, we see people have a strong desire to fix these things. They've deployed our Terraform module, which works well, but still requires interfacing with different repos and modifying things in the pipeline. With this announcement, the capability provides a central control point to make changes. We've had a customer, for example, enable it in the morning. It was turned on, mutating, and bringing request values down. When those requests decrease, in environments like Karpenter or AKS, the nodes will automatically consolidate. If you turn on the automation, the container requests go down, the nodes go down, and the money-saving starts immediately. That's one of the beautiful aspects: when you turn it all on, it just starts to get better right away.
Bart: I noticed that the transcript you provided is actually empty or missing. Could you please share the full transcript text so I can apply the hyperlinking guidelines and edit it appropriately?
Andrew: Kubex is not open source, but two of its main components are. The analytics are SaaS-based and hosted in the cloud. However, the data forwarder that runs in your Kubernetes cluster to get Prometheus and Node Exporter data is open source. You can inspect it and see what it's doing. The mutating admission controller is also open source. Anything that runs in a customer environment and touches customer data is open source, so you can verify exactly what it's going to do and compile it yourself if you want. The main body remains a SaaS-based service.
Bart: I noticed that the transcript snippet is very short and doesn't provide much context about Densify's business model. Could you provide more details from the transcript to help me identify terms for hyperlinking?
Andrew: We work on a subscription model. The pricing is per virtual CPU, and all details are on our website. For a certain size environment, the cost is very predictable. You can use it monthly or yearly, with yearly subscriptions offering lower prices. Most customers sign up for a year or multiple years to get a better rate.
You can license different components, including a cloud optimization component and a Kubernetes optimization component. These components work together, so when you're running Kubernetes, it will optimize both the Kubernetes cluster and the cloud nodes it's running on. It's a flexible, SaaS-based subscription model.
Bart: Who are your main competitors?
Andrew: There are a number of companies around here that do similar things. In fact, I was just chatting with the StormForge folks earlier today. Cast.ai is over there. They do similar things, albeit a bit differently. They all have different strengths and weaknesses. Some are more of a Node Autoscaler, like ScaleOps, PerfectScale, and SEDAI.
We all have our different strengths. If you ask each of us, we'll probably tell you what we're better at. But it's nice having company in the space because it indicates you're in the right place—it's a problem people are trying to solve.
I've seen a difference myself. A year or two ago, I'd be evangelizing that companies probably have this resource problem. Now people seem to understand when they walk up to our booth. They know they have a cost problem and are looking for how to fix and automate it. This makes our life easier when people are aware of the problem, rather than us constantly trying to tell them it exists.
Having other companies in the space is great. It just means it's a good neighborhood to be in.
Bart: I notice the transcript snippet is very short and doesn't provide much context about Kubex and Densify's differentiation. I would need more context to create meaningful hyperlinks. Could you provide more of the surrounding conversation?
Andrew: One of the things we're very good at is deep ML-based analysis of container workload patterns. We really go to town on characterizing exactly what they're doing for replicated workloads, scale sets, and HPA. We look at all the replicas and understand what they're doing through a very strong policy model.
We can say, how exactly do we want to treat this workload? Do we want to size the limit based on the busiest replica, or set the request based on the average of all nodes? We can do a lot of statistical control around startup spikes and other scenarios.
We feel that getting the right answer is a precursor to automation because you don't want to automate the wrong answer—that's a disaster. We start with the precision of our analysis and getting the right answer. Then we can automate it or implement it however you want. Without the right answer, it's emotionally satisfying but practically useless.
We have seen problems where customers automate a bad solution from a product, which can cause issues like HPA scaling wildly. So we try to make sure what we do is right first, and then automate it—as opposed to the approach of some other companies.
Bart: If people want to find out more information about this product, they should go to the Densify website.
Andrew: If you go to Densify, all our information is there. I recommend going there because we have a new sandbox where you can click around and try the product. You can sign up for a trial or simply use the product with demo data. You don't have to connect it to anything. You can explore the features and automation screens. We encourage you to try out the sandbox, which is a great place to start. There are also lots of other information and resources available. My contact information is on the site if you have any questions.