 Hello, welcome back to theCUBE's coverage of DockerCon 2021 virtual. I'm John Furrier, your host of theCUBE. We're here with Messamu Mefair, principal technologist at AWS Amazon Web Services. Messamu, thank you for coming on theCUBE, appreciate it. Thank you, thank you for having me. Great to see you. Love this Amazon integration with Docker. I want to get into that in a second. Been great to see the Amazon cloud native integration working well. ECS, very popular. Re-interview I've done at re-invent and every year it gets better and better, more adoption every year. Tell us what's going on with Amazon ECS because you have ECS anywhere. And that's being available. Yeah, that's fine. What's the update? That's correct, join. And yeah, so customers has been appreciating the value and the simplicity of ECS for many years now. I mean, we launched ECS back in 2014 and we have seen great adoption of the product and customers has always been appreciating the fact that it was easy to operate and easy to use. This is a journey with ECS anywhere that started a few years ago actually. And we started this journey listening to customers that had particular requirements. I like to talk about the low of the land and the low of the physics where customers wanted to go all in into the cloud but they did have these exceptions that they need to deal with with applications that could not move to the cloud. So as I said, this journey started three years ago when we launched Outpost. And Outpost is our managed infrastructure that customers can deploy in their own data centers. And we supported ECS on day one on Outpost. Having that said, there are lots of customers that came to us and said, we love Outpost but there are certain applications and certain requirements such as compliance or the fact simply that we have like assets that we need to reuse in our data center that we want to use and before we move into the cloud. So they were asking us, we love the simplicity of ECS but we have to use gears that we have in our data center. That is when we started thinking about ECS anywhere. So basically the idea of ECS anywhere is that you can use ECS, the ECS product that you know and love. I'm appreciating the simplicity of using ECS but using your customer managed infrastructure as the data plane. Basically what you could do is you can define your application within the ECS control plane and deploy those application on customer own infrastructure. What that means from a very practical perspective is that you can deploy this application on your managed infrastructure ranging from Raspberry Pi's. This is the demo that we showed at the event when we pre-announced ECS anywhere all the way up to bare metal server. We don't really care about the infrastructure underneath as long as it's supported. The OS is supported, we're fine with that. Okay, so let's take this to the next level. Obviously the big theme at DockerCon is developer experience. You know, that's kind of what I was talking about that. And obviously developer productivity and innovation have to go hand in hand. You don't want to stunt the innovation equation which is cloud native and scale, right? So how does the developer experience improve with Amazon ECS anywhere? Now that I'm on premises or in the cloud, can you take me through what's the improvements around ECS and the developer? Yeah, I've argued that what ECS anywhere solved is more for operational aspect than the requirements that are more akin to the operation team that they need to meet. We're working very hard to improve the developer experience on top of ECS beyond what we're doing with ECS anywhere. So I'd like to step back a little bit and maybe tell a little bit of a story of why we're working on those things. So the customer, as I said before, continue to appreciate the simplicity and the ease of use of ECS. However, what we learn over the years is that as we added more features to ECS, we ended up leveraging more AWS services. Example would be a load balancer integration or secret manager or EFS or other things like service discovery that uses underneath other AWS products like CloudMap or Routes53. And what happened is that the end user experience, the developer experience, became a little bit more complicated because now customers appreciate the ease of use of these fully managed services. However, they were responsible for tying and wiring all together in the application definition. So what we're working on to simplify this experience is we're working on tools that kind of abstract these verbosity that you get with ECS. An example is a confirmation template that a developer would need to use to deploy an application, leveraging all of these features, could end up being many hundreds of confirmation lines in the definition of the service. So we're working on new tools and new capabilities to make this experience better. Some of them are CDK, the co-pilot CLI, the AWS co-pilot CLI. Those are all instruments and technologies and tools they were building to abstract that verbosity that I was alluding to. And this is where actually also the Docker Compose integration with ECS holds in. Yeah, I was just going to ask you that, the Docker piece, because obviously it's DockerCon. All the developers love containers, they love what they do. This is a native mindset of shifting left with security. How is the relationship with the Docker container ecosystem going with you guys? Can you take a minute to explain for the folks here watching this event and participating in the community, explain the relationship with Docker container specifically? Yeah, absolutely. So basically we started working with Docker many, many years ago. ECS was based on Docker technology when we launched and it's still using Docker technology. In last year, we started to collaborate with Docker more closely when Docker releases the Docker Compose specification as an open source project. So basically Docker is trying to use the Docker Compose specification to create an infrastructure cloud agnostic way to deploy Docker application using those specifications in multiple infrastructure. As part of this journey, we work with Docker to support ECS as a backend for this specification. Basically what this means from a very practical perspective is that you can take a Docker Compose an existing Docker Compose file and Docker says that there are 650,000 Docker Compose files spread across GitHub and all source control system over the word. And basically you can take those Docker Compose file and compose up and deploy transparently into ECS Fargate on AWS. So basically if we go back to what I was alluding to before the fact that a developer would need to author many hundreds line of confirmation template to be able to take their application and deploy it into the cloud. What they need to do now is authoring a new file a YAML file with a very clear and easy to use Docker Compose syntax Compose up and deploy out to magically on AWS and using ECS Fargate and many other AWS services in the backend. And what's the expectation in your mind as you guys look at the container service to anywhere model beyond premise and without post, what's the vision? Cause that's again another question mark for me is like, okay, I get it totally makes sense. But containers are showing the mainstream enterprises not the hyperscales. You guys have always been kind of the forward thinkers, but you know, main street enterprise, I call it they're picking up adoption of containers in a massive way. They're looking at cloud native specifically as the place for modern application development. Period. That's happening. What's the story? I mean, say it again. Cause I want to make sure I get this right. ECS anywhere, if I want to get on premise in a hybrid, what's it mean for me? This goes back to what I was saying at the beginning. So there are, there are, what we have been discussing here are mostly two orthogonal things, right? So the fact that we enable these big enterprises to meet their requirements and meet their checkboxes sometimes to be able to deploy outside of AWS when there is the need to do that. This could be for edge use cases or for reusing gears that exist in the data centers. So this is where ECS anywhere is basically trying, this is what ECS anywhere is trying to address. There is another orthogonal discussion which is developer experience. And that developer experience is being addressed by these additional tools. What I like to say is that the confirmation is becoming a little bit like a sampler in a sense, right? It's becoming a very low level, super powerful but very low level. And we want to abstract and bring the experience to the next level and make it simple for developers to leverage the simplicity of some of these tools including Docker compose and being able to deploy into the cloud and getting all the benefits of the cloud, scalability, elasticity and security. I love the, the assembler analogy because you think about it, a lot of the innovation has been kind of like low level foundational. And if you start to see all the open source activity and the customers, the tooling does matter. And I think that's where the ease of use comes in. So the simplicity totally makes sense. Can you give an example of some simplicity piece because I think, you know, you guys, you know, look at looking at ECS as the cornerstone for simplicity, I get that. Can you give an example, walk us through a day in the life of an example? An example of simplicity. Yeah, simplicity in action. Yeah. Well, one of the examples that I usually do and there is this notion of being serverless. I think that there is a little bit of an obsession around serverless and trying to talk about serverless for so many things. When I talk about ECS, I like to use another moniker that is versionless. So to me, simplicity also means that I do not have to update my service, right? So the way ECS works is that engineering in the service team keeps producing and keeps delivering new features for ECS overnight for customers to wake up in the morning and consuming those features without having to deal with upgrades and updates. I think that this is a very key, a very key example of simplicity when it comes to ECS that is very hard to find in other solutions, whether they are on-prem or in the cloud. That's a great example. And one of the big complaints I hear just anecdotally around the industry is, you know, the speed of the minds of business want the apps to move faster and the iteration with some craft, obviously with security and making sure things buttoned up. But things get pulled back, it's almost slowed down because the speed of the innovations happening faster than the compliance of some sort of, you know, old governance model or code reviews. I want to approve everything. So there's a balance between making sure what's approved, whether it's security or some pipeline, you know, procedures and whatnot. So this is a huge issue. I cannot agree more with you. Yeah. No, it's absolutely true. Because I think that we see these very interesting dichotomy, I would say between startups moving super fast and enterprises trying to move fast but forced to move at their own speed. So when we deliver services based on, for example, open source software that customers need to look after in terms of upgrade to latest release, what we usually see is startup asking us, can you move faster? There is a new version of that software. Can you enable us to deploy that version? And then on the other hand of the spectrum, there are these big enterprises trying to move faster but not so much that are asking us, can you slow down a little bit, right? Because I cannot keep that pace. So it's a very interesting time to be alive. You know, one of the things that pop up into these conversations when I talk to VP of engineering of companies and then enterprises is that the operational efficiency, you got developer productivity and you got innovation, right? You got the three kind of things going on there, knobs and they all have to turn up. That people want more efficiency out of the operations and more developer productivity and more innovation. What's interesting is you start seeing, okay, it's not that easy. There's also a team formation. And I know Andy Jassy kind of referred to this in his keynote at re-invent last year around thinking differently around your organizational. But that could be applied to technologists too. So I'd love to get your thoughts while you're here. I know you blog about this and you tweet about this but this is kind of like, okay, if these things are all going to be knobs we turned up, innovation, efficiency, operationally and developer productivity. What's the makeup of the team? Because some are saying you got an SRE embedded, you got the platform engineering, you got version lists, you got server lists, all these things are going on, all goodness. But does that mean that the teams have to change? What's your thoughts on this? I want to get your perspective. Yeah, I know, absolutely. I think that there was a joke going around that as soon as you see a job like VP of DevOps, I mean, that is not going to work, right? Because these things are, needs to be like embedded into each team, right? Is that there shouldn't be a DevOps team or anything. They'd be just a way of working. And I totally agree with you that these knobs they needs to go insane, right? And you cannot just push too hard on innovation if you're not helping other folks to be able to, you know, keep that pace with you. And we're trying to help customers with multiple tools and services to try to help not only developers and making developer experience better, but also helping people that are building these underneath platforms. Like for example, Proton, AWS Proton is a good example of these where we're focusing on helping these teams that are trying to build platforms that are not looking themselves as being agile or very fast, but they're measured on being secure, being compliant and being, you know, within a guardrail that an enterprise, a regulated enterprise needs to have. So we need to have all of these people, both organizationally, as well as with providing tools and technologies that help them in their specific areas to succeed. Yeah, and what's interesting about all this is that, you know, I think we're also having conversations. And again, you're starting to see things more clearly here at DockerCon. We saw some things at KubeCon, which the joke there was, not joke, but the observation was it's less about Kubernetes, which is now becoming boringly reliable to more about cloud native applications under the covers with programmability. So as all this is going on, there truly is a flip of a script. You can actually re-engineer and refactor everything, not just replatform your applications in IT at once right now, there's a window, whether it's security or whatever. Now that the containers and the Docker ecosystem and the container ecosystem and the Kubernetes, you've got AKS and you got ECS, Fargate, I mean, all this stuff is a goodness. Companies can actually do this right now. They can actually change everything. This is a unique time. This window might close or certainly change. And if you're not on it now, it's the same argument of the folks who got caught in the pandemic and weren't in the cloud got flat footed. So, you know, you're seeing that example if you were in the cloud during the pandemic, before the pandemic, you were probably losing during the pandemic. The ones at one where the already guys are in the cloud, now the same thing's true with cloud native. If you're not getting into it now, you're probably going to be in the wrong side of history. What's your reaction to that? Yeah, no, I agree totally. I like to think about this. I usually talk about this if I can step back a little bit. And I think that in this industry, and I have great areas and I have seen lots of things. I think that there has been two big democratization events in IT that happened and occurred in the last 30 years. So the first one was from, you know, from when the PC technology has been introduced, distributed computing from the mainframe area. And that was the first democratization step, right? So everyone had access to computers, so they could do things. If you fast forward to these days, what happened is that on top of that computer, whatever that became a server or whatever, there is a very complex stack of technologies that allow you to deploy and develop and deploy your application, right? But that stack of technology and the complexity of that stack of technology is daunting in some way, right? So it has enabled access and democratic access to technology. So to me, this is what cloud enabled, right? So the next step of democratization was the introduction of cloud services that allow you to bypass that stack, which we call undifferentiated heavy lifting because, you know, you don't get paid for managing, I don't know, an EMR server or whatever. You get paid for extracting values through application logic from that big stack. So I totally agree with you that we're in a unique position to enable everyone with what we're building to innovate a lot faster and in a more secure way. Yeah, and what comes out, I totally agree. And I think that's a great historical view. And I think let's bring this down to the present today and then bring this as the bridge to the future. If you're a developer, you could, and by the way, no matter whether you're programming infrastructure or just writing software or even just calling APIs and rolling your own, composing your services, it's programmable. And it's just all accessible. So I think that's going to change the, again, back to the three knobs, developer productivity or just people productivity, operational efficiency, which is scale, and then innovation, which is the business logic where I think machine learning starts to come in, right? So if you can get the container thing going, you start tapping into that control plane. So it's not so much just the data control plane, it's like a software control plane. Yeah, no, absolutely. The fact that you can, I mean, as I said, I have gray hair, so I've seen a lot of things. And back in the days, I mean, the whole notion of being able to call an API and get 10 servers, for example, or today 10 containers, it would be like, almost a joke, right? So we spent a lot of time racking and doing so much manual stuff that was so error-prone, because we usually talk about velocity and agility, but we rarely talk about the difficulties and the problems that doing things manually introduce in the process, the way that you can get wrong. Massimo, you know, it reminds me of this industry, and I always like, finally, I think, get off my lawn in the old days, I walked to school with no shoes on in the snow. We had to build our own kernel in our own graphics libraries. And then now they have all these tools. It's like, yeah, just an old coder, but joking aside, you know, that experience, you're bringing up a point for the younger generation who have never loaded a Linux operating system before or have done anything at that level. It's not so much old versus young, it's more of a systems thinking. You said distributed computing. If you look at all the action, it's essentially distributed computing with new software paradigm. And it's a system architecture. It's not so much software to engineering, software developer, you know, it's just basically all engineering at this point, all software. It is, it is very much indeed. It's all software. There is no other way to call it. It's, I mean, we go back to talk about infrastructure as code and everything is now code or software in a way. It's, yeah. That's great to have you on. Congratulations, ACS Anywhere being available. It's great stuff and great to see you and great to have this conversation. Amazon Web Services, obviously the world has gone super cloud. Now you have distributed computing with Edge, IoT exploding beautifully, which means a lot of new opportunities. So thanks for coming on. Thank you very much for having me. It was a pleasure. Thank you. Cube coverage of DockerCon 2021 virtual. This is theCUBE. I'm John Furrier, your host. Thanks for watching.