>> Instructor: "theCUBE" presents KubeCon and CloudNativeCon Europe 2022, brought to you by Red Hat, the Cloud Native Computing Foundation and its ecosystem partners. >> Welcome to Valencia, Spain and we're at KubeCon, CloudNativeCon Europe 2022. I'm Keith Townsend, and my co-host, Enrico Signoretti. Enrico's really proud of me. I've called him Enrico instead of Enrique every session. >> Every day. >> Senior IT analyst at GigaOm. We're talking to fantastic builders at KubeCon, CloudNativeCon Europe 2022 about the projects and their efforts. Enrico, up to this point, it's been all about provisioning, insecurity, what conversation have we been missing? >> Well, I mean, I think that we passed the point of having the conversation of deployment, of provisioning. Everybody's very skilled, actually everything is done at day two. They are discovering that, well, there is a security problem. There is an observability problem a and in fact, we are meeting with a lot of people and there are a lot of conversation with people really needing to understand what is happening. I mean, in their cluster work, why it is happening and all the questions that come with it. And the more I talk with people in the show floor here or even in the various sessions is about, we are growing so that our clusters are becoming bigger and bigger, applications are becoming bigger as well. So we need to now understand better what is happening. As it's not only about cost, it's about everything at the end. >> So I think that's a great set up for our guests, Matt Provo, founder and CEO of StormForge and Patrick Brixton? >> Bergstrom. >> Bergstrom. >> Yeah. >> I spelled it right, I didn't say it right, Bergstrom, CTO. We're at KubeCon, CloudNativeCon where projects are discussed, built and StormForge, I've heard the pitch before, so forgive me. And I'm kind of torn. I have service mesh. What do I need more, like what problem is StormForge solving? >> You want to take it? >> Sure, absolutely. So it's interesting because, my background is in the enterprise, right? I was an executive at UnitedHealth Group before that I worked at Best Buy and one of the issues that we always had was, especially as you migrate to the cloud, it seems like the CPU dial or the memory dial is your reliability dial. So it's like, oh, I just turned that all the way to the right and everything's hunky-dory, right? But then we run into the issue like you and I were just talking about, where it gets very very expensive very quickly. And so my first conversations with Matt and the StormForge group, and they were telling me about the product and what we're dealing with. I said, that is the problem statement that I have always struggled with and I wish this existed 10 years ago when I was dealing with EC2 costs, right? And now with Kubernetes, it's the same thing. It's so easy to provision. So realistically what it is, is we take your raw telemetry data and we essentially monitor the performance of your application, and then we can tell you using our machine learning algorithms, the exact configuration that you should be using for your application to achieve the results that you're looking for without over-provisioning. So we reduce your consumption of CPU, of memory and production which ultimately nine times out of 10, actually I would say 10 out of 10, reduces your cost significantly without sacrificing reliability. >> So can your solution also help to optimize the application in the long run? Because, yes, of course-- >> Yep. >> The lowering fluid as you know optimize the deployment. >> Yeah. >> But actually the long-term is optimizing the application. >> Yes. >> Which is the real problem. >> Yep. >> So, we're fine with the former of what you just said, but we exist to do the latter. And so, we're squarely and completely focused at the application layer. As long as you can track or understand the metrics you care about for your application, we can optimize against it. We love that we don't know your application, we don't know what the SLA and SLO requirements are for your app, you do, and so, in our world it's about empowering the developer into the process, not automating them out of it and I think sometimes AI and machine learning sort of gets a bad rap from that standpoint. And so, at this point the company's been around since 2016, kind of from the very early days of Kubernetes, we've always been, squarely focused on Kubernetes, using our core machine learning engine to optimize metrics at the application layer that people care about and need to go after. And the truth of the matter is today and over time, setting a cluster up on Kubernetes has largely been solved. And yet the promise of Kubernetes around portability and flexibility, downstream when you operationalize, the complexity smacks you in the face and that's where StormForge comes in. And so we're a vertical, kind of vertically oriented solution, that's absolutely focused on solving that problem. >> Well, I don't want to play, actually. I want to play the devils advocate here and-- >> You wouldn't be a good analyst if you didn't. >> So the problem is when you talk with clients, users, there are many of them still working with Java, something that is really tough. I mean, all of us loved Java. >> Yeah, absolutely. >> Maybe 20 years ago. Yeah, but not anymore, but still they have developers, they have porting applications, microservices. Yes, but not very optimized, et cetera, cetera, et cetera. So it's becoming tough. So how you can interact with this kind of old hybrid or anyway, not well engineered applications. >> Yeah. >> We do that today. We actually, part of our platform is we offer performance testing in a lower environment and stage and we, like Matt was saying, we can use any metric that you care about and we can work with any configuration for that application. So perfect example is Java, you have to worry about your heap size, your garbage collection tuning and one of the things that really struck me very early on about the StormForge product is because it is true machine learning. You remove the human bias from that. So like a lot of what I did in the past, especially around SRE and performance tuning, we were only as good as our humans were because of what they knew. And so, we kind of got stuck in these paths of making the same configuration adjustments, making the same changes to the application, hoping for different results. But then when you apply machine learning capability to that the machine will recommend things you never would've dreamed of. And you get amazing results out of that. >> So both me and Enrico have been doing this for a long time. Like, I have battled to my last breath the argument when it's a bare metal or a VM, look, I cannot give you any more memory. >> Yeah. >> And the argument going all the way up to the CIO and the CIO basically saying, you know what, Keith you're cheap, my developer resources are expensive, buy bigger box. >> Yeah. >> Yap. >> Buying a bigger box in the cloud to your point is no longer a option because it's just expensive. >> Yeah. >> Talk to me about the carrot or the stick as developers are realizing that they have to be more responsible. Where's the culture change coming from? Is it the shift in responsibility? >> I think the center of the bullseye for us is within those sets of decisions, not in a static way, but in an ongoing way, especially as the development of applications becomes more and more rapid and the management of them. Our charge and our belief wholeheartedly is that you shouldn't have to choose. You should not have to choose between costs or performance. You should not have to choose where your applications live, in a public private or hybrid cloud environment. And so, we want to empower people to be able to sit in the middle of all of that chaos and for those trade offs and those difficult interactions to no longer be a thing. We're at a place now where we've done hundreds of deployments and never once have we met a developer who said, "I'm really excited to get out of bed and come to work every day and manually tune my application." One side, secondly, we've never met, a manager or someone with budget that said, please don't increase the value of my investment that I've made to lift and shift us over to the cloud or to Kubernetes or some combination of both. And so what we're seeing is the converging of these groups, their happy place is the lack of needing to be able to make those trade offs, and that's been exciting for us. >> So, I'm listening and looks like that your solution is right in the middle in application performance, management, observability. >> Yeah. >> And, monitoring. >> Yeah. >> So it's a little bit of all of this. >> Yeah, so we want to be, the intel inside of all of that, we often get lumped into one of those categories, it used to be APM a lot, we sometimes get, are you observability or and we're really not any of those things, in and of themselves, but we instead we've invested in deep integrations and partnerships with a lot of that tooling 'cause in a lot of ways, the tool chain is hardening in a cloud native and in Kubernetes world. And so, integrating in intelligently, staying focused and great at what we solve for, but then seamlessly partnering and not requiring switching for our users who have already invested likely, in a APM or observability. >> So to go a little bit deeper. What does it mean integration? I mean, do you provide data to this, other applications in the environment or are they supporting you in the work that you do. >> Yeah, we're a data consumer for the most part. In fact, one of our big taglines is take your observability and turn it into action ability, right? Like how do you take that, it's one thing to collect all of the data, but then how do you know what to do with it, right? So to Matt's point, we integrate with folks like Datadog, we integrate with Prometheus today. So we want to collect that telemetry data and then do something useful with it for you. >> But also we want Datadog customers, for example, we have a very close partnership with Datadog so that in your existing Datadog dashboard, now you have-- >> Yeah. >> The StormForge capability showing up in the same location. >> Yep. >> And so you don't have to switch out. >> So I was just going to ask, is it a push pull? What is the developer experience when you say you provide developer this resolve ML learnings about performance, how do they receive it? Like, what's the developer experience. >> They can receive it, for a while we were CLI only, like any good developer tool. >> Right. >> And, we have our own UI. And so it is a push in a lot of cases where I can come to one spot, I've got my applications and every time I'm going to release or plan for a release or I have released and I want to pull in observability data from a production standpoint, I can visualize all of that within the StormForge UI and platform, make decisions, we allow you to set your, kind of comfort level of automation that you're okay with. You can be completely set and forget or you can be somewhere along that spectrum and you can say, as long as it's within, these thresholds, go ahead and release the application or go ahead and apply the configuration. But we also allow you to experience the same, a lot of the same functionality right now, in Grafana, in Datadog and a bunch of others that are coming. >> So I've talked to Tim Crawford who talks to a lot of CIOs and he's saying one of the biggest challenges or if not, one of the biggest challenges CIOs are facing are resource constraints. >> Yeah. >> They cannot find the developers to begin with to get this feedback. How are you hoping to address this biggest pain point for CIOs-- >> Yeah.6 >> And developers? >> You should take that one. >> Yeah, absolutely. So like my background, like I said at UnitedHealth Group, right. It's not always just about cost savings. In fact, the way that I look about at some of these tech challenges, especially when we talk about scalability there's kind of three pillars that I consider, right? There's the tech scalability, how am I solving those challenges? There's the financial piece 'cause you can only throw money at a problem for so long and it's the same thing with the human piece. I can only find so many bodies and right now that pool is very small, and so, we are absolutely squarely in that footprint of we enable your team to focus on the things that they matter, not manual tuning like Matt said. And then there are other resource constraints that I think that a lot of folks don't talk about too. Like, you were talking about private cloud for instance and so having a physical data center, I've worked with physical data centers that companies I've worked for have owned where it is literally full, wall to wall. You can't rack any more servers in it, and so their biggest option is, well, I could spend $1.2 billion to build a new one if I wanted to, or if you had a capability to truly optimize your compute to what you needed and free up 30% of your capacity of that data center. So you can deploy additional name spaces into your cluster, like that's a huge opportunity. >> So I have another question. I mean, maybe it doesn't sound very intelligent at this point, but, so is it an ongoing process or is it something that you do at the very beginning, I mean you start deploying this. >> Yeah. >> And maybe as a service. >> Yep. >> Once in a year I say, okay, let's do it again and see if something change it. >> Sure. >> So one spot, one single.. >> Yeah, would you recommend somebody performance test just once a year? Like, so that's my thing is, at previous roles, my role was to do performance test every single release, and that was at a minimum once a week and if your thing did not get faster, you had to have an executive exception to get it into production and that's the space that we want to live in as well as part of your CICD process, like this should be continuous verification, every time you deploy, we want to make sure that we're recommending the perfect configuration for your application in the name space that you're deploying into. >> And I would be as bold as to say that we believe that we can be a part of adding, actually adding a step in the CICD process that's connected to optimization and that no application should be released, monitored, and sort of analyzed on an ongoing basis without optimization being a part of that. And again, not just from a cost perspective, but for cost and performance. >> Almost a couple of hundred vendors on this floor. You mentioned some of the big ones Datadog, et cetera, but what happens when one of the up and comings out of nowhere, completely new data structure, some imaginative way to click to telemetry data. >> Yeah. >> How do, how do you react to that? >> Yeah, to us it's zeros and ones. >> Yeah. >> And, we really are data agnostic from the standpoint of, we're fortunate enough from the design of our algorithm standpoint, it doesn't get caught up on data structure issues, as long as you can capture it and make it available through one of a series of inputs, one would be load or performance tests, could be telemetry, could be observability, if we have access to it. Honestly, the messier the better from time to time from a machine learning standpoint, it's pretty powerful to see. We've never had a deployment where we saved less than 30%, while also improving performance by at least 10%. But the typical results for us are 40 to 60% savings and 30 to 40% improvement in performance. >> And what happens if the application is, I mean, yes Kubernetes is the best thing of the world but sometimes we have to, external data sources or, we have to connect with external services anyway. >> Yeah. >> So, can you provide an indication also on this particular application, like, where the problem could be? >> Yeah. >> Yeah, and that's absolutely one of the things that we look at too, 'cause it's, especially when you talk about resource consumption it's never a flat line, right? Like depending on your application, depending on the workloads that you're running it varies from sometimes minute to minute, day to day, or it could be week to week even. And so, especially with some of the products that we have coming out with what we want to do, integrating heavily with the HPA and being able to handle some of those bumps and not necessarily bumps, but bursts and being able to do it in a way that's intelligent so that we can make sure that, like I said, it's the perfect configuration for the application regardless of the time of day that you're operating in or what your traffic patterns look like, or, what your disc looks like, right. Like 'cause with our low environment testing, any metric you throw at us, we can optimize for. >> So Matt and Patrick, thank you for stopping by. >> Yeah. >> Yes. >> We can go all day because day two is I think the biggest challenge right now, not just in Kubernetes but application re-platforming and transformation, very, very difficult. Most CTOs and EASs that I talked to, this is the challenge space. From Valencia, Spain, I'm Keith Townsend, along with my host Enrico Signoretti and you're watching "theCube" the leader in high-tech coverage. (whimsical music)

