>> Live from Barcelona, Spain, it's theCUBE, covering KubeCon + CloudNativeCon Europe 2019. Brought to you by Red Hat, the Cloud Native Computing Foundation, and ecosystem partners. >> Welcome back to Barcelona, Spain, this is theCUBE's live coverage of KubeCon, CloudNativeCon, 2019. 7,700 people in attendance, including myself, Stu Miniman, and co-host Corey Quinn, and returning to the program, Abby Fuller, who is the principal container czarina (Abby laughs) at Amazon Web Services. Yeah, Abby, I could say it without laughing, but, uh-- >> I can't. >> I don't think you can. Yeah, so, you know, let's just, czarina? You know, how does one, you know, become a czarina in their career, Abby? Let's start there. >> You ask Deepak really nicely, and he'll change your title for you. Longer answer, I think I'm doing a similar version of what I've always done for Amazon. Which is, how can I get what customers are asking for, and their feedback, and what they're struggling with, they're working on, or enjoying? Taking that back to our internal product development process, and then doing the same thing back the other way. So if we're building something, how can I help educate customers on how to work with it, and how to use it, how to build with it? So, same thing, just funnier title. >> All right, well, Abby, you know, it's a big, cloud show, so of course we know Amazon will be here. Lot's of developers here at the show, lot's of activity. Yesterday AWS held a, kind of, pre-show workshop. Maybe start there, tell us a little bit about that. >> Yeah, so we had AWS Container Day, maybe five or six hundred people, we did it at the hotel that is allegedly across the street, but is really, like, twenty five minute walk away. We did some workshops, we did a Birds of a Feather session at night. We had a little, mini, product preview announcement, so that was pretty fun. Something called, Container Insights, from CloudWatch team. I think my favorite thing about KubeCon is my favorite thing about the Kubernetes community, right, which is that, everyone is so happy to be here. They're all so enthusiastic. I've never had that many questions at a Birds of a Feather session before. We sent a ton of Amazon people here, to, kind of, talk about EKS, and Kubernetes, and community work. And the energy at the KubeCon is always so impressive. >> Give us a little sampling, you know, there's passion, is there questions? Are they trying to understand the various pieces? Are they excited about some of the new features? What's some of the energy you're capturing? >> Yeah, you know, I think it's both. I think on the EKS side, there's always the balance, right, in the Kubernetes community between, how can I have more power and flexibility? And then, how can you carry pager for more of this? So I think it's always an interesting balance, between the folks that are like, hmm, do you think you could manage that for me as well? And the folks that are like, I want to be able to pass in control plain flags. So, there's always an interesting balance. A lot of questions about version upgrades. I think that one is always, always seems to be top of mind, 'cause the Kubernetes community moves so fast. So, compared to a lot of other products, and how quickly they can release new versions, Kubernetes moves so fast. So, if you don't have a good upgrade strategy, you're in trouble. So-- >> Well, to that point, yesterday during the talk, there was a slide that went up, that listed, over the trailing 12 months, that there were 1,900 and change major service and feature releases. And that's very much a two edged sword, sitting in the audience, 'cause on the one hand, yay, the pace of innovation continues to increase, and services are getting better all the time. On the other, it's one of those, hmm, at least four of those would have been critically important, but I may not know about them. And to that end, something that the container group seems to have done, that almost no one else has, has been to put up a public roadmap of what's coming down the pike. Which has been tremendously helpful for customers, as far as being able to plan things out. How did that come to be? >> A lot of talking. I think, ultimately, right, all teams at AWS work the same way. Which is, backwards from what the customer is asking for. So, we have a lot of customer meetings. We have a lot of customer conversations, we talk to a lot of people. I do a lot with that on social media, or at conferences, or with blogs, or with live streaming. But ultimately, at the root of it, we all follow the same process. And I think the roadmap is really an extension of that. It's, how could we get, both what we're working on, to customers a little bit faster, but also, how can you have a voice that we hear so much more loudly? So, right? That you can be the smallest start up, or the largest enterprise, and you can open a GitHub issue just the same. And say, hey, you know, I'd really like to see you do that. And, I think the other piece of it, is that everyone has an AWS story. Where they build something custom, to work around something, or to add a feature, and then six weeks later we're like, we shipped it! And that's awesome, it's a good problem to have, and being able to delete code is one of everyone's favorite problems, I think. It's my favorite problem. >> It's one of life's true joys. >> It is one of life's true joys. (Corey laughs) But, what I think is even better than that, is a little bit of a heads up. And I think that that really builds trust between us and the community, is, how can we let you know we're working on, so you can plan around it? Or, if you don't see something, let us know that we're not thinking about the things that you value. >> Well, So Abby, you know, we've been at the Amazon shows for a number of years-- >> Yeah. >> And that customer feedback loop is something that we hear a lot. >> Yeah. >> Are there any dynamics about, just being in a big, open source community here, is, you know, just listening, and feedback loops as part of that? So, how does that impact, you know, how you work on things? >> Yeah, so, when we do events like this, I try to talk to as many people as possible. I try to listen in to the conversations, when I can. People come by the booth, they come by the meeting rooms. And I think it's about taking that back from all the different sources that were at the conference, the reviews online, the blog posts that people write after this, coverage like theCUBE, taking that all back, and then let's go through it. And then, how many of these things do we know about? Have a lot of people asked us for this? Is this something new? If it is new, how can we go find other people to talk to, to see who else is having that problem, that maybe we just didn't know to ask about before? So it's all part of that same working backwards process, but feedback comes from so many different places, and I think that, that ultimately is what makes it cool, right? It's because you get different feedback at a KubeCon than you will at a re:Invent, than you will on a Twitter, or that you will at a customer meeting. So, you need all of those sources to kind of figure out, what's more important? And, who is it important to? >> Yeah, one of the things that I find fascinating about the entire AWS Container story is, you almost get to decide your own level of involvement. You can run it all yourself, on top of EC2, you can wind up doing one of the manage serves with ECS, or EKS. And then there's Fargate, which I'm very bullish on for the future, if for no other reason that, if that takes over, suddenly we will never have to hear someone from Amazon mispronounce AMI, ever again. Which, I'll take my victories where I can find them. (Abby laughs) But, what are you seeing customers doing with Fargate? What's the paradigm look like, that's different than you might have expected at launch? >> Yeah, so, the way that I ultimately think about Fargate, right, is as a, it's a capacity provider for EC2. So, when you think about, kind of, the levels of control, right? You start at maybe the orchestrator level, so an ECS or an EKS. And if you're using ECS through Fargate, you're not interacting directly with EC2. So it's about, how can I control and define everything at just the container level, just at the task definition level, without having to think about the underlying EC2 instances? And they're still there, before someone tells me that serverless still has servers. But, you're not the one that's actively managing them. We're managing them on your behalf. All you care about is your workload itself. And then you can go a step deeper than that, and say, you know what, I want control over those EC2 instances. I want to manage them myself, maybe I want to do something in user data, or I want to be able to run DaemonSets myself, on the underlying infrastructure, and that's fine. So, I think it's ultimately about the level of control that you want. Fargate, to me, is interesting because it's like Lambda, in the sense that people have seemed very joyful about not having to manage EC2. Because ultimately, that's not what's providing them business value. That's not what let's them differentiate, and I think the way that Werner puts it is, you want everything that you write to be business logic. And I think with things like Lambda and Fargate, it gets you one step closer to that. That instead of having to manage infrastructure, to then manage your code, it's, just manage my code, please figure out the rest of it for me. >> This is borderline heresy in some circles, so don't, at me. (Abby laughs) But, what I'm wondering is, are things like containers, and functions as a service, aligned longer term, on the same axis? At some point, where it just becomes an implementation detail, and not a battle that needs to be fought. >> Yeah, the way that we think about it, right, is that, and I think the way that customers see it, is that serverless is ultimately a spectrum. There are many different flavors of it, depends on how you kind of want to work with it. But ultimately, I think, even longer term, maybe this is even more heretical, right? But, I want to not care. I don't want to have to care about the primitive that you're using. I don't want you to have to choose. And right now, I think you have to choose, regardless of the tool that you're using, you must choose very early. And to take advantage of a new tool, to go from containers, to Lambda, or whatever else you want to use, you have to re-write. Or you have to rebuild, or you have to re-wrap what you're doing. And I want to get to a point where you don't care. That I can use whatever combination of the below that I want to use, and that AWS will provide tools around that, that just says, you run this however you want. You mix and match whatever flavors you like, and we'll take care of it. >> Yeah, it's interesting, almost every time we've done one of these Kubernetes shows, we've had somebody from Amazon on, and even if we haven't had an AWS employee, almost every customer we have on is doing some, if not a lot of Amazon. There's some out there that look, and they're like, well, Amazon doesn't have the biggest booth, and Amazon has all of these different choices out there, so they must not be fully committed to, you know, capitol K, Kubernetes, and things like that. How can you help us understand what's going on? >> Yeah, so, I think Bob Wise, and his team spent a ton of time working on the community, and the whole team does, right? We're one of the biggest contributors to etcd, we're hosting Birds of a Feather. We've contributed back to a fair amount of community projects, and I think a lot of them are, in fact, around how to just make Kubernetes work better on AWS. And that might be something that we built because, EKS. Or, it might be something like Cluster Autoscaler, right? Which, ultimately, people would like to work better with Auto Scaling groups. So, I think we have the community involvement, but, I think it's about having a quiet community involvement, right? That, it's about chopping wood, and carrying water, and being present, and committing, and showing up, and having experts, and answering questions, and being present in things like SIG groups, than it is, necessarily, having the biggest booth. >> Yeah, I mean, from my perspective, at conferences, across the board, community involvement can never be measured by who spends enough money on the conference to have a booth large enough to play ice hockey in. That doesn't really seem to be as good of a barometer. Things like the roadmap, tend to be a spectacular, I guess, expression of how that engagement is starting to look. And I really am enthusiastic to see what's been done so far, and I'm looking forward to seeing more of it. >> Well thank you, I'm really proud of the roadmap. It's been so interesting to see customers take a, kind of, a new level of transparency, for us, product roadmap wise. And then, I love seeing people go through, and start adding more. So, I feel like the roadmap started to feel successful to me when customers started opening a ton of issues, and saying, hey, have you thought about this? Our new thing is, we've been posting requests for comments, or design docs on there, and saying, you know, we're thinking about building this, and here's what we were thinking about building. Did the way that we built this solve the problem that you're trying to solve? 'Cause ultimately, you can build the coolest thing in the world, and if it doesn't solve problems for your customers, what's the point? >> Yeah, and Abby, I'll reiterate that the roadmap was something that, you know, the ecosystem, the community, was very excited about. What other things did you want to share before we wrap? You know, things at the show, or related to the container space that, you know, you're hearing your customers talking, and asking a lot about. >> Yeah, so I've heard great things about all the sessions. I think that I'm a little biased, 'cause I was on the program committee. So, obviously the selection was universally excellent. Yeah, I think, what I like the most, I think, about events like this, is that everyone seems to have a different way of solving things. They're all asking for something new. They're all talking about a different project. They're all in different SIG groups. They're all making different feature requests. They're all using different tools. I think that that's really powerful, and I think was what's made Kubernetes so amazing, is that, the whole community feels like this. This is a huge turn out for a conference, and everyone feels very, like, actively engaged. And I like seeing us, kind of, push the boundaries, right? Between, how much can I pass off to something like EKS? And then, how much can I keep customizing, but on only the things that matter to me? >> I guess, as you're talking about roadmap, and plans for the future, if I were to build an environment on AWS, going back, let's say a decade-ish, I would have built something in a single AWS account, using EC2 classic, and maybe simple DB, as a data store. Which, generally, is in no way aligned with best practices today, and migrating off of those types of architectures, for some customers, has been painful. Is there any way to, I guess, loosen the abstraction, for lack of a better term? Of, what, the things we can do, and build in a forward looking way today, that will make migrating to whatever best practices emerge from the customer learnings, or the rest, in the future, not be the equivalent of an entire migration? >> Yeah, so, I think what you're asking, right, is, how can I make, kind of, adopting new technologies, or migrating, a little bit easier? >> Yeah. Or even, adopting new patterns. >> That's a really interesting one. Yeah. I think where I see this space kind of going, and where I think it gets interesting to me, is thinks like App Mesh. So, I can have many different kinds of compute inside of a mesh, through App Mesh, right? So I can have an application running on EC2, I can have a container running with EKS, or ECS, I can have Kubernetes on EC2. In the fullness of time, I'd love to see things like Lambda functions inside an App Mesh. What I like about that, is that, how that can make the migration process easier. Because if I can have many types of primitives in the same mesh, I can mix and match, or I can drain traffic off from one to the other, and I can experiment a little bit more without having to re-write, 'cause I can try it out. It can be part of the same mesh, and if I want to move, I can just move more stuff over. So, I think that's interesting, and I think, as for, kind of, the best practices, and stuff like that, we evolve hand in hand with our customers. As our customers are figuring out new technologies that they want to use, or new ways of building things, we want to be right there with them. And I think the AWS way is about, how can we help customers build whatever way they want to do, but help them be secure, reliable and scalable. >> Yeah. What I'm hearing from that, as a take away, is, if I'm not playing around with service mesh's, or app mesh's now, it's probably time to fix that, and learn how they work. >> I think it's a new technology. I think it's an interesting one, I'm excited to see where it goes, but, watching it, kind of, grow along with Kubernetes, has been really interesting. >> All right, well Abby Fuller, thanks so much for joining again on theCUBE. >> Thanks for having me. >> For Corey Quinn, I'm Stu Miniman, you're watching KubeCon, CloudNativeCon 2019, in Barcelona, Spain, thanks for watching theCUBE. (futuristic music)