 Live from New York, it's the queue. Covering AWS Global Summit 2019. Brought to you by Amazon Web Services. Welcome back. Rush Hour started a little bit early here in New York City with over 10,000 people in attendance for AWS Summit in New York City. I'm Stu Miniman. My co-host for today is Corey Quinn. Happy to welcome to the program two first-time guests from our host Amazon Web Services. To my right here is Deepak Singh who's the director of Compute Services. Sitting to his right is Aaron Kow who's the senior manager of product marketing. Gentlemen, thanks so much for joining us. Thank you for having us. Thank you for having us. All right, so we know that every day we wake up and there's new announcements coming from Amazon and the only way most of us keep up with it is trying to read Corey's newsletter here. But in your group in Compute, we know that there's a lot going on and quite a few announcements. So Aaron, why don't you kick us off with some of the hard news that went through it this morning? Yeah, we just launched Amazon EventBridge. It's a serverless event bus that allows you to connect your applications with data from sources like SaaS applications, AWS resources, and your own applications. All right, so Deepak, we'd love to dig into that a little bit. I like you said that Amazon, you learned a lot from CloudWatch in building this tool. Everybody looking at kind of, you know, Lambda and the serverless space is like, okay, how are all these pieces going to come together? Is it all Amazon services all the time? And of course, Amazon has a huge ecosystem. But help us understand a layer down, you know, how this works. Yeah, so as you know, you know, AWS services send events to CloudWatch events, they consume events from CloudWatch events. One of the best ways to do it is through Lambda. And Lambda, one of Lambda's biggest strengths is the number of integrations we have with event sources, both taking in events and triggering events. But to your point, there are always events inside the AWS ecosystem. I think one of the things as a service owner that really excites me about EventBridge is how now customers have access not just to event triggers inside AWS, but also from partners like Zendesk. So that's, and the applications we can build will be really exciting. All right, quite a few other announcements, maybe a walk us through some of them. Yeah, CDK is another announcement where it's an open source software development framework that allows you to model your applications using programming language like TypeScript, Java, Python and .NET. The whole thing with building in the cloud is slightly different. You used to take your code, put it on a server and run it. Now people are building things a little more distributed, using a lot of different resources for their applications. So it's getting provisioning your infrastructure is a little bit harder, right? You either have to do a lot of things manually or maybe you're writing a lot of scripts or using a domain specific language. But with CDK, you're now able to use the programming languages that you're perging your applications with to model and provision your infrastructure. So it's super helpful. Really think it's going to help developers increase their development velocity. They're able to use things like loops, conditions, object oriented programming. They don't have to do context switching. And just with a few lines of code, they're able to do a lot more. All right. I want to play with it a little bit when it was in preview. And one of the things that I found that it was extremely helpful was it was a lot easier for me to write something using CDK and then see what that rendered down to in terms of cloud formation. And then, oh, I guess that's how I do it in cloud formation, which was great. The counterpoint though is it also felt at times like it was super wordy. So if I read that, what it generates compared to what I normally write, which is admittedly awful, but I almost start to feel like I'm doing it wrong with that and then with Amplify and with Sam and the rest. There's a lot of higher level abstractions that build cloud formation for you. But then it renders down in a few different and key ways. Under the hood, how much are these products that you're coming out with starting to shape the direction of cloud formation itself? Or is that mostly baked and done? There's a lot of products that we're building that are complimenting cloud formation. Cloud formation is the templating modeling language to provision AWS resources. But on top of that, we have things like Sam that provides a more high level abstracted declarative way to build on top of cloud formation. We have Amplify to also use the cloud formation to help you build mobile applications in front of development. And then finally, you have CDK for just general use. So these things are all complimenting and things customers are asking for and helping us shape the ecosystem there. All right, Deepak, the container space, of course, has been one of these title waves that we've been watching and is fundamentally changing the way people architect their application and that huge impact on your product line. Give us the update. I could just start with some of the high level. I remember the first, when I talked to you a couple of years ago, it was when the whole Kubernetes piece was sorting out. So ECS, EKS used to have a much longer name that Corey would constantly- Only for Corey. Finally, you fixed the compensation problem where someone was getting compensated based upon number of syllables and a service name. So good on you on that one. Right, and the acronym AMI, maybe you can settle once and for all. How we pronounce that? I'm old school, it'll always be AMI. But walk us through kind of your container services. I think the great thing about containers is, as you said, the adoption is everywhere. And what we find is there's a growth of ECS, the growth of EKS, whether you're running it on EC2 or Fargate, everything is growing like crazy because people find new interesting ways to run applications based on what they know and what they're comfortable with. They have customers like Snap that know Kubernetes well and they're building a big chunk of their new infrastructure on EKS or AWS. And it basically helps the developer velocity. On the flip side, your customers like turn a broadcasting that run a lot of their web services, a lot of their Comedy Central content properties like that on Fargate because they can just snap them out. They're all, it's a website, it's a service that they can just keep expanding. So it boils down to what are the key things that you're comfortable with, what are the reasons you pick something? So if you are running like Snap across, in many different places, you are likely to choose Kubernetes and standardize on that. So that's the best part for me is people have choices and then they pick based on what they need at that point in time, which can be two different teams at the same place picking a different solution. I will add that one of the areas that we are focused on now is observability and developer experience. Those are areas that our customers have been asking for. CDK plays into that. You saw it in the demo this morning. And with observability, with container insights and with the fluent bit plugins that we announced, I think those are areas that you'll see us do a lot more going forward. So Roy, that was one of those, the CloudWatch container insights, just to explain what that one is. So historically when you do CloudWatch, it's very VM-centric. You're looking at CPU, memory, you're assuming your application, your instances run for a particular period of time. At the, in the container world, you have services where the underlying tasks come and go all at a very different rate. CloudWatch container insights is meant to be a world that's aware of the fact that your containerized applications are tasks and services and pods. So you're able to get more fine-grained metrics on the things that container customers care about. And you're not trying to use VM-centric language to look at a containerized infrastructure. That's the biggest reason for doing that. And then on the fluent bit side was our customers want log routing to whatever they want to do it on. Whether they want it sent to S3 or Elastic Search, we do that with Kinesis data powerhouse. So we basically wrote a bunch of open source plugins in for fluent bit that just send your log where you want them to go. So that's kind of where we are focused. Yeah, I view it as more of a log router than I do almost anything else. Yeah, it is that. Yeah, a question of where does it come from? Where does it go? How do you keep it straight? Yeah. It's, at this point, what does it output to these days? Are there various destination options, third party vendors, CloudWatch, S3? So we wrote two plugins. One was for, well, three, I don't know, one for S3 because so many people want to send the data to S3. The other one was a Kinesis data powerhouse. So from there, you can send it to Redshift. You can send it to Elastic Search. So based on what, however you want to analyze it, you can send it to a custom resource because it's Kinesis. So you're using some third party provider. You can just send your logs over to those. Yeah. So Corey, you're dealing with a lot of customers. There's now so many, you know, different instance types and some of the pieces, you know, what's the feedback you're giving to, you know, Amazon these days? Entirely depends upon the service teams and it ranges from, this is amazing, excellent job to, okay, it's a good start. And it's always a question though. It's when you have what, 200 service options or darn near it at this point, 170, it's impossible to wind up with something that is evenly consistent and you have services that are sub-components of other services and built on top. I mean, I think the, I guess the feedback I've been giving almost universally across the board is, assume that I am about 20% as smart as you right now seem to think I am and then explain it to me and then I'll probably understand it a lot better. It comes down to service to storytelling more or less of meeting people at various points along their journey. And I was mentioning in our editorial session just before this segment that that's something that AWS has markedly improved on the last two or three years where you have customer stories that are rapidly moving up the stack as far as leveraged services. It's not just we took VMs and now we run them somewhere else. Now it's about building extremely volume intensive applications on top of a whole bunch of managed services and these are serious companies. These are regulators. It's not just Twitter for pets anymore. Nothing wrong with that. No, there is nothing wrong with that. So, you know, we were discussing like FinRow was a great case study this morning and they talked about in the four years that they've been on, pre-architected three times. You know, how do you balance all of these nuances coming out with, you know, how do I make sure that I deploy something today that I've got the flexibility to change but you know, I want to be able to lock in my pricing and make it easier. So actually we think about that quite a bit. One of the reasons we built AppMesh the way we did as something that sits outside a container orchestrator was it doesn't lock you into choosing one or the other or even choosing an architecture. You can start off with a monolith, start putting side cards on it so that it's getting visibility into all your traffic. Then portions of your applications you can start breaking out. You can put them on Fargate, you can put them on ECS, you can put them on EC2. I think that is something we did very consciously because so many of our customers are in that position. And I think more and more are going to go higher up the stack using managed databases, using Lambda, but it's not a decision they need to make all up front. They can do it piecemeal and we see our customer FinRow as a great example. They've done that. Yeah. One of the philosophies of like AWS is giving customers building blocks to build things on. So the whole thing is here's a new primitive that you can use, then you can take it out, replace something with something else depending on your needs. So we give customers flexibility and choice. And part of the problem is that that very much becomes a double-edged sword. I mean, most recently you've had, you've actively declared war on alphabet. I don't mean the large cloud provider that turns things off for a living. I'm talking about the English alphabet where you take a look at all the different EC2 instance types. I think in US East One now there's over, what is it, 190 different instances you can pick from. It leads to analysis paralysis. Which one do I pick? What's the right answer? What am I committing to? What am I not? And you see, like that's a microcosm of the larger service problem. I want to build a web app that does a thing. Which services do I use? You open up the service listing and you just get this sort of sinking sensation. I get that. I can't imagine what someone new to the space is getting to. Yeah. And this is where things like Amplify, Foggate, AWS batch, where you don't need to select an instance. Where you just tell us what your requirements are and batch makes that selection for you. The core building blocks are important because you can't really figure out what to do. But then you'll see us do much more above the stack to help people get there. It's an ongoing thing that we'll keep trying to tackle but we'll see a lot more of that. It's controversial. One of my favorite things about Lambda, for example, is there's one knob, RAM. And as you turn that up, other performance characteristics increase and people complain about it, but I love the simplicity because I don't have to sit and think and make all these different decisions. It's one axis. Yeah, but if you want more knobs, you can use Foggate. So I think that's the beauty of it if you do have that choice. Yeah, one of the lines, Aaron, I really liked in Warner's keynote is he said, we've really, my words, commoditized IT. We all have access to all of the tools now. That was what big data originally in cloud also was, you used to have to be a nation state or a Fortune 100 to be able to do some of these things. So what do you hear from customers? How do they make sure they're staying competitive and ahead and that relationship between the business and IT? What do you hear from your customers these days? Oh, yeah, in terms of that, like I think for customers, like I think EventBridge is a pretty good example of that in terms of customers asking us for ability to integrate their SaaS providers and it great a lot of different things and not have to do a lot of undifferentiated heavy lifting and things like that. And customers are increasingly moving towards like event driven architectures and they ask us, hey, we really like CloudWatch events and how you do things with IT automation and then bringing SaaS providers in. And we don't want to build a polling infrastructure in order to access APIs and do all this heavy lifting. So what we did was we built out, we took CloudWatch events and added new features for SaaS applications and built that into a separate service for people to use. So that's like a lot of the relationships we have with our customers listening to what they need and giving them what they want. No, and I think that's a very valuable thing. We used to say five years ago, you would talk about let's get rid of undifferentiated heavy lifting. Well, now it's like, no, no, let's enable some thing that you would have thought was heavy lifting and were daunted to be able to do it, but now hopefully it's easier because a lot of this stuff, as Corey said, this is still a little bit daunting and you've got a lot of ecosystem and service providers and services to help us take care of because it's the paradox of choice with all the options that you have. And I think that's a beauty of what, I mean our customers are smart. They manage to find interesting ways to keep challenging us and they keep us busy, but I also think that really, really many of them, the ones who have been able to be successful, have figured out what it needs to be, take all the tools we give them, which are the ones where they want to completely hand it over to AWS and give us a responsibility and then which ones do they really feel they care about and the ones who can find their balance are the ones that we see moving the faster. I think that's what we're trying to. And one thing that does absolutely permeates virtually every service team I've worked with at AWS, I mean I've had this experience with you where I talk about how my use case isn't a terrific fit for your product and your response is always, well what is your use case? It's not, it's starting off from the baseline assumption that my use case is ridiculous, which let's face it, it probably is, but being able to address a customer need and understand that even if it doesn't dictate roadmap is incredibly valuable and I don't find that there are too many players in any space let alone this one that are willing to have the patience to listen to frankly some loud person wearing a suit. We try, I mean I think you've heard Andy say this so much, like a big chunk, 85, 90% of our roadmap is customer requests. I would say that even the remaining 10% is maybe not things that they're directly asked for, but things that we've observed they've run into or that we've run into working with the one or two customers who are ahead of the pack and they're like, okay if they have this problem, they could, how do you generalize that? Can we try and understand what it means? One of the reasons we made the container roadmap public was this space is moving so quickly, it's almost impossible for us to talk to enough customers to figure that out, so like okay, this gives us an avenue for them to come to us and just tell us in GitHub issues. Yeah, so right, final question I have for both of you. Yeah, directionally looking forward, the roadmap, we love when there's publicly facing material not under the NDAs that we normally have to be able to hear of so. So what are you hearing from your customers? What direction are they pulling you towards in that we should expect to watch AWS kind of as we head towards re-invent later this year? Yeah, I think customers are asking us for different things for developer experience, especially event-driven architectures. I think there's going to be a lot of interesting things happening in the Lambda space and that entire space. Yeah, and to add to that I think, to your point earlier, helping them simplify choices is going to be a big part of it. Meeting them where they are in their IDEs with their tooling is a big part of what you'll see us do, so I think you saw examples today and we'll keep building on top of those. All right, well, send our congratulations to the two pizza teams that worked on all of the projects that were announced today. Look forward to seeing you down the road in the track and the drive. Thanks so much and welcome to being CUBE alumni next. Yeah, thank you for having us. Aaron Deepak from AWS, he's Corey Quinn. I'm Stu Miniman, back with lots more coverage from AWS Summit here in New York City. Thanks for watching the CUBE.