>>The cube presents, Coon and cloud native con Europe 22, brought to you by the cloud native computing foundation. >>Welcome to Melissa Spain. And we're at cuon cloud native con Europe, 2022. I'm Keith Townsend. And my co-host en Rico senior Etti en Rico's really proud of me. I've called him en Rico and said IK, every session, senior it analyst giga, O we're talking to fantastic builders at Cuban cloud native con about the projects and the efforts en Rico up to this point, it's been all about provisioning insecurity. What, what conversation have we been missing? >>Well, I mean, I, I think, I think that, uh, uh, we passed the point of having the conversation of deployment of provisioning. You know, everybody's very skilled, actually everything is done at day two. They are discovering that, well, there is a security problem. There is an observability problem. And in fact, we are meeting with a lot of people and there are a lot of conversation with people really needing to understand what is happening. I mean, in their classroom, what, why it is happening and all the, the questions that come with it. I mean, and, uh, the more I talk with, uh, people in the, in the show floor here, or even in the, you know, in the various sessions is about, you know, we are growing, the, our clusters are becoming bigger and bigger. Uh, applications are becoming, you know, bigger as well. So we need to know, understand better what is happening. It's not only, you know, about cost it's about everything at the >>End. So I think that's a great set up for our guests, max, Provo, founder, and CEO of storm for forge and Patrick Britton, Bergstrom, Brookstone. Yeah, I spelled it right. I didn't say it right. Berg storm CTO. We're at Q con cloud native con we're projects are discussed, built and storm forge. I I've heard the pitch before, so forgive me. And I'm, I'm, I'm, I'm, I'm, I'm kind of torn. I have service mesh. What do I need more like, what problem is storm for solving? >>You wanna take it? >>Sure, absolutely. So it it's interesting because, uh, my background is in the enterprise, right? I was an executive at United health group. Um, before that I worked at best buy. Um, and one of the issues that we always had was, especially as you migrate to the cloud, it seems like the CPU dial or the memory dial is your reliability dial. So it's like, oh, I just turned that all the way to the right and everything's hunky Dory. Right. Uh, but then we run into the issue like you and I were just talking about where it gets very, very expensive, very quickly. Uh, and so my first conversations with Matt and the storm forge group, and they were telling me about the product and, and what we're dealing with. I said, that is the problem statement that I have always struggled with. And I wish this existed 10 years ago when I was dealing with EC two costs, right? And now with Kubernetes, it's the same thing. It's so easy to provision. So realistically, what it is is we take your raw telemetry data and we essentially monitor the performance of your application. And then we can tell you using our machine learning algorithms, the exact configuration that you should be using for your application to achieve the results that you're looking for without over provisioning. So we reduce your consumption of CPU of memory and production, which ultimately nine times outta 10, actually I would say 10 out of 10 reduces your cost significantly without sacrificing reliability. >>So can your solution also help to optimize the application in the long run? Because yes, of course, yep. You know, the lowing fluid is, you know, optimize the deployment. Yeah. But actually the long term is optimizing the application. Yes. Which is the real problem. >>Yep. So we actually, um, we're fine with the, the former of what you just said, but we exist to do the latter. And so we're squarely and completely focused at the application layer. Um, we are, uh, as long as you can track or understand the metrics you care about for your application, uh, we can optimize against it. Um, we love that we don't know your application. We don't know what the SLA and SLO requirements are for your app. You do. And so in, in our world, it's about empowering the developer into the process, not automating them out of it. And I think sometimes AI and machine learning sort of gets a bad wrap from that standpoint. And so, uh, we've at this point, the company's been around, you know, since 2016, uh, kind of from the very early days of Kubernetes, we've always been, you know, squarely focused on Kubernetes using our core machine learning, uh, engine to optimize metrics at the application layer, uh, that people care about and, and need to need to go after. And the truth of the matter is today. And over time, you know, setting a cluster up on Kubernetes has largely been solved. Um, and yet the promise of, of Kubernetes around portability and flexibility, uh, downstream when you operationalize the complexity, smacks you in the face. And, uh, and that's where, where storm forge comes in. And so we're a vertical, you know, kind of vertically oriented solution. Um, that's, that's absolutely focused on solving that problem. >>Well, I don't want to play, actually. I want to play the, uh, devils advocate here and, you know, >>You wouldn't be a good analyst if you didn't. >>So the, the problem is when you talk with clients, users, they, there are many of them still working with Java with, you know, something that is really tough. Mm-hmm <affirmative>, I mean, we loved all of us loved Java. Yeah, absolutely. Maybe 20 years ago. Yeah. But not anymore, but still they have developers. They are porting applications, microservices. Yes. But not very optimized, etcetera. C cetera. So it's becoming tough. So how you can interact with these kind of yeah. Old hybrid or anyway, not well in generic applications. >>Yeah. We, we do that today. We actually, part of our platform is we offer performance testing in a lower environment and stage. And we like Matt was saying, we can use any metric that you care about and we can work with any configuration for that application. So the perfect example is Java, you know, you have to worry about your heap size, your garbage collection tuning. Um, and one of the things that really struck, struck me very early on about the storm forage product is because it is true machine learning. You remove the human bias from that. So like a lot of what I did in the past, especially around SRE and, and performance tuning, we were only as good as our humans were because of what they knew. And so we were, we kind of got stuck in these paths of making the same configuration adjustments, making the same changes to the application, hoping for different results. But then when you apply machine learning capability to that, the machine will recommend things you never would've dreamed of. And you get amazing results out of >>That. So both me and an Rico have been doing this for a long time. Like I have battled to my last breath, the, the argument when it's a bare metal or a VM. Yeah. Look, I cannot give you any more memory. Yeah. And the, the argument going all the way up to the CIO and the CIO basically saying, you know what, Keith you're cheap, my developer resources expensive, my bigger box. Yep. Uh, buying a bigger box in the cloud to your point is no longer a option because it's just expensive. Talk to me about the carrot or the stick as developers are realizing that they have to be more responsible. Where's the culture change coming from? So is it, that is that if it, is it the shift in responsibility? >>I think the center of the bullseye for us is within those sets of decisions, not in a static way, but in an ongoing way, especially, um, especially as the development of applications becomes more and more rapid. And the management of them, our, our charge and our belief wholeheartedly is that you shouldn't have to choose, you should not have to choose between costs or performance. You should not have to choose where your, you know, your applications live, uh, in a public private or, or hybrid cloud environment. And so we want to empower people to be able to sit in the middle of all of that chaos and for those trade-offs and those difficult interactions to no, no longer be a thing. You know, we're at, we're at a place now where we've done, you know, hundreds of deployments and never once have we met a developer who said, I'm really excited to get outta bed and come to work every day and manually tune my application. <laugh> One side, secondly, we've never met, uh, you know, uh, a manager or someone with budget that said, uh, please don't, you know, increase the value of my investment that I've made to lift and shift us over mm-hmm <affirmative>, you know, to the cloud or to Kubernetes or, or some combination of both. And so what we're seeing is the converging of these groups, um, at, you know, their happy place is the lack of needing to be able to, uh, make those trade offs. And that's been exciting for us. So, >>You know, I'm listening and looks like that your solution is right in the middle in application per performance management, observability. Yeah. And, uh, and monitoring. So it's a little bit of all of this. >>So we, we, we, we want to be, you know, the Intel inside of all of that, mm-hmm, <affirmative>, we don't, you know, we often get lumped into one of those categories. It used to be APM a lot. We sometimes get a, are you observability or, and we're really not any of those things in and of themselves, but we, instead of invested in deep integrations and partnerships with a lot of those, uh, with a lot of that tooling, cuz in a lot of ways, the, the tool chain is hardening, uh, in a cloud native and, and Kubernetes world. And so, you know, integrating in intelligently staying focused and great at what we solve for, but then seamlessly partnering and not requiring switching for, for our users who have already invested likely in a APM or observability. >>So to go a little bit deeper. Sure. What does it mean integration? I mean, do you provide data to this, you know, other applications in, in the environment or are they supporting you in the work that you >>Yeah, we're, we're a data consumer for the most part. Um, in fact, one of our big taglines is take your observability and turn it into actionability, right? Like how do you take the it's one thing to collect all of the data, but then how do you know what to do with it? Right. So to Matt's point, um, we integrate with folks like Datadog. Um, we integrate with Prometheus today. So we want to collect that telemetry data and then do something useful with it for you. >>But, but also we want Datadog customers. For example, we have a very close partnership with, with Datadog, so that in your existing data dog dashboard, now you have yeah. This, the storm for capability showing up in the same location. Yep. And so you don't have to switch out. >>So I was just gonna ask, is it a push pull? What is the developer experience? When you say you provide developer, this resolve ML, uh, learnings about performance mm-hmm <affirmative> how do they receive it? Like what, yeah, what's the, what's the, what's the developer experience >>They can receive it. So we have our own, we used to for a while we were CLI only like any good developer tool. Right. Uh, and you know, we have our own UI. And so it is a push in that, in, in a lot of cases where I can come to one spot, um, I've got my applications and every time I'm going to release or plan for a release or I have released, and I want to take, pull in, uh, observability data from a production standpoint, I can visualize all of that within the storm for UI and platform, make decisions. We allow you to, to set your, you know, kind of comfort level of automation that you're, you're okay with. You can be completely set and forget, or you can be somewhere along that spectrum. And you can say, as long as it's within, you know, these thresholds, go ahead and release the application or go ahead and apply the configuration. Um, but we also allow you to experience, uh, the same, a lot of the same functionality right now, you know, in Grafana in Datadog, uh, and a bunch of others that are coming. >>So I've talked to Tim Crawford who talks to a lot of CIOs and he's saying one of the biggest challenges, or if not, one of the biggest challenges CIOs are facing are resource constraints. Yeah. They cannot find the developers to begin with to get this feedback. How are you hoping to address this biggest pain point for CIOs? Yeah. >>Development? >>Just take that one. Yeah, absolutely. That's um, so like my background, like I said, at United health group, right. It's not always just about cost savings. In fact, um, the way that I look about at some of these tech challenges, especially when we talk about scalability, there's kind of three pillars that I consider, right? There's the tech scalability, how am I solving those challenges? There's the financial piece, cuz you can only throw money at a problem for so long. And it's the same thing with the human piece. I can only find so many bodies and right now that pool is very small. And so we are absolutely squarely in that footprint of, we enable your team to focus on the things that they matter, not manual tuning like Matt said. And then there are other resource constraints that I think that a lot of folks don't talk about too. >>Like we were, you were talking about private cloud for instance. And so having a physical data center, um, I've worked with physical data centers that companies I've worked for have owned where it is literally full wall to wall. You can't rack any more servers in it. And so their biggest option is, well, I could spend 1.2 billion to build a new one if I wanted to. Or if you had a capability to truly optimize your compute to what you needed and free up 30% of your capacity of that data center. So you can deploy additional name spaces into your cluster. Like that's a huge opportunity. >>So either out of question, I mean, may, maybe it, it doesn't sound very intelligent at this point, but so is it an ongoing process or is it something that you do at the very beginning mean you start deploying this. Yeah. And maybe as a service. Yep. Once in a year I say, okay, let's do it again and see if something changes. Sure. So one spot 1, 1, 1 single, you know? >>Yeah. Um, would you recommend somebody performance tests just once a year? >>Like, so that's my thing is, uh, previous at previous roles I had, uh, my role was you performance test, every single release. And that was at a minimum once a week. And if your thing did not get faster, you had to have an executive exception to get it into production. And that's the space that we wanna live in as well as part of your C I C D process. Like this should be continuous verification every time you deploy, we wanna make sure that we're recommending the perfect configuration for your application in the name space that you're deploying >>Into. And I would be as bold as to say that we believe that we can be a part of adding, actually adding a step in the C I C D process that's connected to optimization and that no application should be released monitored and sort of, uh, analyzed on an ongoing basis without optimization being a part of that. And again, not just from a cost perspective, yeah. Cost end performance, >>Almost a couple of hundred vendors on this floor. You know, you mentioned some of the big ones, data, dog, et cetera. But what happens when one of the up and comings out of nowhere, completely new data structure, some imaginable way to click to elementry data. Yeah. How do, how do you react to that? >>Yeah. To us it's zeros and ones. Yeah. Uh, and you know, we're, we're, we're really, we really are data agnostic from the standpoint of, um, we're not, we we're fortunate enough to, from the design of our algorithm standpoint, it doesn't get caught up on data structure issues. Um, you know, as long as you can capture it and make it available, uh, through, you know, one of a series of inputs, what one, one would be load or performance tests, uh, could be telemetry, could be observability if we have access to it. Um, honestly the messier, the, the better from time to time, uh, from a machine learning standpoint, um, it, it, it's pretty powerful to see we've, we've never had a deployment where we, uh, where we saved less than 30% while also improving performance by at least 10%. But the typical results for us are 40 to 60% savings and, you know, 30 to 40% improvement in performance. >>And what happens if the application is, I, I mean, yes, Kubernetes is the best thing of the world, but sometimes we have to, you know, external data sources or, or, you know, we have to connect with external services anyway. Mm-hmm <affirmative> yeah. So can you, you know, uh, can you provide an indication also on, on, on this particular application, like, you know, where the problem could >>Be? Yeah, yeah. And that, that's absolutely one of the things that we look at too, cuz it's um, especially when you talk about resource consumption, it's never a flat line, right? Like depending on your application, depending on the workloads that you're running, um, it varies from sometimes minute to minute, day to day, or it could be week to week even. Um, and so especially with some of the products that we have coming out with what we want to do, you know, partnering with, uh, you know, integrating heavily with the HPA and being able to handle some of those bumps and not necessarily bumps, but bursts and being able to do it in a way that's intelligent so that we can make sure that, like I said, it's the perfect configuration for the application regardless of the time of day that you're operating in or what your traffic patterns look like. Um, or you know, what your disc looks like, right? Like cuz with our, our low environment testing, any metric you throw at us, we can, we can optimize for. >>So Madden Patrick, thank you for stopping by. Yeah. Yes. We can go all day. Because day two is I think the biggest challenge right now. Yeah. Not just in Kubernetes, but application replatforming and re and transformation. Very, very difficult. Most CTOs and S that I talked to, this is the challenge space from Valencia Spain. I'm Keith Townsend, along with my host en Rico senior. And you're watching the queue, the leader in high tech coverage.

