 From around the globe, it's theCUBE with digital coverage of DockerCon Live 2020. Brought to you by Docker and its ecosystem partners. Hi, I'm Stu Miniman and this is the Cube's coverage of DockerCon Live 2020. Happy to welcome back to the program. One of our Cube alumni, Deepak Singh, he's the vice president of compute services at Amazon Web Services. Deepak, great to see you. Likewise, hi Stu, nice to meet you again. All right, so for an audience that hasn't seen your previous times on theCUBE, give us a little bit about, you know, your role and your organization inside AWS. Yeah, so I've been part of the AWS compute services world from for the last 12 years in various capacities. Today, I run a number of teams, all our container services, our Linux teams. I also happened to run our high performance computing organization. So it's a nice mix of all the computing that our customers do, especially some of the more new and large scale compute types that our customers are doing. All right, so Deepak, obviously, you know, the digital events, we understand what's happening with the global pandemic. DockerCon was actually always planned to be an online event, but I want to understand, you know, your teams, how things are affecting. We know distributed is something that Amazon's done, but you have to cut up those two pizzas and send them out to the additional groups. Or, you know, what advice are you giving the developers out? Yeah, in many ways, obviously, how we operate has changed. We are at home, maybe I think with our families, DockerCon was always going to be virtual, but many other events like AWS summits are now virtual. So, you know, in some ways, the teams, the people that get most impacted are not necessarily the developers in our team, but people who interact a lot with customers who go to conferences and speak, and they are finding new ways of being effective and being successful, and they're being very creative at it. Our customers are getting very good at working with us virtually, because we can't always go to their site. They can't always come to Seattle or one of our other sites for meetings. So, we've all become very good at and disciplined at how do you conduct really nice virtual meetings. But from a customer commitment side, from how we are operating, the things that we're doing not that much changed. We still run our projects the same way that the teams work together. My team tends to do a lot of happy things like Friday happy hours. They happen to be all virtual. I think last time we played, what word bingo? I forget exactly what game we played. I know I got some points somewhere, but we do our best to maintain sort of our team chemistry, our camaraderie, but the mission doesn't change, which is our customers expect us to keep operating their services, make sure that they're highly available, keep delivering new capabilities, and I think in this environment, in some ways that's even more important than ever as the consumer moves online and so much business is being done virtually. So, it keeps us on our toes, but it's been an adjustment, but I think we all, not just us, I think the whole world is doing the best that they can and are under the circumstances. Yeah, absolutely. It definitely has humanized things quite a bit. From a technology standpoint, distributed systems has really been the challenge of quite a long journey that people are going on. Docker has played a really important role in a lot of these cloud-native technologies. It's been just amazing to watch. One of the things I point to in my career is watching from those very, very early days of Docker to the Cambrian explosion of what we've seen container-based services. You've been part of it for quite a number of years and AWS has many services out there. For people that are getting started, what guidance do you give them? What do they understand about containerization in 2020? Yeah, and containerization in 2020 is quite a bit different from when Docker started in 2013. I remember speaking at DockerCon, I forget, that's 2014, 2015, and it was a very different world. People were just trying to figure out what containers are that they could package code into it. Today, containers are mainstream. It is more customers or at least many customers when they're starting to build new applications, probably starting then, either with containers or with some form of server technology. That's at least that's the default starting point. But increasingly, we're also seeing customers with existing applications starting to think about how do they adopt a container that means to an end? The end is, how can we move faster? How can we deliver more quickly? How can our teams be more productive and how can we do it more or less expensively at lower cost? And containers are a big, are an important and critical piece of that puzzle, both from how customers are operating the infrastructure. So there's a whole ecosystem of schedulers and orchestration and security tools and all the things that an enterprise needs to deliver applications using containers that built up. Over the last few years, we have multiple container services that meet those needs. And I think that's been the biggest change is that there's so much more, which also means that when you're getting started, you're faced with many more options. When Docker started, it was a skewed veil, Docker run, Docker build, Docker push, it was very simple. You could get going really quickly. And today, I'm on the different options. My guidance to customers really is boils down to what are you trying to achieve? If you're an organization that's trying to corral infrastructure and trying to use their existing VM more effectively, for example, you probably do want to invest in becoming experts at schedulers and understanding orchestration technologies like ECS and EKS work. But if you just want to run applications, you probably want to look at something like Fargate or more. I mean, you could go towards Lambda and just run code. I think it boils down to where you're starting your journey. And by the way, understanding Docker run, Docker build and Docker push is still a great idea. It helps you understand our thing for it. All right, so Deepak, you've already brought up a couple of AWS services. Talk about the options out there that you can either run on top of AWS, you have a lot of native services, ECS, EKS, you mentioned Fargate there, and very broad ecosystem space. Could you just, obviously, there are entire breakout sessions to talk about the various AWS services, but give us that one-on-one level as to what to understand for container services side of AWS. Yeah, and these services evolved organically. We launched Amazon Elastic Container Service, or ECS, in preview in November of whenever a re-invent was that year in 2014, which seems ages ago in the world of containers. But in the end, our goal is to give our customers the most choice so that they can solve problems the way they want to solve them. So Amazon ECS is our native container orchestration service. It's designed to work with the rest of the AWS ecosystem. So it uses VPC for networking. It uses IM for identity. It uses ALB for load balancing, as though they're just good examples, some examples of how it works. But it became pretty clear over time that there was a lot of customers who were investing in Kubernetes, very often starting in their own data centers. And as they migrated onto the cloud, they wanted to continue using the same two things. But they also wanted to not have to manage the complexity of Kubernetes control planes, upgrades. And they also wanted some of the same integrations that they were getting with ECS. And so that's where the Amazon Elastic Kubernetes service, or ETS comes in, which is, okay, we will manage your control plane for you. We will manage upgrades and patches for you. You focus on building your applications the Kubernetes way. So it embraces Kubernetes. It has, it works with all the Kubernetes tooling and gives your Kubernetes native experience, but then also ties into the broad AWS ecosystem and allows us to take care of some of the muck that many customers quite frankly don't and shouldn't have to worry about. But then we took it one step further. It actually launched the same time as ETS and that's AWS Fargate. And Fargate was, came from the recognition that we had actually a long time ago, which is one of the beauties of EC2 was that customers never had to stop, didn't have to worry about racking and stacking where a server was running anymore. And the idea was, how can we apply that to the world of containers? And we also learned a little bit from what we had done with Lambda. And we took that and took the server layer and took it out of the way. So from a customer standpoint, earlier launching is a pod or a task or a service. And you're not worrying about which machines I need to get, what types of machines I need to get. And the operational simplicity that comes with it is quite remarkable. And not that surprisingly, our customers want us to keep pushing the boundary of the kind of operational simplicity we can give them. But Fargate is a critical building block and part of that. And we're super excited because today, by far, when a new customer, when a customer comes and runs a container on ETS the first time, they pick Fargate, usually using ECS because EKS and Fargate is much newer. But that is a default starting point for any new container customer on AWS is great. All right. Well, Docker, the company really helped a lot with that democratization, container technologies, all those services that you talked about from AWS. I'm curious now that the partnership with Docker here, how do some of the AWS services fit in with Docker? I'm thinking Docker desktop is probably some place that there are some connection. I think one of the things that Docker has always been really good at as a company, as a project, is understanding the developer and the fact that they start off on a laptop. That's where the original Docker experience went so well and Docker desktop since then. And we see a ton of Docker desktop customers that use AWS. We also learned very early on, because our originally CSCLI supported Docker compose, that ecosystem is also very rich and people like building Docker files and just being able to launch them. So we continue to learn from what Docker is doing with Docker desktop. We continue working with them on making sure that customers in the Docker compose and Docker desktop can run their services and application on AWS. And we'll continue working with Docker, the company, on how we make that a lot easier for our customers. They are our mutual customers and how we can learn from their simplicity that Docker, the simplicity that Docker brings and the sort of ease of use that Docker brings to the developer and the developer experience. We learned from that for our own services and we would love working with them to make sure that the customer that's starting with Docker desktop or the Docker CLI has a great experience as they move towards a fully orchestrated experience in the cloud, for example. There's a couple of other areas where Docker has turned out to have had foresight and driven some of our thinking. So a few years ago, Docker released a thing called Container D where they took out the container runtime from inside the bigger Docker engine. And Container D has become a very important project for us as well. It's the underpinning of Fargate now. And we see a lot of interest from customers that want to keep building on Container D as well. And it's going to be very interesting to see how we work with Docker going forward and how we can continue to give our customers a lot of value starting from the laptop and then ending up at lots of your services in the cloud. Very interesting stuff, interesting. Anytime we have a conversation about Docker, there's Docker the technology and Docker the company. And that leads us down the discussion of open source technologies. You were just talking about Container D, believe that connects us to Firecracker, which you and your team are involved in. Your viewpoint is to what you're seeing from open source. How does Amazon think of that? And what else can you share with the audience on this topic? Yeah, and as you've probably seen over the last few years, both from our work in Kubernetes with things like Firecracker and more recently, Bottle Rocket, AWS gets deeply involved with open source in a number of ways. We are involved heavily with a number of CNCF projects, whether it be Container D, whether it be things like Kubernetes itself, projects in the Kubernetes ecosystem, the service mesh world with Envoy, and with the Container D project. So where Container D fits in really well with AWS is in a project that we call Firecracker Container D. They effectively, for Fargate, Firecracker Container D as you move Fargate towards Firecracker, becomes sort of the container in which you run Container D. It's effectively the equivalent of Run C in a traditional Docker engine world. And one of the first things we did when Firecracker got rolled out was open source to Firecracker Container D project. It's a Go project. And the idea was it's a great way for people to build VM-like isolation and then build sort of the serverless container architectures which we wanted to do with Fargate. And I think Firecracker itself has been a great success. You see companies like Weaverx integrating with Firecracker. I've seen a few other examples of sometimes unbeknownst to us of people picking a Firecracker and using it for very, very interesting use cases and not just on AWS in other places as well. And we learned a lot from that. That's kind of why Bottle Rocket was released the way it was. It is both a product and a project. Bottle Rocket, the operating system, is an open source project. It's out in GitHub. It has all the build tooling. You can take it and do whatever you want with it. And then on the AWS side, we will build and publish Bottle Rocket armies, Amazon machine images. We will support them on AWS. And there it's a product. But then Bottle Rocket, the project, is something that anybody in the world who wants to run a minimal operating system can choose to pick up. And I think we've learned a lot from these experiences, how we deal with the community, how we work with other people who are interested in contributing. And Docker is one of the, the Docker open source pieces and Docker the company are both part of sort of the growing open source ecosystem that's coming from AWS, especially around the container world. So it's going to be very interesting. And I'll end with containerization has started impacting other parts of AWS as well. It's how other services are being built, very often through ECS and EKS, but they're also influencing how we think about what capabilities we need to build into the broader container ecosystem. Yeah, Deepak, you mentioned that some of the learnings from Lambda has impacted the services you're doing on the containerization side. We've been watching some of the blurring of the lines between kind of the container world and the services, serverless world. There's some open source projects out there, the CNCS working on some things. What's the latest as you see kind of containerization and serverless and where do you see them going forward? This is where I say that crystal balls are not my strong sweep, but we hear customers, customers often want the best of both worlds. What we see very often is that customers don't actually choose just Fargate or just Lambda. They'll choose both where for different pieces of their architecture, they may pick a different solution. And sometimes that's driven by what they know. Sometimes it's driven by what fits into their need. Some of the lines blur, but they're still quite different. Lambda, for example, has a very event-driven architecture. It is one process at a time. It has all these event hooks into the rest of AWS that are hard to replicate. And if that's the world you want to live in or benefit from, you're going to use Lambda. If you're running long-running services or you want a particular size that you don't get in Lambda or you want to take a more traditional application and convert it into a more modern application, chances are you're starting on Fargate but it fits in really well. You have an existing operational model that fits into it. So we see applications evolving very interestingly. It's one reason why when we built a service mesh we thought forward and said, it is almost impossible that we'll have a world that's 100% containers, 100% Lambda or 100% EC2. It's going to be some mix of all of these. So we have to think about it that way. And it's something that we constantly think about is how can we do things in a way that companies aren't forced to take one-way doors and oh, I'm going to build on Fargate and then six months later they're like, yeah, we should have probably done Lambda. And I think that is something we think a lot about whether it's from a developer's experience side or if it's from service meshes which allow you to move back and forth on mix and match. And I think that is the area where you'll see us do a lot more going forward. Excellent. So last question for you, Deepak, is just give us a little bit as to what industry watchers should be looking at for container services going forward to next kind of 12, 18 months. Yeah. So I think one of the great things of the last 18 months has been that the type of application that we see customers running, I don't think there's any bound to it. We see everything from people running microservices or whatever you want to call decoupled services these days that services in the end, people are running lots of doing a lot of batch processing, machine learning, artificial intelligence that work with containers. But I think where the biggest changes are going to come is as companies mature, as companies make containers, not just things that they build greenfield applications with but also to start thinking about migrating legacy applications in much more volume. A few things are going to happen. I think we'll be, containers come with a lot of complexity right now. I think if you've seen my last two talks that we went along with David Richardson from the Lambda team, you'll hear that we talk a lot about the fact that we've made customers think about more things than they used to in the pre-container world. I think you'll see now that the early adopter techie part has done, crowd has adopted containers and the next wave of mainstream users is coming in, you'll see more abstractions come on as well. You'll see more governance. I think service measures have a huge role to play here. How identity works, how this fits into things like control tower and more sort of enterprise focused tooling around how you put guardrails around your containerized applications. So you'll see a two or three different directions. I think you'll see a lot more on the serverless side. Just the fact that so many customers start with Fargate, they're going to make us do more. You'll see a lot more on the ease of use, develop experience abstraction side because you started off with the folks who like to think and now you're getting more and more customers that just want to run. And then you'll see, and that's actually a place where Docker, the company and the project have a lot to offer because that's always different. And then on the other side, you have the governance, guardrails, how is this going to be in a compliant environment? How am I going to migrate all these applications over? So that work will keep going on and you'll see more and more of that. So those are three bucket values. The world can surprise us and you might end up with something completely radically different, but that seems like what we're hearing from our customers right now. Excellent. Well, Deepak, always a pleasure to catch up with you. Thanks so much for joining us again. Oh, always a pleasure, Stu. And hopefully we get to do this again someday in person. Absolutely. I'm Stu Minnan. Thanks as always for watching theCUBE. Yep. Thank you.