(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)

>>from San Francisco. It's the queue every day to thank you. Brought to you by day to like you. Hey, >>welcome back already, Jeffrey. Here with the Cube were a day to IQ's headquarters in downtown San Francisco. They used to be metal sphere, which is what you might know them as. And they've rebranded earlier this year. And they're really talking about helping Enterprises in their journey to cloud native. And we're really excited to have really one of the product guys he's been here and seeing this journey and how through with the customers and helping the company transforming his Chandler hosing tonight. He's the s VP of engineering and product. Chandler, great to see you. Thanks. So, first off, give everyone kind of a background on on the day to like you. I think a lot of people knew mesosphere. You guys around making noise? What kind of changed in the marketplace to to do a rebranding? >>Sure. Yeah, we've been obviously, Mason's here in the past and may so so I think a lot of people watching the cube knows No, no one knows about Mace ose as as we were going along our journey as a company. We noticed that a lot of people are also asking for carbonates. Eso We've actually been working with kubernetes since I don't know 16 4017 something that for a while now and as Maur Maur as communities ecosystem starting involving mature more. We also want to jump in and take advantage of that. And we started building some products that were specific to kubernetes and eso. We thought, Look, you know, it's a little bit confusing for people May, SOS and Kubernetes and at times those two technologies were seen almost as competitive, even though we didn't always see it that way. The market saw it that way, so we said, Look, this is going too confusing for customers being called Mesa Sphere. Let's let's rebrand around Maur what we really do. And we felt like what we do is not just focus around one specific technology. We felt like we helped customers with more than that more than just may so support more than just community support, Andi said. Look, let's let's get us a name that shows what we actually do for customers, and that's really helping them take their workloads and put them on on Not just, you know, um, a source platform, but actually take their workloads, bring them into production and enterprise way. That's really ready for day two. And that's that's why we called it data. >>And let's unpack the day to, cause I think some people are really familiar with the concept of day two. And for some people, they probably never heard it. But it's a pretty interesting concept, and I think it packs a lot of meaning in it. A number of letters. I think you >>can kind of just think about it if you were writing software, right? I mean, Day zero is okay. We're gonna design it. We're gonna start playing with some ideas. We're gonna pull into different technologies. We're gonna do a POC. We're gonna build our skateboards. So to say, that's kind of your day. Zero. What do we want? Okay, we're gonna build a Data Analytics pipeline. We want spark. We're going to store data. Cassandra, we're gonna use cough. Go to pass it around. We're gonna run our containers on top of communities. That's just kind of your day. Zero idea. You get it working, you slap it on a cluster. Things are good right? Day one might be okay. Let's actually do a beta put in production in some kind of way. You start getting customers using it. But now, in Day two, after all that's done, you're like, Wait a second. Things were going wrong. Where's our monitoring? We didn't set that up. Where's our logging? Oh, I don't know. Like, >>who do we >>call this? Our container Run time, we think has above. Who do we call like? Oh, I don't know What support contract that we cut, Right? So that's the things that we want to help customers with. We want to help them in the whole journey, getting to Day two. But once they're there, we want them to be ready for day two, right? And that's what we do. >>I love it because one of my favorite quotes I've used it 1000 times. I'll do 2001 right? Is that open source is free like a puppy. Exactly for you. When you leave you guys, you're not writing a check necessarily to the to the shelter, But there's a whole lot of other check. You got a right and take care of. And I think that's such a key piece. Thio Enterprise, right. They need somebody to call when that thing breaks. >>Yeah. I mean, I haven't come from enterprise company. I was actually a customer basis Fear before I joined. Yeah, that's exactly why we're customers that we wanted. Not only that, insurance policy, but someone that partner with us as we start figuring this out, you know? I mean, just picking. You know what container run time do I want to use with communities? That one decision could take months if you're not familiar with it. And you you put a couple of your best architects on it. Go research container. You go research, cryo go research doctor. Tell me what's what's the best one we should use with kubernetes. Whereas if you're going, if you have a partnership with a company like day two, you can say, Look, I trust these. You know this company, they they're they're experts of this and they see a lot of this. Let's go with their recommendation. It's >>okay. So you got you got your white board. You've got a whole bunch of open source things going on, right? And you've got a whole bunch of initiatives and the pressure's coming down from from on high to get going, you've got containers, Asian and Cloud native and hybrid Cloud all the stuff. And then you've got some port CEO on his team trying to figure it out. You guys have a whole plethora of service is around some of these products. So as you try it and then you got the journey right and you don't start from from a standing start. You gotta go. You gotta go. So how do you map out the combination of how people progress through their journey? What are the different types of systems that they want to put in place and into, prioritize and have some type of a logical successful implementation and roll out of these things from day zero day 132? No, it's >>a great question. I think that's actually how we formed our product. Strategy is we've been doing this for a while now and we've we've gone. We've gone on this journey with really big advanced customers like ride sharing companies and large telcos customers like that. We've also gone on this journey with smaller, less sophisticated customers like, you know, industrial customers from the Midwest. Right? And those are two very, very different customers. But what's similar is they're both going on the same journey we feel like, but they're just at different places. So we wanted to build products, find the customer where they're at in their journey, and the way we see it really is just at the very beginning. It's just training, right? So we have, ah, bunch of support. We're sorry. Service is around training. Help you understand? Not just kubernetes, but the whole cloud native ecosystem. So what is all this stuff? How does it work? How does it fit together? How do I just deploy simple app to right? That's the beginning of it. We also have some products in that area as well, to help people scale their training across the whole whole organization. So that's really exciting for us once once, once that customer has their training down there like Okay, look, get I need a cluster now, like I need a destroyer of sorts and criminals itself is great, but it needs a lot of pieces to actually get it ready for prime time. And that's where we build a product called Convoy Say Okay, here is your enterprise great. Ready to go kubernetes destro right out of the box. And that product is really it's what you could use to just fiddle around with communities. It's also what you put into production right on the game. That's that's been scale tested, security tests and mixed workload tested. It's everything. So that's that's kind of our communities. Destro. So you've gotten your training. You have your destro and now you're like, OK, I actually wanna want to run some applesauce. >>Let me hold there. Is it Is it open corps? Or, you know, there's a lot of conversation in the way the boys actually >>the way we built convoy. It's a great question. The way we build convoys said, Okay, we don't We want to pick the best of breed from each of these. Have you seen the cloud native ecosystem kind of like >>by charter, high charter, whatever it is, where they have all the logos and all the different spiral thing. So it's crazy. Got thousands of logos, right? And >>we said, Look, we're gonna navigate this for you. What's the best container run time to pick. And it's It's almost as if we were gonna build this for ourselves using all open source technology. So convoys completely opens. Okay, um, there's some special sauce that we put in on how to bring these things together. Install it. But all the actual components itself is open source. Okay, so that's so if you're a customer, you're like, OK, I want open source. I don't want to be tied to any specific vendor. I want to run on Lee open. So >>yeah, I was just thinking in terms of you know, how Duke is a reference right. And you had, you know, the Horton worst cloud there and map our strategies, which were radically different in the way they actually packaged told a dupe under the covers. Yeah, >>you can think of it similar. How Cloudera per ship, Possibly where they had cdh. And they brought in a lot of open source. But they also had a lot of proprietary components to see th and what we've tried to get away from it is tying someone in tow. Us. I know that sounds counterintuitive from a business perspective, but we don't want customers to feel like if I go with D to like you. I always have to go with me to like you. I have to drink the Kool Aid, and I'm never gonna be able to get off. >>Kind of not. Doesn't really go with the open source. Exactly this stuff. It's not >>right for our customers, right? A lot of our customers want that optionality, and they don't want to feel locked in. And so when we built convoy, he said, Look, you know, if we were to start our own company, not not an infrastructure coming that we are right now, but just a software company build any kind of ab How would we approach it? And that was one of the problems we saw for We don't wanna feel like we're tied into any. >>Right. Okay, so you got to get the training, you got the products. What's >>next? What's next is if you think about the journey, you're like, OK, a lot. What we've found and this may or may not be totally true is one of the first things people like to run on committees is actually they're builds. So see, I see. And we said, How can we help with this. We looked around the market and there's a lot of great see, I see products out there right now. There's get lab, which is great partner of ours. It's a great product. There's there's your older products. Like Jenkins. There's a bunch of sass products, Travis. See all these things. But what we we wanted to do if we were customers of our own products is something that was native to Kubernetes. And so we started looking at projects like tectonic and proud. Some of these projects, right? And we said, How can we do the same thing we did with convoy where we bring these projects together and make it easy for someone to adopt these kubernetes native. See, I see tools. And we did some stuff there that we think is pretty innovative as well. And that's what that's the product we call dispatch. >>Okay. What do you got? More than just products. You've got profession service. That's right. So now >>you need help setting all this up. How do you actually bring your legacy applications to this new platform? How do you get your legacy builds onto these new build systems That that's where our service is coming the plate and kind of steer you through this whole journey. Lastly, what we next in the journey, though? Those service's compliment Really? Well, with with the kind of the rest of the product suite, right? And we didn't just stop with C i c. He said, what is the next type of work that we want to run here? Okay, so there we looked at things like red hat operators. Right? And we said, Look, red hats doing really cool thing here with this operator framework, how can we simplify it? We learn we've done a lot of this before with D. C. O s, where we built what we called the DCS sdk to help people bring advanced complex workloads onto that platform. And we saw a lot of similarities with operators to our d c West sdk. We said, How can we bring some of our understanding and knowledge to that world? And we built this open source product called kudo. Okay, people are free to go check that out. And that's how we bring more advanced workload. So if you think about the journey back to the journey again, you got some training you have your have your cluster, you put your builds on it. Now you want to run some advance work logs? That's where Kudo comes. >>Okay? And then finally, at the end of the trail is 1 800 I need help. Well, almost into the trail. We're not there yet. There was one thing they're still moving with one more step right on >>the very last one. Actually, we said, Okay, what's next in this journey? And that's running multiple clusters of the same. Okay, so that's kind of the scale. That's the end of the journey from for us, for our proxy as it stands right now. And that's where you build a product called Commander. And that's really helping us launch and manage multiple >>companies clusters at the same time. >>So it's so great that you have the perspective of a customer and you bring that directly in two. You know what you want because you just have gone through this this journey. But I'm just curious, you know, if you put your old hat on, you know, kind of c i o your customer. You know, you just talked about the cake chart with Lord knows how many logos? How do you help people even just begin to think about about the choices and about the crazy rapid change in what? That I mean? Kubernetes wasn't a thing four years ago to help them stay on top of it to help them, you know, both kind of have a night to the vision, you know, make sure you're delivering today on not just get completely distracted by every bright, shiny object that happens to come along. Yeah, no, >>I think it's really challenging for the buyers. You know, I think there's a, especially as the industry continues to make sure there's a new concept that gets thrown at all times. Service Manager. You know, some new, cool way to do monitoring or logging right? And you almost feel like a dinosaur. If you're not right on top of these things to go to a conference in, are you using? You know, you know B P f. Yet what is that? You didn't feel right? Exactly. I think I think most importantly, what customers want is the ability what, the ability to move their technology and their platforms as their business has the need. If the need isn't there for the business, and the technology is running well. There shouldn't be a reason to move to a new platform. Our new set of technologies, in fact, with dese us with Mason charities. To us, we have a lot of happy customers that are gonna be moving crib. Amazing if they wanted to anytime soon. Do you see What's that? Something's that criminal is currently doesn't do. It may never do because the community is just not focused on it that DCS is solving. And those customers just want to see that will continue to support them in the journey that they're on with their their business. And I think that's what's most important is just really understanding our customer's understanding their business, understand where they wanna go. What are their goals, So to say, for their technology platforms and and making sure you were always one step ahead >>of them, that's a >>good place to be one step ahead of demand. All right, well, thanks for for taking a few minutes and sharing the story. Appreciate it. Okay. Thank you. All right. Thanks. Chandler. I'm Jeff. You're watching >>the Cube. Where? Day two. I >>Q in downtown San Francisco. Thanks for watching. We'll see you next time

>>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.