(bright upbeat music) >> According to the latest survey from Enterprise Technology Research, container orchestration is the number one category as measured by customer spending momentum. It's ahead of AIML, it's ahead of cloud computing, and it's ahead of robotic process automation. All of which also show highly elevated levels of customer spending velocity. Now, we drill deeper into the survey of more than 1200 CIOs and IT buyers, and we find that a whopping 70% of respondents are spending more on Kubernetes initiatives in 2022 as compared to last year. The rise of Kubernetes came about through a series of improbable events that change the way applications are developed, deployed and managed. Very early on Kubernetes committers chose to focus on simplicity in massive adoption rather than deep enterprise functionality. It's why initially virtually all activity around Kubernetes focused on stateless applications. That has changed. As Kubernetes adoption has gone mainstream, the need for stronger enterprise functionality has become much more pressing. You hear this constantly when you attend the various developer conference, and the talk is all around, let's say, shift left to improve security and better cluster management, more complete automation capabilities, support for data-driven workloads and very importantly, vastly better application performance in visibility and management. And that last topic is what we're here to talk about today. Hello, this is Dave Vellante, and welcome to this special CUBE conversation where we invite into our East Coast Studios Matt Provo, who's the founder and CEO of StormForge and Chandler Hoisington, the general manager of EKS Edge in Hybrid at AWS. Gentlemen, welcome, it's good to see you. >> Thanks. >> Thanks for having us. >> So Chandler, you have this convergence, you've got application performance, you've got developer speed and velocity and you've got cloud economics all coming together. What's driving that convergence and why is it important for customers? >> Yeah, yeah, great question. I think it's important to kind of understand how we got here in the first place. I think Kubernetes solves a lot of problems for users, but the complexity of Kubernetes of just standing up a cluster to begin with is not always simple. And that's where services like EKS comes in and where Amazon tried to solve that problem for users saying, "Hey the control plane, it's made up of 10, 15 different components, standing all these up, patching them, you know, handling the CBEs for it et cetera, et cetera, is a very complicated process, let me help you do that." And where EKS has been so successful and with EKS Anywhere which we launched last year, that's what we're helping customers do, a very similar thing in their own data centers. So we're kind of solving this problem of bringing the cluster online and helping customers launch their first application on it. But then what do you do once your application's there? That's the question. And so now you launched your application and does it have enough resources? Did you tune the right CPU? Did you tune the right amount of memory for it? All those questions need to be answered and that's where working with folks like StormForge come in. >> Well, it's interesting Matt because you're all about optimization and trying to maximize the efficiency which might mean people's lower their AWS bill, but that's okay with Amazon, right? You guys have shown the cheaper it is, the more they buy, well. >> Yeah. And it's all about loyalty and developer experience. And so when you can help create or add to the developer experience itself, over time that loyalty's there. And so when we can come alongside EKS and services from Amazon, well, number one StormForge is built on Amazon, on AWS, and so it's a nice fit, but when we don't have to require developers to choose between things like cost and performance, but they can focus on, you know, innovation and connecting the applications that they're managing on Kubernetes as they operationalize them to the actual business objectives that they have, it's a pretty powerful combination. >> So your entry into the market was in pre-production. >> Yeah. >> You can kind of simulate what performance is going to look like and now you've announced optimized live. >> Yep. >> So that should allow you to turn the crank a little bit more. >> Yeah. >> Get a little bit more accurate and respond more quickly. >> Yeah. So we're the only ones that give you both views. And so we want to, you know, we want to provide a view in what we call kind of our experimentation side of our platform, which is pre-production, as well as on ongoing and continuous view which we kind of call our observation, the observation part of our solution, which is in production. And so for us, it's about providing that view, it's also about taking an increased number of data inputs into the platform itself so that our machine learning can learn from that and ultimately be able to automate the right kinds of tasks alongside the developers to meet their objectives. >> So, Chandler, in my intro I was talking about the spending velocity and how Kubernetes was at the top. But when we had other survey questions that ETR did, and this is post pandemic, it was interesting. We asked what's the most important initiative? And the two top ones were security, no surprise, and it popped up really after the pandemic hit in the lockdown even more prominent and cloud migration, >> Right. >> was number two. And so how are you working with StormForge to effect cloud migrations? Talk about that relationship. >> Yeah. I think it's, you know, different enterprises to have different strategies on how they're going to get their workloads to the cloud. Some of 'em want to have modernize in place in their data centers and then take those modernized applications and move them to the cloud, and that's where something like I mentioned earlier, EKS Anywhere comes into play really nicely because we can bring a consistent experience, a Kubernetes experience to your data center, you can modernize your applications and then you can bring those to EKS in the cloud. And as you're moving them back and forth you have a more consistent experience with Kubernetes. And luckily StormForge works on prem as well even in air gapped environments for StormForge. So, you know, that's, you can get your applications tuned correctly for your data center workloads, and then you're going to tune them differently when you move them to the cloud and you can get them tuned correctly there but StormForge can run consistently in both environments. >> Now, can you add some color as to how you optimize EKS? >> Yeah, so I think from a EKS standpoint, when you, again, when the number of parameters that you have to look at for your application inside of EKS and then the associated services that will go alongside that the packages that are coming in from a Kubernetes standpoint itself, and then you start to transition and operationalize where more and more of these are in production, they're, you know, connected to the business, we provide the ability to go beyond what developers typically do which is sort of take the, either the out of the box defaults or recommendations that ship with the services that they put into their application or the any human's ability to kind of keep up with a couple parameters at a time. You know, with two parameters for the typical Kubernetes application, you might have about a 100 different possible combinations that you could choose from. And sometimes humans can keep up with that, at least statically. And so for us, we want to blow that wide open. We want developers to be able to take advantage of the entire footprint or environment itself. And, you know, by using machine learning to help augment what the developers themselves are doing, not replacing them, augmenting them and having them be a part of that process. Now this whole new world of optimization opens up to them, which is pretty fantastic. And so how the actual workloads are configured, you know, on an ongoing basis and predictively based on upcoming business events, or even unknowns many times is a pretty powerful position to be in. >> I mean, you said not to replace development. I mentioned robotic process automation in my intro, and of course in the early days, I was like, oh, it's going to replace my job. What's actually happened is it's replacing all the mundane tasks. >> Yeah. >> So you can actually do your job. >> Yeah. >> Right? We're all working 24/7, 365 these days, so that the extent that you can automate the things that I hate doing, >> Yeah. >> That's a huge win. So Chandler, how do people get started? You mentioned EKS Anywhere, are they starting on prem and then kind of moving into the cloud? If I'm a customer and I'm interested and I'm sort of at the beginning, where do I start? >> Yeah. Yeah. I mean, it really depends on your workload. Any workload that can run in the cloud should run in the cloud. I'm not just saying that because I work at Amazon but I truly think that that is the case. And I think customers think that as well. More and more customers are trying to move workloads to the cloud for that elasticity and all the benefits of using these huge platforms and, you know, hundreds of services that you have advantage of in the cloud but some workloads just can't move to the cloud yet. You have workloads that have latency requirements like some gaming workloads, for example, where we don't have regions close enough to the consumers yet. So, you know, you want to put workloads in Turkey to service Egypt customers or something like this. You also have workloads that are, you know, on cruise ships and they lose connectivity in the middle of the Atlantic, or maybe you have highly secure workloads in air gapped environments or something like this. So there's still a lot of use cases that keep workloads on prem and sometimes customers just have existing investments in hardware that they don't want to eat yet, right? And they want to slowly phase those out as they move to the cloud. And again, that's where EKS Anywhere really plays well for the workloads that you want to keep on prem, but then as you move to the cloud you can take advantage of obviously EKS. >> I'll put you in the spot. >> Sure. >> And don't hate me for doing this, but so Andy Jassy, Adam Selipsky, I've certainly heard Maylan Thompson Bukavek talk about this, and in fullness of time, all workloads will be in the cloud. >> Yeah. >> And I've said the cloud is expanding. We're going to bring the cloud to the edge. Edge is in your title. >> Yeah. >> Is that a correct interpretation and obvious it relates >> Absolutely. >> to Kubernetes. >> And you'll see that in Amazon strategy. I mean, without posts and wavelengths and local zones, like we're, at the end of the day, Amazon tries to satisfy customers. And if customers are saying, "Hey, I need workloads in San, I want to run a workload in San Francisco. And it's really important to me that it's close to those users, the end users that are in that area," we're going to help them do that at Amazon. And there's a variety of options now to do that. EKS Anywhere is actually only one piece of that kind of whole strategy. >> Yeah. I mean, here you have your best people working on the speed of light problem, but until that's solved, sure, sure. >> That's right. >> We'll give you the last word. >> How do you know about that? >> Yeah. Yeah. (all laughing) >> It's a top secret. Sorry. You heard it on the CUBE first. Matt, we'll give you the last word, bring us home. >> I, so I couldn't agree more. The, you know, the cloud is where workloads are going. Whether what I love is the ability to look at, you know, for the same enterprises, a lot of the ones we work with, want a, they want a public and a private view, public cloud, private cloud view. And they want that flexibility to, depending on the nature of the applications to be able to shift between from time to time where, you know, really decide. And I love EKS Anywhere. I think it's a fantastic addition to the, you know, to the ecosystem. And, you know, I think for us, we're about staying focused on the set of problems that we solve. No developer that I've ever met and probably neither of you have met, gets super excited about getting out of bed to manually tune their applications. And so what we find is that, you know, the time spent doing that, literally just is, there's like a one-to-one correlation. It means they're not innovating and they're not doing what they love to be doing. And so when we can come alongside that and automate away the manual task to your point, I think there are a lot of parallels to RPA in that case, it becomes actually a pretty empowering process for our users, so that they feel like they're, again, meeting the business objectives that they have, they get to innovate and yet, you know, they're exploring this whole new world around not having to choose between something like cost and performance for their applications. >> Well, and we're entering an entire new era of scale. >> Yeah. >> We've never seen before and human just are not going to be able to keep up with that. >> Yep. >> And that affect quality and speed and everything else. Guys, hey, thanks so much for coming in a great conversation. And thank you for watching this CUBE conversation. This is Dave Vellante, and we'll see you next time. (upbeat music)

