Ladies and gentlemen, this is the main event of the day, chagrined by that at the club level data, such a software company with executive producer of this debate, Chu and CMO James White for our community roundtable is led by leaders from across the industry and around the world. And when the action begins, our moderator in charge of the debate is Regehr by. Now for those nerds in attendance with application to delivers club users from around the world, this is the moment you truly all have been waiting for. My brother dug up virtual studio. Your home office has a. Time in three rounds for the next hour, we will finally settle the debate between containers and surplus computer technology. Two of today's hottest technologies for application deployment when used the right way, they both help Europe's teams to deploy applications faster and more cost, effectively if producing part of the red corner and representing server computing. He is a W.S. journalist. Terho noted industry influence and thought leader sparring out of Charlotte North. I know he is an enterprise cloud architect, speaker, community advocate and director of culture and community and a love guru. He is Auris Rossel. And his opponent name out of the blue corner and representing containers, he is the senior director of technology and CTO of But By Not Out and is pouring out of Annapolis, Maryland, with more than 20 years of experience in designing and running hyperscale applications. He's gone from bare metal to virtual the cloud, the serverless and back again. He is Heather. A book from. Let's have a good debate. Take it away. But thank you, Bruce. Wow, I don't know if we'll be able to match Bruce's energy, but I do want to make this debate real and tangible. Chances are if you're a developer or a developer team, you've had a polarizing conversation or two about containers versus serverless. While servo's computing has taken its place as the cool kid on the block, the dialog and the tech continue to evolve and this debate will expose some fresh perspectives that might surprise you. This is so much more than the right tool for the right job. And as we go through this debate, I'm going to be listening for a better understanding of workload's use cases and goals. And don't forget to get more information, please visit and tap dotcom. That's an untapped dot com slash its time. So before we jump into the debate, I'd like to first introduce our distinguished panel. First up, Cheryl Heung, VP of Ecosystem at the Cloud Native Computing Foundation. Hey, Greg, great to see you, and it's awesome to be here. Fantastic, and Josh Attwell, senior technology advocate at Splunk. Hey, Greg, thanks for having me. Hopefully I don't say anything stupid. I'm sure you won't. It's all going to be good, Josh. And last but not least, Kathleen Field's developer advocate at Google. Hello out there. I'm excited to hear from everyone today. That's great. And so am I. And with that Kevin inforce, I want a clean debate, no cheap shots and keep your guard up at all times. Take it away, Kevin. Thank you very much. Greg, it's great to be here. It's great to be here, especially with force, who's well known very well in the service industry. And I know we're going to have a great discussion on on Containers and Cervalis. So I'm going to jump right into it. I'm going to come out with my statement. Containers are brilliant. I love containers. I've been around the industry for a long time and I remember, you know, what life was like well before containers. And that's actually not too long ago. But before containers, how we packaged and deliver applications, everybody had their own way to do it. Everyone had their their own language, their own policies, their own pipelines. Things were very customized on how to get your applications to production and then how to scale them in production or even even language and application specific. And then containers really got commodities by Docker. And everybody was able to use this one construct to package and deploy applications. And and that construct is also defining how we package our applications together, defining that we can put any code we want with any requirements, with any libraries in this box, and then take that box and have a definition around it of how other people can run this. And all you need is a Linux kernel. And that was really amazing. And it's it's more than just packaging. It's it's an entire development change on how you move code from a developer's fingertips to production. At the same time, we were able to cut down on dependencies that you install on servers. You're able to scale better. You're able to take these tiny objects instead of these big VMS, and you're able to move them around from environment, from environment, from development to stage production, or even when they get in production, how you scale containers once they get there. And this was a really, really big paradigm shift in how we were looking at things before this. We were building VMS or, as I said, building custom models. And now we had kind of this universal way to deliver applications. So what did we do with this newfound power? We made it insanely complex or we tried to at least everyone came out with these different schedulers and different ways to run containers because it wasn't good enough. Right. Like we saw the power of containers and containers are awesome. And we said, but this is new. We need to give it all new concepts. So we need to give it all new ways to scale and to run once you get to the cloud. So we came up with me so so we came with Docker Swarm and we came up with Cuban Êtes and Branch had their own scheduling tool at the time and no one really knew they had this container. And then you had all these new constructs on how to run it. And things started breaking down a little bit. It's like, OK, I had this container, I saw the value of it in production, but how do I run it? And things got complex. And around this same time, Serverless came into the mix and I will say Serverless picked out this this this problem with where the containers movement was going with you're getting out of hand. You came up with this great concept and now you don't know what to do with it. And Serverless came in and said, hey, why are you worried about all this stuff? You know, bring it down to the basic concepts. And this is not the first time that we've tried to do this. We love services. You know, going back in the day, we had application service providers and then we went to infrastructure as a service and we went to platforms as a service. Containers are an evolution in this and then functions and functions as a service, which is the earliest, earliest adoption of Cervalis really told us, like, hey, you're getting too complex on the scale, hand over your code to somebody and let them run it. And we thought, hey, that's great. This takes out some of the complexity of these really, really big schedulers. But what happened there is every time we expand and we break out, we end up contracting again. And as we were running surplus and as we were running functions, all of these other things started coming up like how do I control the layers? How do I control the dependencies of my application? How do I control cold cold starts? How do I control custom libraries? How can I not? I block my application. So one request doesn't take up a whole bunch of CPU and memory all by itself. And we started asking all these questions and the community's actually starting to getting together. And what we found out is that you need something in both worlds and Serverless gets a lot of credit here and in fact gets a lot of credit. They started adding some provision, concert currency, more memory ops. And CPU's, but actually they just started ended up more and more like container's until the end of the day, they've actually implemented Container's as Cervalis. So both of these concepts of kind of grown up over time. But I think the Fairline ideology on how to deliver an application and what I want to scale at the end of the day is closer to being a container than it is necessarily to a function. But what container's has taken from functions and the Cervalis movement is that there needs to be an easier way to run these things. And with the complexity that we add, you know, we've taken a look at this in the products we've built like ocean is how do you make containers as simple as possible to run? Because they provide all of these constructs. And then not only that, but for certain applications, a lot of applications that run at hyperscale. How do you have access to the latest and greatest hardware? How do you have access to the best networking? How do you have access to all of the bells and whistles and the knobs and everything that you need to turn tune to make your application run as efficiently as possible? So what do I need to ask myself during all of this? Like, wee wee wee containers have this great power to be able to be deployed anywhere. They have this power to use the storage. You want the network, you want the instant types, you want the CPU processors you want. You need to think about what is the utility of that and how you manage that once you get to the cloud. Now, communities is becoming a lot easier to run. The the we've we've narrowed down on that. We've mesos. I mean, there's still some implementations of that around, but other schedulers have kind of fallen off. This is a good thing. This is good that people have decided as I'm going to go to the cloud, I have one place to run. And Cooper, Dennis has been that winner. So now we can keep making Carbonetti easier to run. And as we keep making companies easier to run and as we find ways to make container scale, you get a lot of these original serverless concepts that you wanted out of the beginning of Cervalis with containers. Now, what do you need to ask yourself when you're talking about this service services or Cervalis versus Container's paradigm? And that's what what utility am I getting out of the platform and what utility do I need for my dev ops teams and my operation teams themselves? So when I run container's I have control over am I using arm, am I using CPU, am I using GPU, am I using low network, am I using high network? Where is my cost savings. You have the power to control these different options. And when you're starting now, these options may not be the most important things to you to get started and get running quickly. But I can tell you right now, when you start running millions and millions and millions of transactions per second, optimization and cost efficiency and everything that you're doing down to the application level matters a whole lot. You also need to think about your operations teams. Cervalis doesn't necessarily take away support. You still have to support everything you deploy, even if you're leaning on somebody else to run your code. If something happens with that, you need to have the backup strategy on what you're going to do with that particular service goes down. Are you going to have the flexibility to move the way you want to now? You can answer that on both sides. Container's give you an option to move things fairly easily. Now, with that management, you have to decide, am I going to manage fast and Ayaz and Pazz and Container's can my operations teams handle that? Will I just manage? Can can I just manage my eyes? Can I just manage my containers? These are real questions that you need to ask and where your level of support and what you feel comfortable with at the end of the day. So. What I'm saying here is containers have allowed us to run both our legacy applications and our modern applications in a defined, similar way that allows dev ops teams and engineers to move fast together to any cloud they want to move to to any system they want to move to and to be able to scale in any way that they want to go. And along the way, if you can pick up some Cervalis things that fit in between the cracks, I think that's good. But I think for our big applications, our biggest customers, from what we see in the world, containers have really changed the way that we deploy to production, and they've really changed the way on how we use cloud in general. So with that, I'll pass it up to force. Thanks, Kevin, and appreciate your thoughts there. And look, as I begin my defense of Cervalis here, the first thing I want to acknowledge is that Serverless, as a coach shipping paradigm, is dead. Yes, it has its die hard proponent's. There's pockets of the industry where it's being used with great success. Amazon says they're using land it today to run about half of all their new development. But fase function as a service. Let's be real. It's not taken over the world, not the way we thought that it might. Those of us who were all excited about Serverless four or five years ago, developers as a whole have spoken loud and clear. Containers are how they once packaged code. Even Lamda itself kind of threw in the towel and reinvent this past December when they announced that they will now support containers as a packaging abstraction for them and not just zip files. Containers have won the battle of packaging abstractions, but as value shifts up the stack, I want to ask you who carries the serverless mindset is what's eating the world, not the packaging abstraction, not the specific technology, not functions as a service. Don't get hung up on that. It's all about this mindset and I define the mindset as own less build more. Not just on cloud provider services like your Dinamo DB, your apps take your step functions. Right, but all these other tools like a Zappia and Twilio and zero and a net Lafi and Stripe, all these services that break off little pieces of your application workflow that everybody used to have to roll on their own and takes those and makes them something you can consume so that you can focus more of your time on building what's truly important. That's the surplus mindset of ownerless build more. The containers mindset, on the other hand, is about hedging. It's about delivering the same software that we did ten years ago, just as you said, Kevin, just with a new skin of cloud, best practices on top and for a lot of legacy use cases, that's great and it's necessary and we're going to need it for a long time. Don't get me wrong. Yeah, containers. Right. They scratch an itch, they fill a need. But ultimately, containers are about repackaging the past. Serverless is about reimagining the future. If you again, if you think that future is fast function as a service, it's not about fase. You're too hung up on that, as is not the hammer that pounds in every nail. Instead, I want you to be thinking as you're developing new applications about how you can own less and build more, whatever that means. And to eliminate that, I'm going to quickly run down three kind of counterintuitive reasons why Cervalis is fantastic. Reason number one, Serverless violates the second law of thermodynamics. Not really, but bear with me for just a second, OK? The traditional I.T. world is such that any time that I write a line of code and deploy to production, it begins to decay. Every time I take some hardware and I put it on a data center, it becomes legacy. And if I'm not constantly pouring engineer hours and maintenance hours into that code or that hardware, well, then I'm going to have problems, right? I'm going to fall behind my competitors. The serverless mindset takes that whole fundamental law of physics and turns it on its head. It says, hey, through the contract that you have with the service provider, these services are actually going to get better underneath you over time, not worse. They're not going to decay. They're going to improve and they're going to do that not just based on your needs and your use cases, but on the aggregate use cases of thousands of users of that technology. It's like having a great hive mind working on your behalf. And there's no better example of this than Dinamo Déby, one of my favorite Serverless services, Dinamo DBI, used to run under a billing model called Provisioned Capacity. It's still an available model. It's kind of a server full mindset where you say, I think I'll use about this much compute underneath my database. And that's what you pay for every month. The over it you get throttled. About two years ago, HWC released a new way of paying for Dinamo to be called Dinamo be on demand. And in that case, your capacity tracks really, really closely with your actual usage. The table scales with what you use and you pay for what you use. And that's expensive if you're using a lot. But if you're not using a lot of data, like in a development environment on a staging environment, Dinamo to be on demand capacity was a tremendous savings. I have a personal friend who saved about one hundred and twenty thousand dollars a year on their Dinamo DB bill just by checking that on demand capacity box when it became available one day in the console. To be clear, no engineering innovation required for this person, no refactoring required. It's one line of collaboration. If you want to deploy this programmatically or you can go check a box in the console. It just appeared yesterday. My Dinamo DBI tables were slower and cost more. Today they're faster and cost less. That's the power of the surplus mindset. Reason number two, perhaps an even more counterintuitive reason that Serverless is exciting. It's really, really expensive. OK, I'm saying that's a good thing, Serverless is expensive, but it's just money. It's just money. Think about we talk about, you know, free as in beer, free as in speech. And we started to say, is it free? As in no, OP's right. Is it free? As in the amount of additional time and brainpower that I have to spend keeping the service up and running. We have this tendency as developers to want to build rather than buy. Right. To look at the, for example, a managed logging service and say, oh, I don't want to pay for that. I could just run this opensource elk stack or whatever on my two instances. OK, but if I could consume limited service that does that, that's run by domain specialists who know everything about logging and think about it more than I ever do, then I can focus on the core of my business, which let's assume is not logging right. To quote my friend and fellow hero, Jared Shorters, long time service advocate, he reminds us that opportunities to efficiently trade dollars for engineering time are rare. OK, he says, I don't think we find a price tag yet on a truly great product. That wasn't a no brainer. So truly great is the kicker there. Right? You want to be best of breed with what you're deploying. But think about this. Serverless makes that tradeoff so much easier than it ever was in the past. All right. Those opportunities to efficiently trade dollars for engineering time, they're rare. But in the world of the surplus mindset, they're less rare. They're in front of you. And you can take that chance to spend the money free up, time to build, but provides more value long term. Third, counterintuitive reason that Cervalis is awesome. You ready for this in? That's right. Vendor lock in, cloud lock in, whatever you want to call it. I'm saying it's a good thing. It's actually a huge selling point of serverless. Bear with me. And let's be honest, everybody is locked in on something. You're locked in on your programing languages. You're locked in on your architectural choices. You're locked in on the business constraints and the regulatory constraints that you have. You're locked in on choices that people made 20 years ago, whether you like it or not. The question is, what do you want to be locked into? I think about a service like us, ayam, which I often refer to as the greatest form of cloud and much more so than something like Lamda or Container's right. That's code. If I really have to, I can pick that up and run it on another piece of compute somewhere that's pretty lowest, lowest common denominator stuff in the cloud world. OK, but I am undergirds every aspect of anything you want to build cloud natively and before you think that's a terrible thing, that's no different than like Active Directory, which was undergirding all of our authentication stuff 20 years ago. Right. But nobody's getting fired for choosing active directory. That made total sense in these large enterprise context. It was a well-supported implementation of something everybody needed was easy to go out and find talent that could support. It was well documented. All right. Even if you're really tied into it today and can't figure out how to get off of it, it enabled a lot of business value over a lot of years. And Serverless is the same way. You've got a benefit of cloud lockin as well in that you're able to take advantage of these native integrations. Think of all the triggers that plug into Lamba functions and the plug into these other managed services. The cloud provider has a vested interest in making it as easy as possible for all these services to talk to each other and play nice. And that lets you go faster and build more. Now, on the container side, to get a little bit controversial for a second, I would say you don't necessarily have the advantages of avoiding that vendor lock in that you might think you do. In fact, you may be setting yourself up for what I sometimes call back door lock it. All right. Because Kevin called it out. Containers are complex. Carbonetti is so complicated that we can't even say the whole word. We abbreviated Kate s right. Like it's the Hebrew name for God or something. And we do that because it's difficult to manage. And so we end up putting our Carbonetti sentences back in the hands of cloud providers through managed services like X and X. And these are all cases of the cloud providers saying, let's be real. You don't really want to deal with all this container orchestration stuff. Let us run it for you. And you say great and that's fine. But it's not this portable vendor neutral solution that you've been telling yourself that it is OK when it's time to move. And as you have all the integrations with that cloud providers manage service, you're going to experience pain. Don't kid yourself that you're not. That's back door locking. It looked like portability up front. It's cloud lock in on the back. And maybe I should call it a lock in Mullet's. I don't know. Anyway, to pull back from all that, the surplus mindset is great. It violates the second law of thermodynamics, OK, it's expensive, but only in the sense that it frees you up to spend your money on things that are more important. And it's it locks you in in a way that again allows you to build instead of buying. OK, so serverless the mindsets about owning less, building more. But I want to close the same way that I close my talk. Cervalis way back in Austin, Texas in twenty seventeen. Serverless is not a panacea. It's an idea that infrastructure can be structured like it's from IKEA. Running your code on compute. You don't manage free you to pursue your true business advantage. So go write a function, deploy in test and let the cloud do what the cloud does best. Greg, while that is absolutely fantastic, Kevin and forest and force, if I'm taking one thing away from this, I got to get a new haircut. So with that, you know, Cheryl, as I'm listening to this, I keep hearing the refrain of simplicity versus complexity. There's also cost and in elements here. But I'm curious if you're seeing that gap or what are the gaps that you're seeing between these technologies? Yeah, so first of all, Kevin Foster, thank you. Amazing, amazing presentations, talks from both of you. One of the fun things about being at CNF is we cover containers and Cervalis. So in a sense, cloud native winds, whoever wins the container versus Sevres debate. But I'll tell you about my own personal bias, I, I am an application developer by background. In 2010, 10 years ago, I started writing C++ and packaging it at Google using the equivalent of containers. So I have been thinking in containers for a really long time and I agree that containers are brilliant. But my own I want to say something I've never said on camera before. First time I kind of hate infrastructure, but I'm like, I don't want to think about infrastructure. I'm an application developer. Just let me write code. Let me forget about it forever. Let me just assume it works perfectly. So I do love that whole, you know, own less build more mindset because that is exactly how I want to think as an application developer. Fantastic, Josh, I see you kind of wince a little bit about infrastructure there for a quick second. Well, maybe just a little bit, you know, having a background deep entrenched with infrastructure, but also with a background in application development. And I want to be a strong proponent for Serverless because I do think Forrest is correct in the way that we, particularly developers and organizations who are needing to make changes or implement new software, new capabilities to customers. It is the mindset that people should be looking for looking towards. I will argue that I think it's way early still. I mean, remember the very early days of the cloud, like I'm automating virtual virtual as data centers and everything about the cloud. I'm doing private clouds. Common denominator was still really, really low. So the use cases were rapid prototyping, getting your first applications out there and trying new things because waiting for infrastructure took too long. I think we're starting to see those same type of frameworks where Serverless and to to Sheryl's point, I really think developers are going to need to learn how to trust and depend on serverless capabilities and function as a service so that they know that it's going to persist, that it's going to expand, that it's a model that they can continue to build off of because as a consumer, for instance, using something like this, then that that's just like, in my view, using functions and services. Cervalis, where you say, all right, you're going to do this and this and this. I'm going to connect it together in my application. And as long as none of those things change and I have a function for everything I need to do, I'm set. But my my concern in the near term is we still have a lot of gaps which will absolutely get filled over time. So I just think we should be mindful that while container's are hedging a bit, they're also opening up opportunity for serverless demand and capabilities to increase quite a bit. I don't really feel like you're putting a stake in the ground there, Josh Caslen, I'm going to point to you is if you can help us put some definition around this of either the projects you're working on or customers that you're working with and what your experiences. Yeah, I think an interesting thing that's come up across the board, as everyone's been talking, is kind of, you know, a lot of people aren't using even containers today. They're not using serverless today. They're not using containers. Today, they're on Prem. Even if we don't like infrastructure, which is a pretty common sentiment, I think everyone still has to use it in some form. And a lot of businesses are still running data centers. They're still dealing with a lot of unprime overhead that I shouldn't say overhead, but like infrastructure. And and so you have to have those skills and those skills are going to exist for a long time. A lot of those things, like Josh was saying, there's just these gaps. There's these really legacy applications that maybe have some spaghetti code that somebody wrote a long time ago and nobody knows how to run it. And those things are going to take a very long time to modernize. I really like the term application modernization and both of the technologies we're talking about today are about modernizing our applications. So that being said, granted, a lot of things are still going to be on Prem for a good long time. When we think about containers and Serverless, I was working with someone on an e-book recently and they were like, you know, all of these things, they're just containers really underneath. Right. And that came up in our presentations earlier is you can run your applications as containers and you can run them in serverless or you can use container orchestration like Cooper Nettie's. So isn't it all really containers underneath? And one thing that made me think of is that I think a lot of people aren't coming to containers as I need containers right now. They're coming to containers as I needed Carbonetti or I need to run my application. And so that is the driving factor that we have to get to to determine which of these solutions is the right one for your use case. So we've been talking about how if you don't like infrastructure and you're an application developer and what you really care about is getting that application out there, especially in cases where it's an application that can run, do its thing and then go away and not be taking up resources and your valuable infrastructure. Serverless is obviously going to be a great fit. But if you're in more of a lift and shift type situation, like we were talking about earlier, sometimes you'll have to lift and shift into the cloud, into virtual machines to get started. Sometimes as people start to think about modernizing and using the cloud more natively, using all of its great benefits or natively, then they'll start to think about moving those applications into containers. So a lot of those applications will be better served by containers, especially right now because we were talking about gaps. There are a lot of use cases that Cervalis is really amazing at. And then there are some where it's not as good, especially things like more stateful applications. Those are complicated no matter which one you're talking about. But containers have have had a little bit more time to kind of solve those problems. So I tend to think about about things kind of in that way. I hope that helps. Absolutely. Are you saying that containers might be just a bit more mature and more flexible than Cervalis? Am I hearing that right? I think that's my perception. That's certainly what my path has led me to. I started with containers and Serverless has been kind of a new thing that's come on my radar in the last couple of years. And I think that's pretty common. All right. I think I could hear forces rolling in his head. No, not at all. I agree with that. But I think to the point about maturity and flexibility to to a large extent, I mean, you know, I mean, how old is communities like six years old, something like that. And which is it's actually about exactly the same age as lambeck, give or take. Right. When might even be slightly older in terms of when it was released. So there's what I think has happened is the maturity of the community around Carbonetti is way ahead of where the maturity of the community around services. And so that's leading to situations where, yeah, the technology does a lot of things on the server side, but we've got to have the best practices around it as a community so that we're not trying to take all the assumptions that we're bringing from from years of of that past. Right. That I was talking about and try to bring those to surplus and make it do things that it doesn't do. It's a reimagining and that's hard and takes time. And that's on all of us to help make that more legible to people. You're absolutely right for it. I want to point out that you also have to look at to Kathleen's point the application portfolio that every industry or any every enterprise and every company out there is having to manage. And I think what the rationalization on that maturity over the last six or seven years has been, the amount or percentage of impact to modernizing that application portfolio has been disproportionately weighted towards containers than it has Cervalis. And to the point I was laying out earlier, that prototyping in that Adrian Cockcroft at Atrius Reinvent was pointing out about modern application infrastructures. And he highlights that, you know, they did this hackathon for nonprofits and they're given like 12 hours to 16 hours to produce something. Well, yeah, if I need to produce something in 12 to 16 hours, I'm absolutely going to go serverless all out and figure out how to make it work. When I have to make that optimized for scale and growth, I have to reevaluate to make sure that those functions are going to work properly, that this application can meet all the needs in the framework that's there. And do I need to connect to other systems? Do I need to do other things that Serverless may not be able to do? And I think that rationalization of how your entire application portfolio is what's driving that maturity like difference. Yeah, just go ahead. Sorry. No, I was going to say there is there's this sense that we want to give developers the right to deploy code and not worry about infrastructure. And I think that's something, you know, as a developer myself, like I've wanted for as long as I can remember. Also, I think what the disconnect is, is like I don't think no ops is really a thing. There's no like a bypass from the developer straight to production. Not yet anyway. Maybe we'll get there and all developers around the world will rejoice someday. But once you do get to scale, once you get out of kind of the the zero to one or one to 10, if you talk about the product lifecycle, once your product is up and running and it's serving a full load, you have an operations team like there's someone who cares about operations in the middle. So how do we make I think the Serverless the idea of Cervalis is awesome. I do think that I think pulling us in the direction of allowing developers or allowing people to do as minimal things as possible to get what they want to run in production is great. I think the means of how we get there, if you were to make a decision at this point in time, I think containers give you the most flexibility in how to do that. And I think if you do go Cervalis, you have to there's a lot of questions that you need to ask yourself of how many services is it services all the way down, like what are my what are my contracts? What are my escalus, what is my support system if communication between these services go down? So I would say, you know, the code that you hold near and dear and very, very, very close to your business, that that that is massive scale and does matter like it matters what CPU it's running on. Is it on the best network? Does it have the right storage attached? These things are great for containers. And then I think the hooks, the things that put the glue together for the rest of your system, I think those are probably more ideals for Serverless. And then I think we need to get better as a community of. There's a lot of open source projects out there and I know we have a product ourselves. It's called Ocean to make people's lives easier and more like the Cervalis experience. And I think we need to get there. But like if I have to put a stake in the ground today, like I need to put my mission critical, highly scalable at in production, I'm going to choose containers to do that. Let me touch into something that you mentioned and also Kasan mentioned a little bit earlier, which is the problem of storage and stateful applications, because I I think this is actually the most interesting part of all of this. If you have no state, things are much easier. But if I am a medium sized enterprise, running things on time with some databases that are happily ticking along, like, what would you say to me if you were saying, come on to containers or come on to Cervalis? Wow, force, you want to take the first four days as a consultant where I was getting asked this question a lot and what quickly emerges is that the data is often the last thing to move if it ever does, out of the data center. Right. And so you start looking at that application problem and saying, what can I break off some analytics or some reporting or something where I lead my source of truth, where it is because I just can't unpack it, that gravity is flowing. You know, all sources are flowing into that giant pile of mud and the data center. It's really hard to untangle it. And where we've seen people start to have success there is by by taking that incremental approach where they weigh one by one break off workloads and they wrap these shims around the applications that they have. It's not a simple or easy problem. And there's there's applications that will never move out of the data center. That's fine. They don't have to. Right. Not everything belongs in the cloud. It never will. But it's important for us as a application modernization team, a term that I also love Kazulin to sit there and figure out what does make sense and where is their business value, where we can actually reproduce what the system is doing and make it work effectively in the cloud. And I would say either surplus or containers, I'd ask, are you happy with how fast you are delivering to production? And not just that the application itself is running fine and is going along and you have great support metrics and health and stuff. But like, what's the change rate on that application? Are you able to get that production as fast as you want to? How long is your code in a GitHub repository or in development before it gets out being used by your customers? I think both containers and Cervalis have have have ways to make that better for you. So I definitely get all of that. But I really want to dove in on that storage and data piece because that is the hardest piece for either containers or service to move. So what would you say to me if I was trying to make that move? I would say absolutely start with containers, because containers you can start with on Prem today, you can set up any you can set up the system you want. You can be close to your data. And then you can then you can think about a migration story to the cloud if it makes sense to you tomorrow. McCaslin, would you concur with that? Would that be? It sounds like that's similar to your experience in how you came through this industry. A little bit, actually, one story that I like to tell on this, when people are are thinking about, well, I say that often people don't think about this early enough and I come in and I go, So what do you think you're going to do with your data now that you're considering modernizing these applications and they start going, huh? And there's this story that I tell of spinning up my own personal WordPress website. So if anyone has working with WordPress before, it has a database on the back end where it stores a lot of its data. And I my website has a lot of images on it, so. When I first wanted to do this, I thought, oh, I'll open it up in containers, this will be super easy and awesome. So like five minutes I had my WordPress container running. That was great. But one thing I knew about containers was, hey, I should be able to delete that container and bring it back up and still have all of my stuff here if I set up my persistent storage. Right. So I tried that. And when I did, I lost all of my images, all of my blog posts that I had put in there. The text was still there, but the images weren't. And I was like, what just happened? What didn't I set up? Right. And it turned out that WordPress was expecting to be kind of on its own machine and it would just create a directory where it would put a lot of its resources. And I hadn't put that into its own separate storage outside of the container. And so when the container went away, it went away. So this is a whole new way for people to think about their applications and how they relate to storage. So it's a really tough thing for people to wrap their minds around. I like to use the example of a database, too. If you try to spin up a database in a container, where is all that data going to be? You should be able to delete that container and your database application will go away, but all of the data should still be there. So if you were to spin up another container and hook it up to that data, it should also be fine. So this is really difficult for a lot of people to think about. And this is this is where the server side of me wants to say, well, why are these databases just managed services in the first place? Right. Why should I have to figure out how to run this on top of containers? Let me handle this to somebody who knows. So I regularly quip that in all my years of building applications and automation and whatnot, the only completely stateless app I ever wrote was Hello World. And because everything else requires the access of data of some type of reference of data, I writing to data like there is a there is a process. But to your point, I think you're absolutely right. And I do think that we're going to continue to see modernization of how we access data, how we store and connect with data. And I think that is going to Sheryl's point. I think that's going to be a linchpin for explosive serverless maturity and growth and adoption. You know, this has been a really great and a really fantastic conversation. We could probably talk for another 20, 30 minutes about, but we do need to wrap up. And I do want to go round the horn with last thoughts from each person and I'll pick on you first. Cheryl, last thoughts. Any key takeaways that you want somebody in the audience that generally isn't caught up in the drama of Cervalis versus Container's, but wants to actually have a key, take away the appreciation of how they should view these technologies? I think my key takeaway from this is think about data from the beginning, think about what experience you want to have, because actually it's pretty easy to move on to either of these technologies today. But the data stuff is wildly different and that's what you need to make a decision on. Fantastic, Josh, give us a key takeaway. Yeah, I agree with that one as well, I think the way we operationalize in the future is important. I going to get away with it or not. Cheryl, you got to come up with your own. Josh, come on now. I'm on it, man. So while while it's important to consider this conversation today, whatever you're putting into a container, tomorrow is likely to be a serverless function capability in the future. So this is an ongoing thing. You know, whatever decisions you make today are for today and for the near future. But you need to, as we've talked about, continually be looking at what the emerging capabilities are because this is going to continue to shift to that mindset. Absolutely fantastic, Kathleen, give us a good takeaway. So whatever business you're in, whatever you're running today, there are good reasons for that probably. There are a lot of good things about what you're running today. And so as you're thinking about all of these new technologies that are coming into the picture, any engineer has to deal with all of the rapid change in the tech industry. So you're going to have to think about what's right with my application today. What doesn't need to change? It ain't broke. Don't fix it. What can I keep the same? But what could I do better with these new technologies I'm hearing about? And you let that kind of guide you towards these solutions as you modernize your applications. That's really great, fantastic, Kevin. I mean, you gave a great presentation, if I'm going to take away one key takeaway, what is it? Move fast, take the technology, it's going to help you move fast, but also the technology that's going to give you all of the things you need to run your business. I want to always associate the container itself with infrastructure. There's plenty of ways to deploy and run and scale containers without necessarily worrying the infrastructure about it. There's plenty of open source tools out there. There's there's ocean from Spot by NetApp that does this for you that allows your developers to scale as much as they want to deploy their applications to scale containers and containers. Still give you that ability to fine tune everything about your hyperscale application in the cloud. So I think you really need to understand what you're doing and what your operation teams can support. And I believe today the breadth of that is with containers. Fantastic. Kevin, thank you so much. And wrapping up here for take us home. Give us this give give us the suckerpunch here. Defy entropy by anything not worth building. Learn to love Blockin, you live with ownerless build more. We got quite a few for for that one takeaway. That's fantastic. I got to tell you, this was a really great in a fantastic debate. And I really want to, you know, first thank Kevin for us for really giving us some thought provoking ways to view containers versus services and the value that goes with them. Cheryl, Josh and Kathleen, thank you so much also for being a fantastic panel, asking great questions and also making us think a little bit about these technologies and applications as we deploy them. And with that, I'll just remind everybody, please go to Antep, Dotcom and THP Dotcom. It's time for more information. Thank you, everyone, and thank you for joining us and spending your day with us.