 Hello and welcome to this startup showcase. It's great to be here and talk about some of the innovations we are doing at AWS, how we work with our partner community, especially our open source partners. My name is Deepak Singh. I run our compute services organization, which is a very vague way of saying that I run a number of things that are connected together through compute. Very specifically, I run a container services organization. So for those of you who are into containers, ECS, EKS, Foggate, ECR, AppRunner, those are all teams that are within my org. I also run the Amazon Linux and bottom rocket team. So anything AWS does with Linux, both externally and internally, as well as our high performance computing team. And perhaps very relevant to this discussion, I run the Amazon open source program office. So I've been at AWS for over 13 years, almost 14, involved with compute in various ways, including EC2. What that has done has given me a vantage point to seeing how our customers use the services that we build for them, how they leverage various partner solutions, and along the way, how AWS itself has gotten involved with open source. And I'll try and talk to you about some of those factors and how they impact how you consume our services. So why don't we get started? So for many of you, one of the things, there's two ways to look at AWS and open source and Amazon in general. One is the number of contributors you may have and the number of repositories you contribute to. Those are just a couple of measures. There are people that I work with on a regular basis who will remind you that those are not perfect measures. Sometimes you could just contribute to one thing and have outsized impact because of the nature of that thing. But AWS being what it is, increasingly, we look at different ways in how which we can help contribute and enhance open source because we consume a lot of it as well. I'll talk about it very specifically from the space that I work in, the container space in particular, where we've worked a lot with people in the Kubernetes community. We've worked a lot with people in the broader CNCF community, as well as small projects that our customers might have got started off with. For example, one I like talking about is Argo CD from Intuit. We were very actively involved with helping them figure out what to do with it. And it was great to see how Intuit and V-Works et cetera came together to think about GitOps at the Kubernetes level. And while those are their projects, we've always been involved with them. So we try and figure out what's important to our customers, how we can help, and then take action because of that. Let's talk about a little bit more. Here are some examples of the kinds of open source projects that Amazon and AWS contribute to. They range from the open JDK. I think we even now have our own implementation of Java, the Coretto open source project. We contribute to projects like Rust, where we are very active in the Rust foundation from a leadership role as well. The robot operating system, just to pick some. We collaborate with Facebook and are actively involved with the PyTorch project. And there's many others. You can see all the logos in here where we participate either because they're important to us as AWS and the services that we run or they're important to our customers and the services that they consume or the open source projects they care about. And how we get to those, how do we get and make those decisions is often depends on the importance of that particular project at that point in time, how much impact they're having to AWS customers, or sometimes where we feel that us contributing to that project is super critical because it helps us build more robust services. I'll talk about it on a completely somewhat different basis. You may have heard of us talk about our new next generation of Amazon Linux, Amazon Linux 2022, which is based on Fedora as its upstream. One of the reasons we made this decision was it allows us to go and participate in the Fedora project and make sure that the upstream project is robust, stays robust, and that what that ends up being is that Amazon Linux 2022 will be a robust operating system with the kind of capabilities that our customers are asking for. That's just one example of how we think about it. So for example, the Python Software Foundation is something that we work very closely because so many of our customers use Python. So we help run something like PyPy, which is many, if you're a Python developer, I happen to be a Ruby one, but lots of our customers use Python and helping the Python project be robust by making sure PyPy is available to everybody is something that we help provide credits for, help support in other ways. So it's not just code. It can mean many different ways of contributing as well. But in the end, code and operations is where we hang our hat. Good examples of this is projects that we will create an open source because it makes sense to make sure that we open source some of the core primitives or foundations that are part of our own services. A great example of that, whether this be things that we open source or things that we contribute to. And I'll talk about both. And I'll talk about things near and dear to my heart. There's many examples. I've picked the two that I like talking about. The first of these is Firecracker. Many of you have heard about it. Firecracker, for those of you who don't know, is a very lightweight virtual machine manager, which allows you to run these micro VMs. And why was this important? Many years ago, when we started Lambda, and quite honestly, Fargate, and Fargate still runs quite a bit in that mode, we used to have to run on VMs like everything else. And finding the right VM for the size of task that somebody asked for, the size of function that somebody asked for, is, requires us to provision capacity ahead of time. And it also wastes a lot of capacity because Lambda function is small, even if you find the smallest VM possible, those can be a little, that can be challenging. And you use, you know, there's a lot of resources that are being wasted. VMs start at a particular speed because they have to do a whole bunch of things before the operating system spins up and the virtual machine spins up. And we asked ourselves, can we do better? Can we come up, come up with something that allows us to create right sized, very lightweight, very fast booting virtual machines, micro virtual machines that we ended up calling them. That's what led to Firecracker. And we open source the project. And today, Firecracker is used not just by AWS Lambda or Fargate, but by a number of other folks, there's companies like Fly IO that are using it. We know people using Firecracker to run Kubernetes on prem, on bare metal as an example. So we've seen a lot of other folks embrace it and use it as the foundation for building their own serverless services, their own container services. And we think there's a lot of value and learnings that we can bring to the table because we get the experience of operating at scale. But other people can bring to the table because they may have specific requirements that we may not find as important from a AWS perspective. So that's Firecracker. An example of a project where we contribute because we feel it's fundamentally important to us as ContainerD. We've been involved with ContainerD from the beginning. Today we are a whole team that does nothing else but contribute to ContainerD because ContainerD underlies Fargate, it underlies our Kubernetes offerings. And it's increasingly being used by customers directly as a replacement where they're running ContainerD instead of running full-on Docker or similar Container Engine. What it has allowed us to do is focus on what's important so that we can operate ContainerD at scale, keep it robust and secure, add capabilities to it that AWS customers need manifested often through Fargate or Kubernetes. But in the end it's a win-win for everybody. It makes ContainerD better. If you want to use ContainerD for yourself on AWS, that's a great way to, you know, you still benefit from all the work that we're doing. The decision we took was, since it's so important to us and our customers, we wanted a team that lived and breathed ContainerD and made sure it was super robust. And there's many, many examples like that, you know, that we end up participating in either by taking a project that exists or open sourcing our own. Here's an example of some of the open source projects that we have done from an AWS on Amazon perspective. And there's quite a few. When I was looking at this list, I was quite surprised, not quite surprised, I've seen the reports before, but every time I do, I have to recount and say that's a lot more than one would have thought, even though I've been looking at it for such a long time. Examples of this in my world alone are things like, you know, what work we're going to do with Amazon Linux. A bottle rocket, which is a container host operating system that's been open sourced from day one. Firecracker is something we talked about. We have a project called AWS Parallel Cluster, which allows you to spin up high-performance computing clusters on AWS using the kind of schedulers you may use to use, like Slurm, and that's an open source project. We have plenty of open source projects in the web development space, in the security space, and more recently, things like the Open3D engine, which is something that we are very excited about and that we open sourced a few months ago. And so there's a number of these projects that cover everything from tooling to developer application frameworks, all the way to database and analytics and machine learning. And you'll notice that in a few areas, containers as an example, machine learning as an example, our default is to go with the open source option. It's where we can open source and it makes sense for us to do so, where we feel the broader community might benefit from it. That's our default stance. The CNCF, the Cloud Native Computing Foundation, is something that we've been involved with quite a bit. We contribute to Kubernetes, we contribute to Envoy. I talked about Continuity a bit. We've also contributed projects like CDK-8, which marries the AWS Cloud Development Kit with Kubernetes. It's now a sandbox project in Kubernetes. And those are some of the areas. CNCF is such a wide-surface area, we don't contribute to everything, but we definitely participate actively in CNCF with projects like at CD that are critical for us. We are very active in just how the project evolves, but also try and see which are the projects that are important to our customers who are running Kubernetes maybe by themselves or some other project on AWS. Envoy is a good example. Kubernetes itself is a good example because in the end, we want to make sure that people running Kubernetes on AWS, even if they're not using our services, are successful, and we can help them or we can work on the projects that are important to them. That's kind of how we think about the world, and it's worked pretty well for us. We've done a bunch of work on the Kubernetes side to make sure that we can integrate and solve our customer problems. We've, you know, we've, from everything from Totser for PyTorch models to work that we have done with Graviton, our ARM processor, to a virtual GPU plugin that allows you to share and radio GPU resources to the elastic fabric adapter, which is a network device for high-performance computing that you can use with Kubernetes on AWS, along with things that directly impact Kubernetes customers, like the CDK8 project I talked about, work that we do with the container networking interface to the Amazon controller for Kubernetes, which is an open source project. They allow you to use other AWS services directly from Kubernetes clusters. Again, you notice it says Kubernetes, not EKS, which is a managed Kubernetes service, because if you want you to be successful with Kubernetes and AWS, whether you're using our managed service or running your own or some third-party service. Similarly, we've worked with Prometheus. We now have a managed Prometheus service, and at Reinvent last year, we announced the general availability of this thing called Carpenter, which is a provisioning and auto-scaling engine for Kubernetes, which is also an open source project. But here's the beauty of Carpenter. You don't have to be using EKS to use it. Anyone running Kubernetes on AWS can leverage it. We focus on the AWS provider, but we've built it in such a way that if you wanted to take Carpenter and implement it on prem or another cloud provider, that'd be completely okay. That's how it's designed, and what we anticipated people may want to do. I talked a little bit about Bottle Rocket. It's our Linux-based open-source operating system, and the thing that we have done with Bottle Rocket is make sure that we focus on security and the needs of customers who want to run orchestrated containers. We are very focused on that problem. For example, Bottle Rocket only has essential software needed to run containers. SC Linux, I just noticed it says SC Linus, but I'm sure that's, you know, Linus Torvalds would be pretty happy at seeing that. SC Linux is enabled by default. We use things like DM Verity, and it has a read-only root file system. No shell. You can't SSH in. You can install it if you wanted to. We've allowed it to create different build types, variants as we call them. You can create a variant for a non-AWS resource as well. You can create your own, if you have your own homegrown container orchestrator, you can create a variant for that. It's designed to be used in many different contexts, and all of that is open-sourced. And then we use the update framework to publish and secure repository and kind of how this transactional system way of updating the software. And it's something that we didn't invent, but we have embraced wholeheartedly. So Bottle Rocket is completely open-sourced. We have partners like Aqua, who develop security tools for containers. And for them, something like Bottle Rocket is a natural partnership because people are running a container host operating system. You can use Aqua's tooling to make sure that they're a secure container environment. And we see many more examples like that. You may think serverless is all about AWS proprietary technology because Lambda is a proprietary service. But, you know, if you look peek under the covers, that's not necessarily true. Lambda runs on top of Firecracker, as we've talked about, Firecrackers and open-source projects. So the foundation of Lambda in many ways is open-source. What it also allows people to do is, because Lambda runs at such extreme scale, one of the things that Firecracker is really good for is running at scale. So if you want to build your own Firecracker-based at-scale service, you can have most of the confidence that as long as your workload fits the design parameters of Firecracker, the battle-hardening, the robustness is being proved out day-to-day by services at scale like Lambda and Fargate. For those of you who don't know what serverless is, in the end, our goal with serverless is to make sure that you don't think about all the infrastructure that your applications run on. You focus on business logic as much as you can. That's how we think about it. And serverless has become its own quote-unquote environment. The number of partners and open-source frameworks and tools that are spun up around serverless, in which case, mostly Lambda API gateway services like that is pretty high. So a number of open-source projects like Zappa, serverless framework, there's so many that have come up that make it easier for our customers to consume AWS services like Lambda and API gateway. We've also done some of our own tooling and frameworks, a serverless application model, AWS Chalice, if you're a Python developer. We have these open-source runtimes for Lambda, Rust, Dart, other options. We have a number of tools that we open-source. So in general, you'll find the tooling that we do, runtimes will tend to always be open-source. We will often take some of the guts of the things that we use to build our systems like Firecracker and open-source them, while the control planes, etc., of AWS services may end up staying proprietary, which is the case in Lambda. Increasingly, our customers build their applications and leverage the broader AWS partner network. The AWS partner network is a network of partnerships that we've built, of trusted partners. You can, when you go to the APN website and find a partner there, you know that that partner meets a certain set of criteria that AWS has developed. And you can rely on those partners for your own business. So whether you're a little tiny business that wants some function fulfilled that you don't have the resources for, or large enterprise that wants all these applications that you've been using on-prem for a long time and want to keep leveraging them in the cloud, you can go to APN, find that partner, and then bring their solutions on as part of your cloud infrastructure. And could even be a systems integrator, for example, to help you solve this specific development problem that you may have a need for. Increasingly, one of the things we like to do is work with, you know, partner community that is full of open source providers. So a great one, I would, there's so many, and you have, we have a panel discussion with many other partners as well that who make it easier for you to build applications on AWS, all open source, and built on open source. But I'd like to call out a couple of them. The first one of them is Tidelift. Tidelift, for those of you who don't know, is a company that provides space tools to curate, track, manage open source catalogs. You know, they have a whole network of maintainers and providers. They help, if you're an independent open source developer or a small team, you should probably get to know Tidelift. They provide you benefits and capabilities as a developer and maintainer that are pretty unique and really help. And I've seen a number of our open source community embrace Tidelift, quite honestly, even before they were part of the APN. But what, as part of the partner network, they get to participate in things like ISV Accelerate, you know, sort of, they get to, they are officially an advanced partner because they have migrated the SaaS offering on to AWS. But in the end, if you're part of the open source supply chain, you're a maintainer, you're a developer, I would recommend working with Tidelift because their goal is making all of you who are developing open source solutions, especially on AWS, more successful. And that's why I enjoy this partnership with them. And I'm looking to do a lot more because I think as a company, we want to make sure that open source developers don't feel like they are not supported because all you have to do is read various forums. It's challenging often to be a maintainer, especially of a small project. So I think with helping with licensing, license management, security, identification, remediation, helping these maintainers is a big part of what Tidelift does and it's great to see them as part of a partner network. Another partner that I like to call out is Cystic. I actually got introduced to them many years ago when they first launched. And one of the things that happened was they were super interested in some of our serverless stuff. And we've been trying to figure out how we can work together because a lot of our customers are interested in the capabilities that Cystic provides. And over the last few years, we found a number of areas where we can collaborate. So Cystic, I know them primarily as a security company. So people use Cystic to secure the bills, do threat response, threat detection, completely continuously validate their posture, get this continuous analytics signal on how they're doing and monitor performance at the end of it. It's a SaaS platform. They have a very nice open-source security stack, the one I'm most familiar with and I think most of you are familiar with is Falco. Cystic's CNCF project has been super popular. Cystic OSS has what, three, 37, 40 million downloads by now. So that's pretty, pretty cool. And they have been a great partner because we've had to make sure that their solution works at Fargate, which is not a natural place for their software to run, but there's enough demand and interest from our customers that both companies leaned in to make sure they can be successful. So last year, Cystic got a security competency. We have a number of specific competencies that we, for our partners, they have an integration security hub. It's great, partners that lean in the way Cystic has on to making our customers successful and working with us are the best partners that we have. And there's a number of open-source companies out there built on open-source where their entire portfolio is built on open-source software or the active participants like we are, that we love working with on a day-to-day basis. So I think the thing I would like to, as we wind this out in this presentation is AWS is constantly looking for partnerships because our partners enable our customers. They could be with companies like Redis, with Mongo, with Confluent, with Databricks. Customers, your default reaction might be, hey, these are companies that maybe compete with AWS. But no, I mean, I think we are partners as well, like from somebody at the lower end of the spectrum where people run on top of the services that I own on Linux, on containers, on EC2. For us, these partners are just as important customers as any AWS service or any third party or any external customer. And so it's not a zero sum game. We look forward to working with all these companies and open-source projects. From an AWS perspective, a big part of what where my open-source program office spends its time is making it easy for our developers to contribute to open-source, making it easy for AWS teams to decide when to open-source their software or participate in open-source projects. Over the last few years, we made significant changes in how we reduce the friction. And I think you can see it in the results that I showed you earlier in this talk. And the last one is one of the most important things that I say, and I'll just keep saying that, that we do as AWS is carry the pager. There's a lot of open-source projects out there, operationalizing them, running them at scale is not easy. It's not for whatever reason. It may not have anything to do with the software itself. But our core competency is taking that and being really good at operating it and becoming experts at operating it. And then ideally taking that expertise and experience at operating that project, that software, and contributing back upstream, because that makes it better for everybody. And I think you'll see us do a lot more of that going forward. We've been doing that for the last few years, you know, in the container space, we do it every day. And I'm excited about the possibilities. With that, thank you very much. And I hope you enjoy the rest of the showcase. Okay, welcome back. We had Deepak Singh here. We just had the keynote, closing keynote, Vice President of ADOS Compute Services, Deepak. Great to see you, great keynote, great wisdom and insight from that session. Very notable highlights and cutting-edge trends and product information. Thanks for sharing. No, anytime. It's always good to be here. It's too bad that we're still doing this virtually, but always good to talk to you, John. We'll get hopefully through this way pretty quickly. I want to jump right in because we don't have a lot of time. I want to ask you some quick questions. You've brought up a good things. Open-source innovation, okay? Going next level. You've seen the rise of super clouds and super apps developing at open-source. You're seeing big companies contributing. You know, you mentioned Argo and Tuit. You're seeing that dynamic where companies are forming around. This is a rising tide. This is actually real. It's not the old school of, okay, here's a project and then someone manages support and commercialization of it. It's actually platform and cloud scale. This is next gen. Yeah. And actually, I think it started a few years ago. We can talk about a company that you're very familiar with as part of this event, which is Armory. Many years ago, Netflix spun off this project called Spinnaker. Spinnaker is a CICD system that was developed at Netflix for their own purposes, but they chose to open-source it. And since then, it's become very popular with customers who want to use it even on-prem. And you have a company that spun up on it. I think what's making this world very unique is you have very large companies like Facebook that will build things for themselves, like PyTorch or Netflix with Spinnaker and open-source them. And you can have a lot of discussion about why they chose to do so, etc. But increasingly, that's becoming the default when Amazon or Netflix or Facebook or Meta, I guess you call them these days, build something for themselves for their own needs. The first question we ask ourselves is, should it be open-source? And increasingly, we are all saying yes. And here's what happens because of that. It gives an opportunity, depending on how you open-source it, for innovation through commercial deployments. So you get SaaS companies that are going to take that product and make it relevant and useful to a very broad number of customers. You build partnerships with cloud providers like AWS because our customers love this open-source project and they need help. And they may choose an AWS managed service or they may end up working with this partner on a day-to-day basis. And we want to work with that partner because they're making our customers successful, which is one reason all of us are here. You're having this set of innovation from large companies, whether they are just consumer companies like Meta, infrastructure companies like us, or just random innovation that's happening around open-source projects, which ends up in companies being spun up and that foster that innovation and that flywheel that's happening right now. And I think you said that, like this is unique. I mean, you never saw this happen before from so many different directions. It really is a nice progression on the business model side as well. You mentioned Argo, which is a great organic thing that was Intuit developed. We just interviewed CodeFresh. They just presented here in the showcase as well. You're seeing the formation around these projects developed now in the community at a different scale. I mean, look at CodeFresh. I mean, Intuit did it. Argo, they're not just supporting it. They're building a platform. So you're seeing the dynamics of tools and now emerging to platforms. You mentioned Lambda, which is proprietary for AWS in your talk, powered by open source. So again, open source combined with cloud scale allows for new potential super applications or super clouds that are developing. This is a new phenomenon. This isn't just lift and shift and host on the cloud. This is actually a construction, production, developer workflow. Yeah. And you're seeing consumers, large companies, enterprises, startups, it used to be that startups would be comfortable adopting some of these solutions. But now you see companies of all sizes doing so. And I said, it's not just software. It's software, the services increasingly becoming the way these are delivered to customers. And I actually think the innovation is just getting going, which is why we have this. We have so many partners here who are all inventing and innovating on top of open source, whether it's developed by them or a broader community. I like the reference to container D. You guys did that, drove that. You've seen a lot of changes. And again, with cloud scale and open source, you're seeing the dynamics change, whether you're enabling that. And then you see kind of like real big change. So let's take Snowflake, a big customer of AWS. They started as a startup too, but they weren't a data warehouse. They were bringing data warehouse like functionality and then changing everything differently and making it consumable for the cloud. And hence they're huge. So that's a disruption into an incumbent leader or sector. Then you got new capabilities emerging. What's your thoughts, Deepak? Can you share your vision on how you have the disruption to existing leaders, old guard, if you will, as you guys call them, and then new capabilities as these new platforms emerge out of net new functionality. How do you see that emerging? Yeah. So I speak from sort of the world I've lived in over the last few years, which is containers and serverless, right? There's a lot of, if you go to any enterprise and ask them, do you want to modernize your infrastructure? Do you want to take advantage of automated software delivery, continuous delivery, infrastructure as code, modern observability, all of them will say yes. But they also are still a large enterprise, which has these enterprise level requirements. I'm using the word enterprise a lot, and I usually, it's a trigger word for me, because so many customers have similar requirements, but I'm using it here as large company with a lot of existing software and existing practices. I think the innovation that's coming, and I see a lot of companies doing that is saying, hey, we understand the problems you want to solve. We understand the world where you live in, which could be regulated. You want to use all these new modalities. How do we allow you to use all of them, keep the advantages of switching to a Lambda or switching to a service running on Fargate, but give you the same capabilities? And I think I'll bring up Cystic here, because we work so closely with them on Falco, as an example. I just talked about them in my keynote. They could have just said, oh, no, we'll just support EC2 and be done with it. They said, no, we're going to make sure that serverless containers in particular are something that we're going to be really good at, because our customers want to use them but it requires us to think differently. And then they end up developing new things like Falco that are born in this new world, but understand the requirements of the whole world. If you get what I'm saying, and I think that's a great example. Well, I mean, first of all, they're smart. So that was pretty obvious for most people that know C, that you can connect the dots on serverless, which is a great point. But not everyone can see that. Again, this is what's new and Cystic, which is found in his backyard, as I found out in my interview, a great, great founder. They were doing new things. So it was very easy to connect the dots there. Again, that's the trend. Well, I got to ask if they're doing that for serverless, you mentioned Graviton in your speech. And what came out of reinvent this past year was all the innovation going on at the compute level with Graviton at many levels in the Silicon. How should companies and open source developers think about how to innovate with Graviton? Yeah, I mean, you've seen examples from people blogging and tweeting about how faster applications run on Graviton and the price performance benefits that they get, whether it's in observability or other places. So I think the way to think about Graviton is Graviton is something that AWS is going to embrace across a compute portfolio. Obviously, you can go find EC2 instances, the Graviton two instances and run on them. And that'll be great. But we know that most of our customers, many of our customers are building new applications on serverless containers and serverless. And even if containers increasingly with things like Fargate, where they don't want to operate the underlying infrastructure. So we made it very big part of what we're doing is to make sure that Graviton is available to you on every compute modality. You can run it on EC2 forever, you've been running, been able to use ECS and EKS and run on Graviton almost since launch. But do you want to take it a step further? Elastic beanstalk customers, elastic beanstalk has been around for a decade, but you can now use it with Graviton. People running ECS on Fargate can now use Graviton. Lambda customers can pick Graviton as well. So we're taking these price performance benefits that you get from Graviton and basically putting it across the entire compute portfolio. What it means is every high level service that gets built on this now has the option of picking Graviton as underlying compute infrastructure. And you get the price performance benefits, you get the overall, I'll say societal benefits of the lower power consumption of on processors. So I'm personally excited like crazy. And you know, this is Graviton 2, Graviton 3 is coming. And now it's incredible. It's an opportunity like serverless was, it's pretty obvious. I think hopefully everyone will jump on that. Final question is the time sticking here. I want to get your thoughts quickly. If you look at what's happened with containers over the past, say eight years, since the original founding of the first Docker instance, if you will, how that's evolved. And then the introduction of Kubernetes and the cloud native wave we're seeing now. How would you describe the relationship between the success Docker seeing now with Kubernetes in the cloud native construct? What's different? And why is this combination so successful? Yeah, I often say that containers would have, let me rephrase that. What I say is that people would have adopted sort of the modern way of running applications whether containers came around or not. But the fact that containers came around made that migration and that journey is so much more efficient for people. So right from, I still remember the first talk that Solomon gave Perihan on stalker and starting to use it and customers starting to get interested all the way to the more sort of advanced orchestration that we have now for containers across the board. And there's so many examples of the way you can do that. Kubernetes being the most well-known one. Here's the thing that I think has changed. I think what Kubernetes, what Docker, what the whole sort of modern way of building applications has done is it's taken people who would have taken years adopting these practices and by bringing it right to the fingertips and building it into the APIs. And in the case of Kubernetes building an entire sort of software world around it, the number of, I won't say the number of decisions people have to take has gone smaller in many ways. There's so many options, the number of decisions that become higher, but the speed at which they can get to a result and a production version of an application that works for them is way low. I've not seen anything like what I've seen in the last six, seven, eight years of how quickly the most, I would say a company that you would think would never adopt modern technology has been able to go from this is interesting to getting in production really quickly. And I think it's because the tooling makes it so. And the fact that you see the adoption that you see right from the fact that you could do Docker and Docker build Docker, you know, so easily back in the day, all the way to all the advanced orchestration you can do with container orchestrators today. And you throw in serverless into it sort of taking all of that away as well. It's it's it's there's never been a better time to be a developer independent of whatever you're trying to build. And I think containers are a big central part of why that's happened. It's like the recipe, the combination of cloud scale, the timing of Kubernetes and the containerization concepts just explode as a beautiful thing. And it creates more opportunities will challenges which are opportunities that are net new, but it solves the automation piece that we're seeing this again, this only makes things go faster. Yes. And that's the key trend. Deepak, thank you so much for coming on. We're seeing tons of open cloud innovations. Thanks to the success of your team at AWS. And being great participants in the in the community, we're seeing innovations from startups. You guys are helping enabling that. Of course, they want to live on their own and be successful and build their super clouds themselves and super apps. So thank you for spending the time with us. Appreciate it anytime. And thank you. And, you know, this is this is a great event. So I look forward to people running software and building applications using AWS services and all these wonderful partners that we have. Awesome. Great stuff. Great startups. Great next generation leaders emerging when you see startups when they get successful, they become the modern software applications, platforms out there, powering business and changing the world. This is theCUBE. You're watching the AWS startup showcase season two, Episode one, open cloud innovations on John Furrier, your host. See you next time.