(bright upbeat music) >> The adoption of container orchestration platforms is accelerating at a rate as fast or faster than any category in enterprise IT. Survey data from Enterprise Technology Research shows Kubernetes specifically leads the pack into both spending velocity and market share. Now like virtualization in its early days, containers bring many new performance and tuning challenges in particular insuring consistent and predictable application performance is tricky especially because containers, they're so flexible and they enable portability. Things are constantly changing. DevOps pros have to way through a sea of observability data and tuning the environment becomes a continuous exercise of trial and error. This endless cycle taxes resources and kills operational efficiency. So teams often just capitulate and simply dial up and throw unnecessary resources at the problem. StormForge is a company founded mid last decade that is attacking these issues with a combination of machine learning and data analysis. And with me to talk about a new offering that directly addresses these concerns is Matt Provo, founder and CEO of StormForge. Matt, welcome to theCUBE. Good to see you. >> Good to see you. Thanks for having me. >> Yeah, so we saw you guys at a KubeCon sort of first introduce you to our community but add a little color to my intro there if you will. >> Yeah, well, Semi stole my thunder but I'm okay with that. Absolutely agree with everything you said in the intro. You know, the problem that we have set out to solve which is tailor made for the use of real machine learning not machine learning kind of as a marketing tag is connected to how workloads on Kubernetes are really managed from a resource efficiency standpoint. And so a number of years ago, we built the core machine learning engine and have now turned that into a platform around how Kubernetes resources are managed at scale. And so organizations today as they're moving more workloads over, sort of drink the Kool-Aid of the flexibility that comes with Kubernetes and how many knobs you can turn. And developers in many ways love it. Once they start to operationalize the use of Kubernetes and move workloads from pre-production into production, they run into a pretty significant complexity wall. And this is where StormForge comes in to try to help them manage those resources more effectively in ensuring and implementing the right kind of automation that empowers developers into the process ultimately does not automate them out of it. >> So you've got news. You had launch coming to further address these problems. Tell us about that. >> Yeah, so historically, you know, like any machine learning engine, we think about data inputs and what kind of data is going to feed our system to be able to draw the appropriate insights out for the user. And so historically we've kind of been single threaded on load and performance tests in a pre-production environment. And there's been a lot of adoption of that, a lot of excitement around it and frankly amazing results. My vision has been for us to be able to close the loop, however, between data coming out of pre-production and the associated optimizations and data coming out of production environment and our ability to optimize that. A lot of our users along the way have said these results in pre-production are fantastic. How do I know they reflect reality of what my application is going to experience in a production environment? And so we're super excited to announce kind of the a second core module for our platform called Optimize Live. The data input for that is observability and telemetry data coming out of APM platforms and other data sources. >> So this is like Nirvana. So I wonder if we could talk a little bit more about the challenges that this addresses. I mean, I've been around a while and it really have observed... And I used to ask, you know, technology companies all the time. Okay, so you're telling me beforehand what the optimal configuration should be and resource allocation. What happens if something changes? >> Yeah. >> And then it's always, always a pause. >> Yeah. >> And Kubernetes is more of a rapidly changing environment than anything we've ever seen. So specifically the problem you're addressing. Maybe talk about that a little bit. >> Yeah, so we view what happens in pre-production as sort of the experimentation phase. And our machine learning is allowing the user to experiment in scenario plan. What we're doing with Optimize Live and adding the the production piece is what we kind of also call kind of our observation phase. And so you need to be able to run the appropriate checks and balances between those two environments to ensure that what you're actually deploying and monitoring from an application performance, from a cost standpoint is with your SLOs and your SLAs as well as your business objectives. And so that's the entire point of this edition is to allow our users to experience hopefully the Nirvana associated with that because it's an exciting opportunity for them and really something that no else is doing from the standpoint of closing that loop. >> So you said front machine learning not as a marketing tag. So I want you to sort of double click on that. What's different than how other companies approach this problem? >> Yeah, I mean, part of it is a bias for me and a frustration as a founder of the reason I started the company in the first place. I think machine learning or AI gets tagged to a lot of stuff. It's very buzzwordy. It looks good. I'm fortunate to have found a number of folks from the outset of the company with, you know, PhDs in Applied Mathematics and a focus on actually building real AI at the core that is connected to solving the right kind of actual business problems. And so, you know, for the first three or four years of the company's history, we really operated as a lab. And that was our focus. We then decided, we're trying to connect a fantastic team with differentiated technology to the right market timing. And when we saw all these pain points around how fast the adoption of containers and Kubernetes have taken place but the pain that the developers are running into, we actually found for ourselves that this was the perfect use case. >> So how specifically does Optimize Live work? Can you add a little detail on that? >> Yes, so when you... Many organizations today have an existing monitoring APM observability suite really in place. They've also got a metric source. So this could be something like Datadog or Prometheus. And once that data starts flowing, there's an out of the box or kind of a piece of Kubernetes that ships with it called the VPA or the Vertical Pod Autoscaler. And less than, really than 1% of Kubernetes users take advantage of the VPA mostly because it's really challenging to configure and it's not super compatible with the the tool set or, you know, the ecosystem of tools in a Kubernetes environment. And so our biggest competitor is the VPA. And what's happening in this environment or in this world for developers is they're having to make decisions on a number of different metrics or resource elements typically things like memory and CPU. And they have to decide what are the requests I'm going to allow application and what are the limits? So what are those thresholds that I'm going to be okay with so that I can, again, try to hit my business objectives and keep in line with my SLAs? And to your earlier point in the intro, it's often guesswork. You know, they either have to rely on out of the box recommendations that ship with the databases and other services that they are using or it's a super manual process to go through and try to configure and tune this. And so with Optimize Live, we're making that one click. And so we're continuously and consistently observing and watching the data that's flowing through these tools and we're serving back recommendations for the user. They can choose to let those recommendations automatically patch and deploy or they can retain some semblance of control over are the recommendations and manually deploy them into their environment themselves. And we, again, really believe that the user knows their application. They know the goals that they have and we don't. But we have a system that's smart enough to align with the business objectives and ultimately provide the relevant recommendations at that point. >> So the business objectives are an input from the application team? >> Yep. >> And then your system is smart enough to adapt and address those. >> Application over application, right? And so the thresholds in any given organization across their different ecosystem of apps or environment could be different. The business objectives could be different. And so we don't want to predefine that for people. We want to give them the opportunity to build those thresholds in and then allow the machine learning to learn and to send recommendations within those bounds. >> And we're going to hear later from a customer who's hosting a Drupal, one of the largest Drupal hosts. So it's all do it yourself across thousands of customers so it's, you know, very unpredictable. I want to make something clear though as to where you fit in the ecosystem. You're not an observability platform, you leverage observability platforms, right? So talk about that and where you fit into the ecosystem. >> Yeah, so it's a great point. We're also, you know, a series B startup and growing. We've the choice to be very intentionally focused on the problems that we've solve. And we've chosen to partner or integrate otherwise. And so we do get put into the APM category from time to time. We are really an intelligence platform. And that intelligence and insights that we're able to draw is because of the core machine learning we've built over the years. And we also don't want organizations or users to have to switch from tools and investments that they've already made. And so we were never going to catch up to to Datadog or Dynatrace or Splunk or AppDynamics or some of the other. And we're totally fine with that. They've got great market share and penetration. They do solve real problems. Instead, we felt like users would want a seamless integration into the tools they're already using. And so we view ourselves as kind of the Intel inside for that kind of a scenario. And it takes observability and APM data and insights that were somewhat reactive. They're visualized and somewhat reactive. And we add that proactive nature onto it, the insights and ultimately the appropriate level of automation. >> So when I think, Matt, about cloud native and I go back to the sort of origins of CNCF who's a, you know, handful of companies. And now you look at the participants it'll, you know, make your eyes bleed. How do you address dealing with all those companies and what is the partnership strategy? >> Yeah, it's so interesting because it's just that even that CNCF landscape has exploded. It was not too long ago where it was as small or smaller than the FinOps landscape today which by the way, the FinOps piece is also on a a neck breaking, you know, growth curve. We, I do see, although there are a lot of companies and a lot of tools, we're starting to see a significant amount of consistency or hardening of the tool chain, you know, with our customers and users. And so we've made strategic and intentional decisions on deep partnerships in some cases like OEM uses of our technology and certainly, you know, intelligent and seamless integrations into a few. So, you know, we'll be announcing a really exciting partnership with AWS and that specifically what they're doing with EKS, their Kubernetes distribution and services. We've got a deep partnership and integration with Datadog and then with Prometheus and specifically a few other cloud providers that are operating, manage Prometheus environments. >> Okay, so where do you want to take this thing? You're not taking the observability guys head on, smart move. So many of those even entering the market now. But what is the vision? >> Yeah, so we've had this debate a lot as well 'cause it's super difficult to create a category. You know, on one hand, you know, I have a lot of respect for founders and companies that do that. On the other hand from a market timing standpoint, you know we fit into AIOps, that's really where we fit. You know, we've made a bet on the future of Kubernetes and what that's going to look like. And so from a containers and Kubernetes standpoint, that's our bet. But we're an AIOps platform. You know, we'll continue getting better at the problems we solve with machine learning and we'll continue adding data inputs. So we'll go, you know, we'll go beyond the application layer which is really where we play now. We'll add, you know, kind of whole cluster optimization capabilities across the full stack. And the way we will get there is by continuing to add different data inputs that make sense across the different layers of the stack. And it's exciting. We can stay vertically oriented on the problems that we're really good at solving but we can become more applicable and compatible over time. >> So that's your next concentric circle. As the observability vendors expand their observation space, you can just play right into that. >> Yeah. >> The more data you get because your purpose built to solving these types of problems. >> Yeah, so you can imagine a world right now out of observability, we're taking things like telemetry data pretty quickly. You can imagine a world where we take traces and logs and other data inputs as that ecosystem continues to grow, it just feeds our own, you know, we are reliant on data. >> Excellent, Matt, thank you so much. >> Thanks for having me. >> Appreciate for coming on. Okay, keep it right there in a moment. We're going to hear from a customer with a highly diverse and constantly changing environment that I mentioned earlier. They went through a major replatforming with Kubernetes on AWS. You're watching theCUBE, you are leader in enterprise tech coverage. (bright upbeat music)

(upbeat music) >> The adoption of container orchestration platforms is accelerating at a rate as fast or faster than any category in enterprise IT. Survey data from enterprise technology research shows Kubernetes specifically, leads the pack into both spending velocity and market share. Now like virtualization in its early days, containers bring many new performance and tuning challenges, in particular ensuring consistent and predictable application performance is tricky especially because containers they're so flexible and they enable portability, things are constantly changing. DevOps Pros have to wade through a sea of observability data and tuning the environment becomes a continuous exercise of trial and error. This endless cycle taxes resources and kills operational efficiency. So teams often just capitulate and simply dial up and throw unnecessary resources at the problem. StormForge is a company founded mid last decade that is attacking these issues with a combination of machine learning and data analysis. And with me to talk about a new offering that directly addresses these concerns is Matt Provo, founder and CEO of StormForge. Matt, welcome to The CUBE. Good to see you. >> Good to see you. Thanks for having me. >> Yeah. So we saw you guys at CUBE con, sort of first introduce you to our community, but add a little color to my intro there if you want. >> Well, you semi stole my thunder, but I'm okay with that. Absolutely agree with everything you said in the intro. The problem that we have set out to solve, which is tailor made for the use of real machine learning, not machine learning kind of as a marketing tag is connected to how workloads on Kubernetes are really managed from a resource efficiency standpoint. And so a number of years ago, we built the core machine learning engine and have now turned that into a platform around how Kubernetes resources are managed at scale. And so organizations today, as they're moving more workloads over, sort of drink the cool-Aid of the flexibility that comes with Kubernetes and how many knobs you can turn and developers in many ways love it. Once they start to operationalize use of Kubernetes and move workloads from pre-production into production, they run into a pretty significant complexity wall. And this is where StormForge comes in to try to help them manage those resources more effectively and ensuring and implementing the right kind of automation that empowers developers into the process, ultimately does not automate them out of it. >> So you've got news, you a hard launch coming to further address these problems. Tell us about that. >> Yeah. So historically, like any machine learning engine, we think about data inputs and what kind of data is going to feed our system to be able to draw the appropriate insights out for the user. And so historically we've kind of been single threaded on load and performance tests in a pre-production environment. And there's been a lot of adoption of that, a lot of excitement around it and frankly, amazing results. My vision has been for us to be able to close the loop, however, between data coming out of pre-production and the associated optimizations and data coming out of production environment and our ability to optimize that. A lot of our users along the way have said, these results in pre-production are fantastic. How do I know they reflect reality of what my application is going to experience in a production environment? And so we're super excited to announce, kind of the second core module for our platform called optimized live. The data input for that is observability and telemetry data coming out of APM platforms and other data sources. >> So this is like Nirvana. So I wonder if we could talk a little bit more about the challenges that this addresses. I mean, I've been around a while and it really have observed, and I used to ask technology companies all the time. Okay. So you're telling me beforehand what the optimal configuration should be and resource allocation, what happens if something changes? And then it's always, always a pause. And Kubernetes is more of a rapidly changing environment than anything we've ever seen. So this is specifically the problem you're addressing, maybe talk about that a little bit more. >> Yeah. So we view what happens in pre-production as sort of the experimentation phase. And our machine learning is is allowing the user to experiment and scenario plan. What we're doing with optimized live and adding the production piece is what we kind of also call, kind of our observation phase. And so you need to be able to run the appropriate checks and balances between those two environments to ensure that what you're actually deploying and monitoring from an application performance, from a cost standpoint is aligning with your SLOs and your SLAs, as well as your business objectives. And so that's the entire point of this edition, is to allow our users to experience, hopefully the the Nirvana associated with that, because it's an exciting opportunity for them and really something that nobody else is doing from the standpoint of closing that loop. >> So you said up front, machine learning not as a marketing tag. So I want you to sort of double click on that. What's different than how other companies approach this problem? >> Yeah. I mean, part of it is a bias for me and a frustration as a founder of the reason I started the company in the first place. I think machine learning or AI gets tagged to a lot of stuff. It's very buzz wordy, it looks good. I'm fortunate to have found a number of folks from the outset of the company with PhDs and applied mathematics and a focus on actually building real AI at the core that is connected to solving the right kind of actual business problems. And so for the first three or four years of the company's history, we really operated as a lab. And that was our focus. We then decided, we're trying to connect a fantastic team with differentiated technology to the right market timing. And when we saw all these pain points around, how fast the adoption of containers and Kubernetes have taken place, but the pain that developers are running into, we actually found for ourselves that this was the perfect use case. >> So how specifically does optimize live work? Can you add a little detail on that? >> Yeah. So when you... Many organizations today have an existing monitoring APM, observability suite really in place, they've also got a metric source. So this could be something like Datadog, or Prometheus. And once that data starts flowing there's an out of the box or kind of a piece of Kubernetes that ships with it called the VPA or the vertical pod auto scaler. And less than, really less than 1% of Kubernetes users take advantage of of the VPA, mostly because it's really challenging to configure and it's not super compatible with the tool set or the ecosystem of tools in a Kubernetes environment. And so our biggest competitor is the VPA. And what's happening in this world for developers is they're having to make decisions on a number of different metrics or resource elements, typically things like memory and CPU, and they have to decide, what are the requests I'm going to allow for this application and what are the limits? So what are those thresholds that I'm going to be okay with? So that I can, again, try to hit my business objectives and keep in line with my SLAs. And to your earlier point in the intro, it's often guesswork. They either have to rely on out of the box recommendations that ship with the databases and other services that they are using, or it's a super manual process to go through and try to configure and tune this. And so with optimized live, we're making that one click. And so we're continuously and consistently observing and watching the data that's flowing through these tools and we're serving back recommendations for the user. They can choose to let those recommendations automatically patch and deploy, or they can retain some semblance of control over the recommendations and manually deploy them into their environment themselves. And we, again, really believe that the user knows their application. They know the goals that they have, we don't, but we have a system that's smart enough to align with the business objectives and ultimately provide the relevant recommendations at that point. >> So the business objectives are an input from the application team. And then your system is smart enough to a adapt and address those? >> Application over application. And so the thresholds in any given organization across their different ecosystem of apps or environment could be different. The business objectives could be different. And so we don't want to predefine that for people. We want to give them the opportunity to build those thresholds in and then allow the machine learning to learn and to send recommendations within those bounds. >> And we're going to hear later from a customer who's hosting a Drupal, one of the largest Drupal hosts. So it's all do it yourself across that of customers. So it's very unpredictable. I want to make something clear though. As to where you fit in the ecosystem, you're not an observability platform, you leverage observability platforms. So talk about that and where you fit in into the ecosystem. >> Yeah. So this is a great point. We're also a series B startup and growing where we've the choice to be very intentionally focused on the problems that we've solve and we've chosen to partner or integrate otherwise. And so we do get put into the APM category from time to time. We are really an intelligence platform and that intelligence and insights that we're able to draw is because of the core machine learning we've built over the years. And we also don't want organizations or users to have to switch from tools and investments that they've already made. And so we were never going to catch up to Datadog or Dynatrace or Splunk or UpDynamics or some of the other. And we're totally fine with that. They've got great market share and penetration. They do solve real problems. Instead, we felt like users would want a seamless integration into the tools they're already using. And so we view ourselves as kind of the Intel inside for that kind of a scenario. And it takes observability and APM data and insights that were somewhat reactive, they're visualized and somewhat reactive and we make those, we add that proactive nature onto it, the insights and ultimately the appropriate level of automation. >> So when I think Matt about cloud native and I go back to the sort of origins of CNCF, it was a handful of companies, and now you look at the participants make your eyes bleed. How do you address dealing with all those companies and what's the partnership strategy? >> Yeah, it's so interesting because, just that even that CNCF landscape has exploded. It was not too long ago where it was as small or smaller than the Finops landscape today, which by the way, the Finops piece is also on a neck breaking growth curve. I do see, although there are a lot of companies and a lot of tools, we're starting to see a significant amount of consistency or hardening of the tool chain with our customers and users. And so we've made strategic and intentional decisions on deep partnerships, in some cases like OEM, uses of our technology and certainly, intelligent and seamless integrations into a few. So we'll be announcing a really exciting partnership with AWS and that specifically what they're doing with EKS, their Kubernetes distribution and services. We've got a deep partnership and integration with Datadog and then with Prometheus, and specifically a few other cloud providers that are operating manage Prometheus environments. >> Okay. So where do you want to take this thing? You're not taking the observability guys head on, smart move. So many of those even entering the market now. But what is the vision? >> Yeah. So we've had this debate a lot as well 'cause it's super difficult to create a category. On one hand, I have a lot of respect for founders and companies that do that, on the other hand, from a market timing standpoint, we fit into AI Ops, that's really where we fit. We've made a bet on the future of Kubernetes and what that's going to look like. And so from a containers and Kubernetes standpoint that's our bet, but we're an AI Ops platform, we'll continue getting better at the problems we solve with machine learning and we'll continue adding data inputs. So we'll go beyond the application layer, which is really where we play now. We'll add kind of whole cluster optimization capabilities across the full stack. And the way we will get there is by continuing to add different data inputs that make sense across the different layers of the stack. And it's exciting. We can stay vertically oriented on the problems that we're really good at solving but we can become more applicable and compatible over time. >> So that's your next concentric circle. As the observability vendors expand their observation space, you can just play right into that? More data you get because your purpose built to solving these types of problems. >> Yeah. So you can imagine a world right now out of observability, we're taking things like telemetry data. Pretty quickly you can imagine a world where we take traces and logs and other data inputs as that ecosystem continues to grow. It just feeds our own, we are reliant on data. >> Excellent. Matt, thank you so much. Appreciate you coming on. >> Thanks for having me. >> Okay. Keep it right there. In a moment, we're going to hear from a customer with a highly diverse and constantly changing environment that I mentioned earlier. They went through a major replatforming with Kubernetes on AWS. You're watching The CUBE, your leader in enterprise tech coverage. (upbeat music)

[Music] the adoption of container orchestration platforms is accelerating at a rate as fast or faster than any category in enterprise i.t survey data from enterprise technology research shows kubernetes specifically leads the pack in both spending velocity and market share now like virtualization in its early days containers bring many new performance and tuning challenges in particular ensuring consistent and predictable application performance is tricky especially because containers they're so flexible and they enable portability things are constantly changing devops pros have to wade through a sea of observability data and tuning the environment becomes a continuous exercise of trial and error this endless cycle taxes resources and kills operational efficiency so teams often just capitulate and simply dial up and throw unnecessary resources at the problem stormforge is a company founded mid last decade that is attacking these issues with a combination of machine learning and data analysis and with me to talk about a new offering that directly addresses these concerns is matt provo founder and ceo of stormforge matt welcome to the cube good to see you good to see you thanks for having me yeah so we saw you guys at a kubecon sort of first introduce you to our community but add a little color to my intro there yeah well you semi stole my thunder but uh i'm okay with that uh absolutely agree with everything you said in the intro um you know the the problem that we have set out to solve which is tailor-made for the use of real machine learning not machine learning kind of as a as a marketing tag uh is is connected to how workloads on kubernetes are are really managed from a resource efficiency standpoint and so a number of years ago we built uh the the core machine learning engine and have now turned that into a platform around how kubernetes resources are managed at scale and so organizations today as they're moving more workloads over uh sort of drink the kool-aid of the flexibility that comes with kubernetes and how many knobs you can turn and developers in many many ways love it once they start to operationalize the use of kubernetes and move uh workloads from pre-production into production they run into a pretty significant complexity wall and and this is where stormforge comes in to try to help them manage those resources more effectively in ensuring and implementing the right kind of automation that empowers developers into the process ultimately does not automate them out of it so you've got news yeah hard launch coming and to further address these problems tell us about that yeah so historically um uh you know like any machine learning engine we think about data inputs and what kind of data is going to feed our our system to be able to draw the appropriate insights out out for the user and so historically we are we've kind of been single threaded on load and performance tests in a pre-production environment and there's been a lot of adoption of that a lot of excitement around it and and frankly amazing results my vision has been uh for us to be able to close the loop however between uh data coming out of pre-production and opt in the associated optimizations and data coming out of production a production environment uh and and our ability to optimize that a lot of our users along the way have have said these results in pre-production are are fantastic how do i know they reflect reality of what my application is going to experience in a production environment and so we're super excited to to announce kind of the second core module for our platform called optimizelive the data input for that is uh observability and telemetry data coming out of apm platforms and and other data sources so this is like nirvana so i wonder if we could talk a little bit more about the the challenges that this address is i mean i've been around a while and it really have observed and i used to ask you know technology companies all the time okay so you're telling me beforehand what the optimal configuration should be and resource allocation what happens if something changes yeah and then it's always always a pause yeah and kubernetes is more of a rapidly changing environment than anything we've ever seen yeah so this is specifically the problem you're addressing maybe talk about that yeah so we view what happens in pre-production as sort of the experimentation phase and our machine learning is is allowing the user to experiment and design and scenario plan what we're doing uh with optimize live and adding the the production piece is uh what we kind of also call kind of our observation phase and so you need to be able to to to run the appropriate checks and balances between those two environments to ensure that what you're actually deploying and monitoring from an application performance from a cost standpoint is aligning with your slos and your slas as well as your business objectives and so that's the entire point of of this edition is to is to allow our users uh to experience uh hopefully the nirvana associated with that because it's an exciting er it's an exciting opportunity for them and really something that uh nobody else is doing from the standpoint of of closing that loop so you said upfront machine learning not as a marketing tag so i want you to sort of double click on that what's different than how other companies approach this problem yeah i mean part of it is a bias for me and a frustration as a founder of of the reason i started the company in the first place i think machine learning or ai gets tagged to a lot of stuff it's very buzz wordy it's it looks good i'm fortunate to have found a number of folks from the outset of the company with you know phds in applied mathematics and a focus on actually building real ai at the core uh that is connected to solving the right kind of actual business problems and so you know for the first three or four years of the company's history we really operated as a lab and that was our our focus we were we then decided we're trying to connect a fantastic team with differentiated technology to the right market timing and when we saw all these pain points around how fast the adoption of containers and kubernetes have taken place but the pain that the developers are running into we found it we actually found for ourselves uh that this was the perfect use case so how specifically does optimize live work can you add a little detail on that yeah so when you um many organizations today have an existing monitoring apm observability suite really in in place they've also got they've also got a metric source so this could be something like datadog or prometheus and once that data starts flowing there's an out of the box or or kind of a piece of kubernetes that ships with it called the vpa or the vertical pod auto scaler and uh less than really less than one percent of kubernetes users take advantage of the of the vpa mostly because it's really challenging to configure and it's not super compatible with the the tool set or the eco you know the ecosystem of tools uh in a kubernetes environment and so our biggest competitor is the vpa and what's happening in this environment or in in this world for developers is they're having to make decisions on on a number of different metrics or or resource elements typically things like memory and cpu and they have to decide what are the what are the limitations what are the requests i'm going to allow for this uh application and what are the limits so what are those thresholds that i'm going to be okay with so that i can again try to hit my business objectives and keep in line with my slas and to your earlier point in the intro it's often guesswork um you know they either have to rely on out of the box recommendations that ship with the databases and other services that they are using or it's a super manual process to go through and try to configure and tune this and so with optimize live we're making that one click and so we're continuously and consistently uh observing and watching the data that's flowing through these tools and we're serving back recommendations for the user they can choose to let those recommendations automatically patch and deploy or they can retain some semblance of control over the recommendations and manually deploy them into their environment themselves and we again really believe that the the user knows their application they know their the goals that they have we don't uh but we have a system that's smart enough to align with the business objectives and ultimately provide the relevant recommendations so the business objectives are an input from the application team yeah and then your system is smart enough to adapt and address those application over application right and and so the the thresholds in any given organization across their different ecosystem of apps or environment could be different the business objectives could be different and so we don't want to predefine that for people we want to give them the opportunity to build those thresholds in and then allow the machine learning to uh to learn and to send recommendations within those bounds and we're going to hear later from a customer who's uh hosting a drupal one of the largest drupal hosts so it's all do-it-yourself across thousands of customers so it's you know very unpredictable i want to make something clear though as to where you fit in the ecosystem you're not an observability platform you leverage observability platforms right so talk about that and where you fit in into the ecosystem yeah so that's a great point um we uh we're also you know a series b startup and and growing where we've made the choice to be very intentionally focused on the problems that we've solved and we've uh chosen to partner or integrate otherwise and so we do get put into the apm category from from time to time we're really an intelligence platform and that intelligence and insights that we're able to draw is because we because of the core machine learning we've built over the years and we also don't want organizations or users to have to switch from tools and investments that they've already made and so we were never going to we were never going to catch up to to to datadog or dynatrace or or splunk or app dynamics or some of the other and and we're totally fine with that they've got great market share and penetration they they do solve real problems instead we felt like users would want a seamless integration uh into the the tools they're already using and so we we we view ourselves as uh kind of the intel inside uh for that kind of a scenario and uh it takes observability and apm data and insights that were somewhat reactive uh they're visualized and somewhat reactive and and we make those uh we add that we add that proactive nature onto it the insights and and ultimately the the appropriate level of automation so when i think matt about cloud native and i go back to the sort of origins of cncf it was a handful of companies and now you look at the participants it'll you know make your eyes bleed how do you address dealing with all those companies and what are the what's the partnership strategy yeah it's so interesting because um it's just that even that cncf landscape has exploded um it was not too long ago where it was as small or smaller than the finnops landscape today which by the way the phenops pieces is also on a neck-breaking you know growth curve we i do see although there are a lot of companies and a lot of tools we're starting to see a significant amount of consistency or hardening of the tool chain uh you know for with our customers and end users and so we've made strategic and intentional decisions on deep partnerships in some cases like oem uh uses of our technology and and certainly you know intelligent and seamless integrations uh into a few so you know we're we'll be announcing uh a really exciting partnership with aws uh and and uh specifically what they're doing with eks their their kubernetes distribution and services we've got a deep partnership and integration with datadog and then with prometheus and specifically cloud provider a few other cloud providers that are operating managed prometheus environments okay so where do you want to take this thing it's not you're not taking the observability guys head on smart move so many of those even entering the market now but what is the vision yeah so we've had this debate a lot as well because it's super difficult to create a category uh you know on one hand um you know you know i have a lot of respect for founders and and companies that do that on the other hand um from a market timing standpoint you know we fit into ai ops that's really where we fit um you know we are we've made a bet on the future of kubernetes uh and and what that's going to look like and so um from a containers and kubernetes standpoint that's our bet uh but we're an aiops platform you know we'll continue getting better at what at the problems we solve with machine learning and we'll continue adding data inputs so we'll go you know we'll go beyond the application layer which is really where we play now we'll add kind of whole cluster optimization capabilities across across the full stack and the way we'll get there is by continuing to add different data inputs that make sense across the different layers of the stack and it's exciting we can stay vertically oriented on the problems that we're really good at solving but we can become more applicable and compatible over time so that's your next concentric circle as the observability vendors expand their observation space you can just play right into that yeah more data you get because you're a purpose built to solving these types of problems yeah so you can imagine a world right now out of observability we're taking things like telemetry data pretty quickly you can imagine a world where we take traces and logs and other data inputs as as that ecosystem continues to grow it just feeds our own uh you know we are reliant on data um so excellent matt thank you so much appreciate you for having me okay keep it right there in a moment we're gonna hear from a customer with a highly diverse and constantly changing environment that i mentioned earlier they went through a major re-platforming with kubernetes on aws you're watching thecube your leader in enterprise tech coverage [Music] you

(bright upbeat music) >> The adoption of container orchestration platforms is accelerating at a rate as fast or faster than any category in enterprise IT. Survey data from Enterprise Technology Research shows Kubernetes specifically leads the pack in both spending velocity and market share. Now like virtualization in its early days, containers bring many new performance and tuning challenges. In particular, ensuring consistent and predictable application performance is tricky especially because containers they're so flexible and the enabled portability things are constantly changing. DevOps pros have to wade through a sea of observability data and tuning the environment becomes a continuous exercise of trial and error. This endless cycle taxes, resources, and kills operational efficiencies so teams often just capitulate and simply dial up and throw unnecessary resources at the problem. StormForge is a company founded in mid last decade that is attacking these issues with a combination of machine learning and data analysis. And with me to talk about a new offering that directly addresses these concerns, is Matt Provo, founder and CEO of StormForge. Matt, welcome to thecube. Good to see you. >> Good to see you, thanks for having me. >> Yeah. So we saw you guys at CubeCon, sort of first introduce you to our community but add a little color to my intro if you will. >> Yeah, well you semi stole my thunder but I'm okay with that. Absolutely agree with everything you said in the intro. You know, the problem that we have set out to solve which is tailor made for the use of real machine learning not machine learning kind of as a marketing tag is connected to how workloads on Kubernetes are really managed from a resource efficiency standpoint. And so a number of years ago we built the core machine learning engine and have now turned that into a platform around how Kubernetes resources are managed at scale. And so organizations today as they're moving more workloads over sort of drink the Kool-Aid of the flexibility that comes with Kubernetes and how many knobs you can turn and developers in many ways love it. Once they start to operationalize the use of Kubernetes and move workloads from pre-production into production, they run into a pretty significant complexity wall. And this is where StormForge comes in to try to help them manage those resources more effectively in ensuring and implementing the right kind of automation that empowers developers into the process ultimately does not automate them out of it. >> So you've got news, your hard launch coming in to further address these problems. Tell us about that. >> Yeah so historically, you know, like any machine learning engine, we think about data inputs and what kind of data is going to feed our system to be able to draw the appropriate insights out for the user. And so historically we are, we've kind of been single-threaded on load and performance tests in a pre-production environment. And there's been a lot of adoption of that, a lot of excitement around it and frankly, amazing results. My vision has been for us to be able to close the loop however between data coming out of pre-production and the associated optimizations and data coming out of production, a production environment, and our ability to optimize that. A lot of our users along the way have said these results in pre-production are fantastic. How do I know they reflect reality of what my application is going to experience in a production environment? And so we're super excited to announce kind of the second core module for our platform called Optimize Live. The data input for that is observability and telemetry data coming out of APM platforms and other data sources. >> So this is like Nirvana. So I wonder if we could talk a little bit more about the challenges that this addresses. I mean, I've been around a while and it really have observed and I used to ask technology companies all the time, okay, so you're telling me beforehand what the optimal configuration should be in resource allocation, what happens if something changes? And then it's always a pause. And Kubernetes is more of a rapidly changing environment than anything we've ever seen. So this is specifically the problem you're addressing. Maybe talk about that a little bit. >> Yeah so we view what happens in pre-production as sort of the experimentation phase and our machine learning is allowing the user to experiment and scenario plan. What we're doing with Optimize Live and adding the production piece is what we kind of also call kind of our observation phase. And so you need to be able to run the appropriate checks and balances between those two environments to ensure that what you're actually deploying and monitoring from an application performance, from a cost standpoint, is aligning with your SLOs and your SLAs as well as your business objectives. And so that's the entire point of this addition is to allow our users to experience hopefully the Nirvana associated with that because it's an exciting opportunity for them and really something that nobody else is doing from the standpoint of closing that loop. >> So you said upfront machine learning not as a marketing tag. So I want you to sort of double click on that. What's different than how other companies approach this problem? >> Yeah I mean, part of it is a bias for me and a frustration as a founder of the reason I started the company in the first place. I think machine learning our AI gets tagged to a lot of stuff. It's very buzzwordy, it looks good. I'm fortunate to have found a number of folks from the outset of the company with, you know, PhDs in Applied Mathematics and a focus on actually building real AI at the core that is connected to solving the right kind of actual business problems. And so, you know, for the first three or four years of the company's history, we really operated as a lab and that was our focus. We then decided we're trying to connect a fantastic team with differentiated technology to the right market timing. And when we saw all of these pain points around how fast the adoption of containers and Kubernetes have taken place but the pain that the developers are running into, we found it, we actually found for ourselves that this was the perfect use case. >> So how specifically does Optimize Live work? Can you add a little detail on that? >> Yeah so when you, many organizations today have an existing monitoring APM observability suite really in place. They've also got, they've also got a metric source, so this could be something like Datadog or Prometheus. And once that data starts flowing, there's an out of the box or kind of a piece of Kubernetes that ships with it called the VPA or the Vertical Pod Autoscaler. And less than really less than 1% of Kubernetes users take advantage of the VPA mostly because it's really challenging to configure and it's not super compatible with the tool set or the, you know, the ecosystem of tools in a Kubernetes environment. And so our biggest competitor is the VPA. And what's happening in this environment or in this world for developers is they're having to make decisions on a number of different metrics or resource elements typically things like memory and CPU. And they have to decide what are the, what are the requests I'm going to allow for this application and what are the limits? So what are those thresholds that I'm going to be okay with? So that I can again try to hit my business objectives and keep in line with my SLAs. And to your earlier point in the intro, it's often guesswork. You know, they either have to rely on out of the box recommendations that ship with the databases and other services that they are using or it's a super manual process to go through and try to configure and tune this. And so with Optimize Live, we're making that one-click. And so we're continuously and consistently observing and watching the data that's flowing through these tools and we're serving back recommendations for the user. They can choose to let those recommendations automatically patch and deploy or they can retain some semblance of control over the recommendations and manually deploy them into their environment themselves. And we again, really believe that the user knows their application, they know the goals that they have, we don't. But we have a system that's smart enough to align with the business objectives and ultimately provide the relevant recommendations at that point. >> So the business objectives are an input from the application team and then your system is smart enough to adapt and adjust those. >> Application over application, right? And so the thresholds in any given organization across their different ecosystem of apps or environment could be different. The business objectives could be different. And so we don't want to predefine that for people. We want to give them the opportunity to build those thresholds in and then allow the machine learning to learn and to send recommendations within those bounds. >> And we're going to hear later from a customer who is hosting a Drupal, one of the largest Drupal host, is it? So it's all do it yourself across thousands of customers so it's very unpredictable. I want to make something clear though, as to where you fit in the ecosystem. You're not an observability platform, you leverage observability platforms, right? So talk about that and where you fit in into the ecosystem. >> Yeah so it's a great point. We, we're also you know, a series B startup and growing. We've made the choice to be very intentionally focused on the problems that we've solve and we've chosen to partner or integrate otherwise. And so we do get put into the APM category from time to time. We're really an intelligence platform. And that intelligence and insights that we're able to draw is because we, because of the core machine learning we've built over the years. And we also don't want organizations or users to have to switch from tools and investments that they've already made. And so we were never going to catch up to Datadog or Dynatrace or Splunk or AppDynamics or some of the other, and we're totally fine with that. They've got great market share and penetration and they do solve real problems. Instead, we felt like users would want a seamless integration into the tools they're already using. And so we view ourselves as kind of the Intel inside for that kind of a scenario. And it takes observability and APM data and insights that were somewhat reactive, they're visualized and somewhat reactive and we make those, we add that proactive nature onto it, the insights and ultimately the appropriate level of automation. >> So when I think Matt about cloud native and I go back to the sort of origins of CNCF, it was a, you know, handful of companies, and now you look at the participants, you know, make your eyes bleed. How do you address dealing with all those companies and what's the partnership strategy? >> Yeah it's so interesting because it's just that even at CNCF landscape has exploded. It was not too long ago where it was as smaller than the finOps Landscape today which by the way the FinOps pieces is also on a neck breaking, you know, growth curve. We, I do see although there are a lot of companies and a lot of tools, we're starting to see a significant amount of consistency or hardening of the tool chain with our customers and users. And so we've made strategic and intentional decisions on deep partnerships in some cases like OEM users of our technology and certainly, you know, intelligent and seamless integrations into a few. So, you know, we'll be announcing a really exciting partnership with AWS and specifically what they're doing with EKS, their Kubernetes distribution and services. We've got a deep partnership and integration with Datadog and then with Prometheus and specifically cloud provider, a few other cloud providers that are operating manage Prometheus environments. >> Okay so where do you want to take this thing? If it's not, you're not taking the observability guys head on, smart move, so many of those even entering the market now, but what is the vision? >> Yeah so we've had this debate a lot as well because it's super difficult to create a category. You know, on one hand, I have a lot of respect for founders and companies that do that, on the other hand from a market timing standpoint, you know, we fit into AIOps. That's really where we fit. You know we are, we've made a bet on the future of Kubernetes and what that's going to look like. And so from a containers and Kubernetes standpoint that's our bet. But we're an AIOps platform, we'll continue getting better at what, at the problems we solve with machine learning and we'll continue adding data inputs so we'll go beyond the application layer which is really where we play now. We'll add kind of whole cluster optimization capabilities across the full stack. And the way we'll get there is by continuing to add different data inputs that make sense across the different layers of the stack and it's exciting. We can stay vertically oriented on the problems that we're really good at solving but we become more applicable and compatible over time. >> So that's your next concentric circle. As the observability vendors expand their observation space you can just play right into that. The more data you get could be because you're purpose built to solving these types of problems. >> Yeah so you can imagine a world right now out of observability, we're taking things like telemetry data pretty quickly. You can imagine a world where we take traces and logs and other data inputs as that ecosystem continues to grow, it just feeds our own, you know, we are reliant on data. So. >> Excellent. Matt, thank you so much. Thanks for hoping on. >> Yeah, appreciate it. >> Okay. Keep it right there. In a moment, We're going to hear from a customer with a highly diverse and constantly changing environment that I mentioned earlier, they went through a major re-platforming with Kubernetes on AWS. You're watching theCube, your a leader in enterprise tech coverage. (bright music)

>> Welcome back to Los Angeles. The cube is live. It feels so good to say that. I'm going to say that again. The cube is alive in Los Angeles. We are a coop con cloud native con 21. Lisa Martin with Dave Nicholson. We're talking to storm forge next. Cool name, right? We're going to get to the bottom of that. Please welcome Matt Provo, the founder and CEO of storm forge and Tom Ellery, the SVP of revenue storm forge, guys, welcome to the program. Thanks for having us. So storm forge, you have to say it like that. Like I feel like do you guys wear Storm trooper outfits on Halloween. >> Sometimes Storm trooper? The colors are black. You know, we hit anvils from time to time. >> I thought I, I thought they, that I saw >> Or may not be a heavy metal band that might be infringing on our name. It's all good. That's where we come from. >> I see. So you, so you started the company in 2015. Talk to me about the Genesis of the company. What were some of the gaps in the market that you saw that said we got to come in here and solve this? >> Yeah, so I was fortunate to always know. I think when you start a company, sometimes you, you know exactly the set of problems that you want to go after and potentially why you might be uniquely set up to solve it. What we knew at the beginning was we had a number of really talented data scientists. I was frustrated by the buzzwords around AI and machine learning when under the hood, this really a lot of vaporware. And so at the outset, really the, the point was build something real at the core, connect that to a set of problems that could drive value. And when we looked at really the beginnings of Kubernetes and containerization five, six years ago at its Genesis, we saw just a bunch of opportunity for machine learning, to play the right kind of role if we could build it correctly. And so at the outset it was what's going on. Why are people are people moving content workloads over to containers in the first place? And, you know, because of the flexibility and the portability around Kubernetes, we then ran into quickly its complexity. And within that complexity was really the foundation to set up the company and the solution for prob a set of problems uniquely and most beneficially solved by using machine learning. And so when we sort of brought that together and designed out some ideas, we, we did what any, any founder with a product background would do. We went and talked to a bunch of potential users and kind of tried to validate the problems themselves and, and got a really positive response. So. >> So Tom, from a business perspective, what, what attracted you to this? >> Well, initially I wasn't attracted just, I'll say that just from a startup standpoint. So I've been in the industry for 30 years, I've done six or seven pre IPO companies. I was exiting a private company. I did not want to go do another startup company, but being in the largest enterprise companies for the last 20 years, you see Kubernetes like wildfire in these places. And you knew there was huge amount of complexity and sophistication when they deployed it. So I started talking to Matt early on. He explained what they were doing and how unique the offer was around machine learning. I already knew the problems that customers had at scale with Kubernetes. So it was for me, I said, all right, I'm going to take one more run at this with Matt. I think we're, we're in a great position to differentiate ourselves. So that was really the launch pad for me, was really the technology and the market space. Those, those two things in combination are very exciting for us as a business. >> And, you know, a couple of bottles of amazing wine and a number of dinners that. >> Helps as well. >> That definitely helped twist his arm? >> Now tell us, just really kind of get into the technology. What does it do? How does it help facilitate the Kubernetes environment? >> Yeah, absolutely. So when organizations start moving workloads over to Kubernetes and get their applications up and running, there's a number of amazing organizations, whether it's through cloud providers or otherwise that that sort of solved that day one problem, those challenges. And as I was mentioning, you know, they moved because of flexibility and so developers love it and it starts to create a great experience, but there's these set of expectations. >> Where, where typically are these moving from? What you, what, what are the, what are the top three environments these are, that these are moving out of? >> Yeah. I mean, of course, non containerized environments, more generally. They could be coming from, you know, bare metal environment and it could be coming from kind of a VM driven environment. >> Okay. >> So when you look back at kind of the, the growth and Genesis and of VMs, you see a lot of parallels to what we're seeing now with, with containerization. And so as you move, it's, it's exciting. And then you get smacked in the face with the complexity, for all of the knobs that are able to be turned within a Kubernetes environment. It gives developers a lot of flexibility. These knobs, as you turn them, you have no visibility into how into the impact on the application itself. And so often organizations are become, you know, becoming more agile shipping, you know, shipping code more quickly, but then all of a sudden the, the cloud bill comes and they've, over-provisioned by 80, 90%, the, they didn't need nearly as many resources. And so what we do is we help understand the unique goals and requirements for each of the applications that are running in Kubernetes. And we have machine learning capabilities that can predict very accurately what organizations will need from a resource standpoint, in order to meet their goals, not just from a cost standpoint, but also from a performance standpoint. And so we allow organizations to typically save usually between 40 and 60% off their cloud bill and usually increased performance between 30 and 50%. Historically developers had to choose between cost and performance and their worldview on the application environment was very limited to a small set of what we would call parameters or metrics that they could choose from. And machine learning allows that world to just be blown open and not many humans are, are sophisticated in the way we think about multidimensional math to be able to make those kinds of predictions. You're talking about billions and billions of combinations, not just in a static environment, but an ongoing basis. So our technology sits in the middle of all that chaos and, and allows it to allows organizations just to re reap a whole lot of benefits that they otherwise may not ever find. >> Those numbers that you mentioned were, were big from a cost savings perspective than a performance increased perspective, which is so critical these days is in the last 18 months, we've seen so much change. We've seen massive pivots from companies in every industry to survive first of all, and then to be able to thrive and be able to iterate quickly enough to develop new products and services and get them to market to be competitive. >> Yeah. >> Yeah. Sorry. I mean, the thing that's interesting, there was an article by Andreessen Horowitz. I don't know if you've taken to the cloud paradox. So we actually, if you start looking at that great example would be some of these cloud companies that are growing like astronomical rates, snowflakes, like phenomenal what they're doing, but go look at their cogs and what it's doing. Also, it's growing almost proportionately as the revenues growing. So you need to be able to solve that problem in a way that is sophisticated enough with machine learning algorithms, that people don't have to be in the loop to do it. And that the math can prove out the solution as you go out and scale your environments. And a lot of companies now are all transitioning over SAS based platforms, and they're going to start running into these problems that they go as they go to scale. And those are the areas that we're really focused and concentrating on as an organization. >> As the leader of sales, talk to me about the voice of the customer. What are some- you've been there six months or so we heard, we heard about the wine and the dinners is obvious. >> We haven't done a lot of that over the last 18 months. >> You'll have to make for lost time then >> As soon as he closes more business. >> Oh, oh there we go, we got that on camera! >> There's, there's been three, a market spaces that we've had some really good success in that. So we talked about a SAS marketplace. So there's a company that does Drupal and Matt knows very well up in Boston, Aquia. And they have every customer is a unique snowflake customer. So they need to optimize each of their customers in order to ensure the cost as well as performance for that customer on their site works appropriately. So that's one example of a SAS based company that where we can go in and help them optimize without humans doing the optimization and the math and the machine learning from storm forge doing that. So that's an area, the other area that we've seen some really good traction Cantonese with GSI. So part of our go to market model is with GSI. So if you think about what a GSI does, a lot of times customers are struggling either initially deploying Kubernetes or putting it in for 12, 18 months and realizing we're starting to scale, we got all kinds of performance issues. How do I solve it? A lot of these people go to the Accentures, the cognizance and other ones, and start flying their ninjas into kind of solve the problem. So we're getting a lot of traction with them because they're using our tool as a way to help solve the customer's problems. And they're in the largest enterprise customers as possible. >> So if I'm hearing what you're saying correctly, you're saying that when I deploy server less applications, I may in fact, get a bill for servers that are being used? Is it, is that what you're telling us? >> They're there in fact may be a bill for what was coined as server less. That is very difficult to understand, by the way, >> That's crazy talk, Matt. >> And connect back. >> Yeah. But absolutely we deal with that all the time. It's a, it's a painful process from time to time. >> Have you, have you, have you seen the statistics that's going on with how people, I mean, there was huge inertia from every CIO that you had have a cloud strategy in place. Everyone ran out and had a cloud strategy in place. And then they started deploying on Kubernetes. Now they're realizing, oh wow, we can run it, but it's costing us more than it ever costs us on prem and the operational complexity associated with that. So there's not enough people in the industry to help solve that problem, especially at the grass roots, that's where you need sophisticated solutions like storm forge and machine learning to help solve this at scale problem in a way that humans could never solve. >> And I would, I would just add to that, that the, the same humans managing the Kubernetes application environments today are likely the same humans that we're managing it in a, in a BM world. So there's a huge skills gap. I love what Castin announced at KU KU con this year around their learning environment where it's free. Come learn Kubernetes and this, and we need more of that. There's an enormous skills gap and, and the problems are complex enough in and of themselves. But when we have, when you add that to the skills gap, it it's, it presents a lot of challenges for organizations. >> What are some the ways in which you think that gap can start to be made smaller. >> Yeah. I mean, I think as more workloads get moved over, over, you know, over time, you see, you see more and more people becoming comfortable in an environment where scale is a part of what they have to manage and take care of. I love what the Linux foundation and the CNCF are doing around Kubernetes certifications, you know, more and more training. I think you're going to see training, you know, availability for more and more developers and practitioners be adopted more widely. You know, and I think that, you know, as the tool chain itself hardens within a CCD world in a containerized world, as that hardens, you're going to, you're going to start seeing more and more individuals who are comfortable across all these different tools. If you look at the CNCF landscape, I mean, today compared to four or five years ago, it's growing like crazy. And so, but, but there's also consolidation taking place within the tools. And people have an opportunity to, to learn and gain expertise within us. Which is very marketable by the way, >> Absolutely >> My employees often show me their LinkedIn profiles and remind me of how , how much they're getting recruited, but they've been loyal. So it's been a fantastic. >> Are there are so many parallels when you look at a VM in virtualization and what's happening with covers, obviously all the abstractions and stuff, but there was this whole concept of VM sprawl, you know, maybe 10 years in, if you think about the Kubernetes environment, that is exponentially bigger problem because of how many they're spitting up versus how, how many you spun up in VM. So those things ultimately need to be solved. It's not just going to be solved with people. It needs to be solved with sophisticated software. That's the only way you're going to solve a problem at scale like that. No matter how many people you have in the industry, it's just never going to solve the problem. >> So when you're in customer conversations, Tom, what are you say are like the top three differentiators that really set storm forage apart? >> Well, so the first one is we're very focused on Kubernetes only. So that's all we do is just Kubernetes environment. So we understand not just the applications that run in Kubernetes, but we understand the underlying architectures and techniques, which we think is really important. From a solution standpoint, >> So you're specialists? >> We are absolutely specialists. The other areas obviously are machine learning and the sophistication of our machine learning. And Matt said this really well, early on, I mean, the buzzwords are all out there. You can read them all up, all over the place for the last five to seven year AI and ML. And a lot of them are very hollow, but our whole foundation was based on machine learning and PhDs from Harvard. That's where we came out of from a technology background. So we were solving more, we weren't just solving the Kubernetes problems. We were solving machine learning problems. And so that's another really big area of differential for us. And I think the ability to actually scale and not just deal with small problems, but very large problems, because our focus is the fortune 2000 companies. And most of them have been deploying like financial services and stuff, Kubernetes for three, four or five years. And so they have had scale challenges that they're trying to solve. >> Yeah. It's Lisa and I talk about this concept of machine learning and looking under the covers and trying to find out is the machine really learning? Is it really learning or is it people are telling the machine, you need to do this. If you see that Where's the machine actually making those correlations and doing something intelligently. So can you give us an example of something that is actually happening that's intelligent? >> Well, so the, the, if this, then that problem is actually a huge source of my original frustration for starting the company, because you, you, you tag AI as a buzzword onto a lot of stuff. And we see that growing like crazy. And so I literally at the beginning said, if we can't actually build something real, that solves problems, like we're going to hang it up. And, you know, as Tom said, we came out of Harvard and, you know, there was a challenge initially of, are we just going to build like a really amazing algorithm? That's so heavy, it can never be productized or commercialized and it really should have just stayed in academia. And, you know, I the I, I will say a couple of things. One is I do not believe that that black box AI is a thing. We believe in what we would call human, augmented AI. So we want to empower practitioners and developers into the process instead of automate them out. We just want to give them the information and we want to save time for them and make their lives easier. But there's a kill switch on the technology. They can intervene at any point in time. They can direct the technology as they see fit. And what's really, really interesting is because their worldview of this application environment gets opened up by all the predictions and all of the learning that actually is taking place and, you know, give it because that worldview is open, they then get into a kind of a tinkering or experimental mindset with the technology. And they start thinking about all these other scenarios that they never were able to explore previously with the application. And, and so the machine learning itself is on an ongoing basis. Understanding changes in traffic, understanding and changes, changes in workloads for the application or demand. If you thought about like surge pricing for Uber, you know, because of a, a big game that took place. And you know, that, that change in peaks and valleys in demand, our, our technology not only understands those reactively, but it starts to build models and predict proactively in advance of the events that are going to take place on, on what ne- what kind of resources need to be allocated. And why that's the other piece around it is often solutions are giving you a little bit of a what, but they certainly are not giving you any explanation of the why. So the holy grail really like in our world is kind of truly explainable AI, which we're not there yet. Nobody's there yet. But human augmented AI with, with actual intelligence that's taking place that also is relevant to business outcomes is, is pretty exciting. So that's why where try to operate. >> Very exciting guys. Thanks for joining us, talking to us about storm forage, to feel like we need some store in forge. T-shirts what do you think? >> (unintelligible) >> See, I'm not even asking for the bottle of wine. I liked that idea. I thank Matt and Tom, thank you so much for joining us exciting company. Congratulations on your success. And we look forward to seeing what great things are to come from storm forage. >> Thanks so much for the time. >> Our pleasure. For Dave Nicholson. I'm Lisa Martin. We are alive in Los Angeles, the cube covering Kube con and cloud native con 21 stick around. Dave and I will be right back with our next guest.

>>Hi everybody. This is Dave Volante. Welcome to this cube conversation where we're going to go back in time a little bit and explore the early days of Kubernetes. Talk about how it formed the improbable events, perhaps that led to it. And maybe how customers are taking advantage of containers and container orchestration today, and maybe where the industry is going. Matt Provo is here. He's the founder and CEO of storm forge and Chandler Huntington hoes. Hoisington is the general manager of EKS edge and hybrid AWS guys. Thanks for coming on. Good to see you. Thanks for having me. Thanks. So, Jenny, you were the vice president of engineering at miso sphere. Is that, is that correct? >>Well, uh, vice-president engineering basis, fear and then I ran product and engineering for DTQ masons. >>Yeah. Okay. Okay. So you were there in the early days of, of container orchestration and Matt, you, you were working at a S a S a Docker swarm shop, right? Yep. Okay. So I mean, a lot of people were, you know, using your platform was pretty novel at the time. Uh, it was, it was more sophisticated than what was happening with, with Kubernetes. Take us back. What was it like then? Did you guys, I mean, everybody was coming out. I remember there was, I think there was one Docker con and everybody was coming, the Kubernetes was announced, and then you guys were there, doc Docker swarm was, was announced and there were probably three or four other startups doing kind of container orchestration. And what, what were those days like? Yeah. >>Yeah. I wasn't actually atmosphere for those days, but I know them well, I know the story as well. Um, uh, I came right as we started to pivot towards Kubernetes there, but, um, it's a really interesting story. I mean, obviously they did a documentary on it and, uh, you know, people can watch that. It's pretty good. But, um, I think that, from my perspective, it was, it was really interesting how this happened. You had basically, uh, con you had this advent of containers coming out, right? So, so there's new novel technology and Solomon, and these folks started saying, Hey, you know, wait a second, wait if I put a UX around these couple of Linux features that got launched a couple of years ago, what does that look like? Oh, this is pretty cool. Um, so you have containers starting to crop up. And at the same time you had folks like ThoughtWorks and other kind of thought leaders in the space, uh, starting to talk about microservices and saying, Hey, monoliths are bad and you should break up these monoliths into smaller pieces. >>And any Greenfield application should be broken up into individuals, scalable units that a team can can own by themselves, and they can scale independent of each other. And you can write tests against them independently of other components. And you should break up these big, big mandalas. And now we are kind of going back to model this, but that's for another day. Um, so, so you had microservices coming out and then you also had containers coming out, same time. So there was like, oh, we need to put these microservices in something perfect. We'll put them in containers. And so at that point, you don't really, before that moment, you didn't really need container orchestration. You could just run a workload in a container and be done with it, right? You didn't need, you don't need Kubernetes to run Docker. Um, but all of a sudden you had tons and tons of containers and you had to manage these in some way. >>And so that's where container orchestration came, came from. And, and Ben Heineman, the founder of Mesa was actually helping schedule spark at the time at Berkeley. Um, and that was one of the first workloads with spark for Macy's. And then his friends at Twitter said, Hey, come over, can you help us do this with containers at Twitter? He said, okay. So when it helped them do it with containers at Twitter, and that's kinda how that branch of the container wars was started. And, um, you know, it was really, really great technology and it actually is still in production in a lot of shops today. Um, uh, more and more people are moving towards Kubernetes and Mesa sphere saw that trend. And at the end of the day, Mesa sphere was less concerned about, even though they named the company Mesa sphere, they were less concerned about helping customers with Mesa specifically. They really want to help customers with these distributed problems. And so it didn't make sense to, to just do Mesa. So they would took on Kubernetes as well. And I hope >>I don't do that. I remember, uh, my, my co-founder John furrier introduced me to Jerry Chen way back when Jerry is his first, uh, uh, VC investment with Greylock was Docker. And we were talking in these very, obviously very excited about it. And, and his Chandler was just saying, it said Solomon and the team simplified, you know, containers, you know, simple and brilliant. All right. So you guys saw the opportunity where you were Docker swarm shop. Why? Because you needed, you know, more sophisticated capabilities. Yeah. But then you, you switched why the switch, what was happening? What was the mindset back then? We ran >>And into some scale challenges in kind of operationalize or, or productizing our kind of our core machine learning. And, you know, we, we, we saw kind of the, the challenges, luckily a bit ahead of our time. And, um, we happen to have someone on the team that was also kind of moonlighting, uh, as one of the, the original core contributors to Kubernetes. And so as this sort of shift was taking place, um, we, we S we saw the flexibility, uh, of what was becoming Kubernetes. Um, and, uh, I'll never forget. I left on a Friday and came back on a Monday and we had lifted and shifted, uh, to Kubernetes. Uh, the challenge was, um, you know, you, at that time, you, you didn't have what you have today through EKS. And, uh, those kinds of services were, um, just getting that first cluster up and running was, was super, super difficult, even in a small environment. >>And so I remember we, you know, we, we finally got it up and running and it was like, nobody touch it, don't do anything. Uh, but obviously that doesn't, that doesn't scale either. And so that's really, you know, being kind of a data science focused shop at storm forge from the very beginning. And that's where our core IP is. Uh, our, our team looked at that problem. And then we looked at, okay, there are a bunch of parameters and ways that I can tune this application. And, uh, why are the configurations set the way that they are? And, you know, uh, is there room to explore? And that's really where, unfortunately, >>Because Mesa said much greater enterprise capabilities as the Docker swarm, at least they were heading in that direction, but you still saw that Kubernetes was, was attractive because even though it didn't have all the security features and enterprise features, because it was just so simple. I remember Jen Goldberg who was at Google at the time saying, no, we were focused on keeping it simple and we're going from mass adoption, but does that kind of what you said? >>Yeah. And we made a bet, honestly. Uh, we saw that the, uh, you know, the growing community was really starting to, you know, we had a little bit of an inside view because we had, we had someone that was very much in the, in the original part, but you also saw the, the tool chain itself start to, uh, start to come into place right. A little bit. And it's still hardening now, but, um, yeah, we, as any, uh, as any startup does, we, we made a pivot and we made a bet and, uh, this, this one paid off >>Well, it's interesting because, you know, we said at the time, I mean, you had, obviously Amazon invented the modern cloud. You know, Microsoft has the advantage of has got this huge software stays, Hey, just now run it into the cloud. Okay, great. So they had their entry point. Google didn't have an entry point. This is kind of a hail Mary against Amazon. And, and I, I wrote a piece, you know, the improbable, Verizon, who Kubernetes to become the O S you know, the cloud, but, but I asked, did it make sense for Google to do that? And it never made any money off of it, but I would argue they, they were kind of, they'd be irrelevant if they didn't have, they hadn't done that yet, but it didn't really hurt. It certainly didn't hurt Amazon EKS. And you do containers and your customers you've embraced it. Right. I mean, I, I don't know what it was like early days. I remember I've have talked to Amazon people about this. It's like, okay, we saw it and then talk to customers, what are they doing? Right. That's kind of what the mindset is, right? Yeah. >>That's, I, I, you know, I've, I've been at Amazon a couple of years now, and you hear the stories of all we're customer obsessed. We listened to our customers like, okay, okay. We have our company values, too. You get told them. And when you're, uh, when you get first hired in the first day, and you never really think about them again, but Amazon, that really is preached every day. It really is. Um, uh, and that we really do listen to our customers. So when customers start asking for communities, we said, okay, when we built it for them. So, I mean, it's, it's really that simple. Um, and, and we also, it's not as simple as just building them a Kubernetes service. Amazon has a big commitment now to start, you know, getting involved more in the community and working with folks like storm forage and, and really listening to customers and what they want. And they want us working with folks like storm florigen and that, and that's why we're doing things like this. So, well, >>It's interesting, because of course, everybody looks at the ecosystem, says, oh, Amazon's going to kill the ecosystem. And then we saw an article the other day in, um, I think it was CRN, did an article, great job by Amazon PR, but talk about snowflake and Amazon's relationship. And I've said many times snowflake probably drives more than any other ISV out there. And so, yeah, maybe the Redshift guys might not love snowflake, but Amazon in general, you know, they're doing great three things. And I remember Andy Jassy said to me, one time, look, we love the ecosystem. We need the ecosystem. They have to innovate too. If they don't, you know, keep pace, you know, they're going to be in trouble. So that's actually a healthy kind of a dynamic, I mean, as an ecosystem partner, how do you, >>Well, I'll go back to one thing without the work that Google did to open source Kubernetes, a storm forge wouldn't exist, but without the effort that AWS and, and EKS in particular, um, provides and opens up for, for developers to, to innovate and to continue, continue kind of operationalizing the shift to Kubernetes, um, you know, we wouldn't have nearly the opportunity that we do to actually listen to them as well, listen to the users and be able to say, w w w what do you want, right. Our entire reason for existence comes from asking users, like, how painful is this process? Uh, like how much confidence do you have in the, you know, out of the box, defaults that ship with your, you know, with your database or whatever it is. And, uh, and, and how much do you love, uh, manually tuning your application? >>And, and, uh, obviously nobody's said, I love that. And so I think as that ecosystem comes together and continues expanding, um, it's just, it opens up a huge opportunity, uh, not only for existing, you know, EKS and, uh, AWS users to continue innovating, but for companies like storm forge, to be able to provide that opportunity for them as well. And, and that's pretty powerful. So I think without a lot of the moves they've made, um, you know, th the door wouldn't be nearly as open for companies like, who are, you know, growing quickly, but are smaller to be able to, you know, to exist. >>Well, and I was saying earlier that, that you've, you're in, I wrote about this, you're going to get better capabilities. You're clearly seeing that cluster management we've talked about better, better automation, security, the whole shift left movement. Um, so obviously there's a lot of momentum right now for Kubernetes. When you think about bare metal servers and storage, and then you had VM virtualization, VMware really, and then containers, and then Kubernetes as another abstraction, I would expect we're not at the end of the road here. Uh, what's next? Is there another abstraction layer that you would think is coming? Yeah, >>I mean, w for awhile, it looked like, and I remember even with our like board members and some of our investors said, well, you know, well, what about serverless? And, you know, what's the next Kubernetes and nothing, we, as much as I love Kubernetes, um, which I do, and we do, um, nothing about what we particularly do. We are purpose built for Kubernetes, but from a core kind of machine learning and problem solving standpoint, um, we could apply this elsewhere, uh, if we went that direction and so time will tell what will be next, then there will be something, uh, you know, that will end up, you know, expanding beyond Kubernetes at some point. Um, but, you know, I think, um, without knowing what that is, you know, our job is to, to, to serve our, you know, to serve our customers and serve our users in the way that they are asking for that. >>Well, serverless obviously is exploding when you look again, and we tucked the ETR survey data, when you look at, at the services within Amazon and other cloud providers, you know, the functions off, off the charts. Uh, so that's kind of an interesting and notable now, of course, you've got Chandler, you've got edge in your title. You've got hybrid in, in your title. So, you know, this notion of the cloud expanding, it's not just a set of remote services, just only in the public cloud. Now it's, it's coming to on premises. You actually got Andy, Jesse, my head space. He said, one time we just look at it. The data centers is another edge location. Right. Okay. That's a way to look at it and then you've got edge. Um, so that cloud is expanding, isn't it? The definition of cloud is, is, is evolving. >>Yeah, that's right. I mean, customers one-on-one run workloads in lots of places. Um, and that's why we have things like, you know, local zones and wavelengths and outposts and EKS anywhere, um, EKS, distro, and obviously probably lots more things to come. And there's, I always think of like, Amazon's Kubernetes strategy on a manageability scale. We're on one far end of the spectrum, you have EKS distro, which is just a collection of the core Kubernetes packages. And you could, you could take those and stand them up yourself in a broom closet, in a, in a retail shop. And then on the other far in the spectrum, you have EKS far gate where you can just give us your container and we'll handle everything for you. Um, and then we kind of tried to solve everything in between for your data center and for the cloud. And so you can, you can really ask Amazon, I want you to manage my control plane. I want you to manage this much of my worker nodes, et cetera. And oh, I actually want help on prem. And so we're just trying to listen to customers and solve their problems where they're asking us to solve them. Cut, >>Go ahead. No, I would just add that in a more vertically focused, uh, kind of orientation for us. Like we, we believe that op you know, optimization capabilities should transcend the location itself. And, and, and so whether that's part public part, private cloud, you know, that's what I love part of what I love about EKS anywhere. Uh, it, you know, you shouldn't, you should still be able to achieve optimal results that connect to your business objectives, uh, wherever those workloads, uh, are, are living >>Well, don't wince. So John and I coined this term called Supercloud and people laugh about it, but it's different. It's, it's, you know, people talk about multi-cloud, but that was just really kind of vendor diversity. Right? I got to running here, I'm running their money anywhere. Uh, but, but individually, and so Supercloud is this concept of this abstraction layer that floats wherever you are, whether it's on prem, across clouds, and you're taking advantage of those native primitives, um, and then hiding that underlying complexity. And that's what, w re-invent the ecosystem was so excited and they didn't call it super cloud. We, we, we called it that, but they're clearly thinking differently about the value that they can add on top of Goldman Sachs. Right. That to me is an example of a Supercloud they're taking their on-prem data and their, their, their software tooling connecting it to AWS. They're running it on AWS, but they're, they're abstracting that complexity. And I think you're going to see a lot, a lot more of that. >>Yeah. So Kubernetes itself, in many cases is being abstracted away. Yeah. There's a disability of a disappearing act for Kubernetes. And I don't mean that in a, you know, in an, a, from an adoption standpoint, but, uh, you know, Kubernetes itself is increasingly being abstracted away, which I think is, is actually super interesting. Yeah. >>Um, communities doesn't really do anything for a company. Like we run Kubernetes, like, how does that help your bottom line? That at the end of the day, like companies don't care that they're running Kubernetes, they're trying to solve a problem, which is the, I need to be able to deploy my applications. I need to be able to scale them easily. I need to be able to update them easily. And those are the things they're trying to solve. So if you can give them some other way to do that, I'm sure you know, that that's what they want. It's not like, uh, you know, uh, a big bank is making more money because they're running Kubernetes. That's not, that's not the current, >>It gets subsumed. It's just become invisible. Right. Exactly. You guys back to the office yet. What's, uh, what's the situation, >>You know, I, I work for my house and I, you know, we go into the office a couple of times a week, so it's, it's, uh, yeah, it's, it's, it's a crazy time. It's a crazy time to be managing and hiring. And, um, you know, it's, it's, it's, it's definitely a challenge, but there's a lot of benefits of working home. I got two young kids, so I get to see them, uh, grow up a little bit more working, working out of my house. So it's >>Nice also. >>So we're in, even as a smaller startup, we're in 26, 27 states, uh, Canada, Germany, we've got a little bit of presence in Japan, so we're very much distributed. Um, we, uh, have not gone back and I'm not sure we will >>Permanently remote potentially. >>Yeah. I mean, w we made a, uh, pretty like for us, the timing of our series B funding, which was where we started hiring a lot, uh, was just before COVID started really picking up. So we, you know, thankfully made a, a pretty good strategic decision to say, we're going to go where the talent is. And yeah, it was harder to find for sure, especially in w we're competing, it's incredibly competitive. Uh, but yeah, we've, it was a good decision for us. Um, we are very about, you know, getting the teams together in person, you know, as often as possible and in the safest way possible, obviously. Um, but you know, it's been a, it's been a pretty interesting, uh, journey for us and something that I'm, I'm not sure I would, I would change to be honest with you. Yeah. >>Well, Frank Slootman, snowflakes HQ to Montana, and then can folks like Michael Dell saying, Hey, same thing as you, wherever they want to work, bring yourself and wherever you are as cool. And do you think that the hybrid mode for your team is kind of the, the, the operating mode for the, for the foreseeable future is a couple of, >>No, I think, I think there's a lot of benefits in both working from the office. I don't think you can deny like the face-to-face interactions. It feels good just doing this interview face to face. Right. And I can see your mouth move. So it's like, there's a lot of benefits to that, um, over a chime call or a zoom call or whatever, you know, that, that also has advantages, right. I mean, you can be more focused at home. And I think some version of hybrid is probably in the industry's future. I don't know what Amazon's exact plans are. That's above my pay grade, but, um, I know that like in general, the industry is definitely moving to some kind of hybrid model. And like Matt said, getting people I'm a big fan at Mesa sphere, we ran a very diverse, like remote workforce. We had a big office in Germany, but we'd get everybody together a couple of times a year for engineering week or, or something like this. And you'd get a hundred people, you know, just dedicated to spending time together at a hotel and, you know, Vegas or Hamburg or wherever. And it's a really good time. And I think that's a good model. >>Yeah. And I think just more ETR data, the current thinking now is that, uh, the hybrid is the number one sort of model, uh, 36% that the CIO is believe 36% of the workforce are going to be hybrid permanently is kind of their, their call a couple of days in a couple of days out. Um, and the, the percentage that is remote is significantly higher. It probably, you know, high twenties, whereas historically it's probably 15%. Yeah. So permanent changes. And that, that changes the infrastructure. You need to support it, the security models and everything, you know, how you communicate. So >>When COVID, you know, really started hitting and in 2020, um, the big banks for example, had to, I mean, you would want to talk about innovation and ability to, to shift quickly. Two of the bigger banks that have in, uh, in fact, adopted Kubernetes, uh, were able to shift pretty quickly, you know, systems and things that were, you know, historically, you know, it was in the office all the time. And some of that's obviously shifted back to a certain degree, but that ability, it was pretty remarkable actually to see that, uh, take place for some of the larger banks and others that are operating in super regulated environments. I mean, we saw that in government agencies and stuff as well. >>Well, without the cloud, no, this never would've happened. Yeah. >>And I think it's funny. I remember some of the more old school manager thing people are, aren't gonna work less when they're working from home, they're gonna be distracted. I think you're seeing the opposite where people are too much, they get burned out because you're just running your computer all day. And so I think that we're learning, I think everyone, the whole industry is learning. Like, what does it mean to work from home really? And, uh, it's, it's a fascinating thing is as a case study, we're all a part of right now. >>I was talking to my wife last night about this, and she's very thoughtful. And she w when she was in the workforce, she was at a PR firm and a guy came in a guest speaker and it might even be in the CEO of the company asking, you know, what, on average, what time who stays at the office until, you know, who leaves by five o'clock, you know, a few hands up, or who stays until like eight o'clock, you know, and enhancement. And then, so he, and he asked those people, like, why, why can't you get your work done in a, in an eight hour Workday? I go home. Why don't you go in? And I sit there. Well, that's interesting, you know, cause he's always looking at me like, why can't you do, you know, get it done? And I'm saying the world has changed. Yeah. It really has where people are just on all the time. I'm not sure it's sustainable, quite frankly. I mean, I think that we have to, you know, as organizations think about, and I see companies doing it, you guys probably do as well, you know, take a four day, you know, a week weekend, um, just for your head. Um, but it's, there's no playbook. >>Yeah. Like I said, we're a part of a case study. It's also hard because people are distributed now. So you have your meetings on the east coast, you can wake up at seven four, and then you have meetings on the west coast. You stay until seven o'clock therefore, so your day just stretches out. So you've got to manage this. And I think we're, I think we'll figure it out. I mean, we're good at figuring this stuff. >>There's a rise in asynchronous communication. So with things like slack and other tools, as, as helpful as they are in many cases, it's a, it, isn't always on mentality. And like, people look for that little green dot and you know, if you're on the you're online. So my kids, uh, you know, we have a term now for me, cause my office at home is upstairs and I'll come down. And if it's, if it's during the day, they'll say, oh dad, you're going for a walk and talk, you know, which is like, it was my way of getting away from the desk, getting away from zoom. And like, you know, even in Boston, uh, you know, getting outside, trying to at least, you know, get a little exercise or walk and get, you know, get my head away from the computer screen. Um, but even then it's often like, oh, I'll get a slack notification on my phone or someone will call me even if it's not a scheduled walk and talk. Um, uh, and so it is an interesting, >>A lot of ways to get in touch or productivity is presumably going to go through the roof. But now, all right, guys, I'll let you go. Thanks so much for coming to the cube. Really appreciate it. And thank you for watching this cube conversation. This is Dave Alante and we'll see you next time.