>> Announcer: Live from New York. It's the Cube. Covering AWS Global Summit 2019. Brought to you by Amazon Web Services. >> Welcome back rush hour's 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 Kao, 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. >> Alright, 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 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 this morning? >> Yeah, we just launched Amazon EventBridge. It's a serverless event boss that allows you to connect your applications with data from sources like SaaS applications, AWS resources and your own applications. >> All right, so Deepak, I would love to dig into that a little bit. Like you said you that Amazon, you've learned a lot from CloudWatch and building this tool. Everybody looking at kind of, you know, Lambda in 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 or layer down you know how this works? >> Yeah so as 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. 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 database ecosystem. And 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 to our partners like Zendesk and the applications you can build will be really exciting. >> Alright, quite a few other announcements, maybe 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. You know, the whole thing with building in the cloud, it's 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 programming 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 wound up playing 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 in 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 you know, are complementing cloud formation. You know, cloud formation is the templating modeling language to provision AWS resources. But on top of that, we have things like Sam right, that provides a declarative a more high level abstract declarative way to build on top of cloud formation, you know, we have Amplified that also uses cloud formation to help you build mobile applications and front end development. And then finally, you have CDK for just general use. So, these things are all complementing and, you know, things customers are asking for and helping us shape the ecosystem there. >> Yeah, Deepak the container space, of course, has been you know, one of these tidal waves that we've been watching and it's fundamentally changing the way people architect their applications and has huge impact on your product line. Give us the update. If you could just start with some of the high level, I remember first when I talked to you a couple of years ago it was when the whole Kubernetes piece was sorting out. So you know, ECS, EKS, used to have a much longer name that Cory would constantly >> Only for Cory >> Finally you've 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 you know the acronym A-M-I maybe you can you know settle once and for all you know how how we pronounce that. >> I'm old school it'll always be AMI. (laughs loudly) >> Walk us through kind of, you know 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. We have customers, customers like SNAP that know Kubernetes well and they are building on there're building a big chunk of their new infrastructure on EKS on AWS and it basically helps the developer velocity. On the flip side, you have customers like Turner Broadcasting that run a lot of their web services or the Comedy Central content properties like that on Fargate because they can just stamp them out. They all you know, 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've picked something. So if you're running like SNAP across, you know, 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 observe ability and developer experience. Those are areas that our customers have been asking for. CDK plays into that you saw in the demo this morning and with observe ability with container insights and with the fluid plugins that we announced. I think those are areas that you'll see us do a lot more going forward. >> So right, that was one of news today, CloudWatch container insights just to explain what that one is. >> So historically, when you do CloudWatch look, it's very BM-centric, you're looking at CPU memory, you assuming an application, instances run for a particular period of time. In the container world, you have services where the underlying tasks come and go, all you know, 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 BM-centric language to look at a containerized infrastructure. So 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 to send to S3 or the Elasticsearch We do that with Kinesis Data Firehose. So we basically wrote a bunch of open source plugins for Fluent Bit that just send your logs 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. >> 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 you these days? Are there are various destination options, third party vendors, CloudWatch, history? >> So we wrote two plugins one was for well three, I don't know. One for S3 because so many people don't understand the data to S3. The other one was a Kinesis Data Firehose. So from there, you can send it to Redshift, you can send it to you can send it to Elasticsearch. So based on what you however you want another analyze it, you can send it to a custom resource that's Kinesis. So, you're using some third party provider, you can just send your logs over to those. >> Yeah, Corey, you know, you're dealing with a lot of customers, you know, 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 then 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 leverage services. It's not just we took the VMs and now we run them somewhere else. Now it's about building a high, 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. >> So, you know, we were discussing, like FINRA was a great case study this morning and they talked about in the four years that they've been on, they've re-architected three times. You know, how do you balance all of these new instances coming out with, you know, and 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 app match the way we did, as something that sits outside the 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, 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 the 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 decision they need to make all up front. They can do it piecemeal, and we see our customers find another good example, they've done that. >> One of the philosophies of it, 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 effectively 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, 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 there. >> All right, and this is where things like Amplify, Fargate, 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 about the stack to help people get there. It's an ongoing thing that will keep trying to tackle but you'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 access. >> Yeah, but if you want more knobs, you can use Fargate. So I think that, that's the beauty of it that you do have that choice. >> Yeah, one of the lines Aaron, I really liked in Werner's keynote is he said, "we've really, you know, my words commoditized IT. "We all have access to all of the tools now." You know, that was, you know what big data originally and cloud also was, you know, you used to have to be a nation state or fortune 100 to be able to do some of these things so, you know, what do you hear from customers? You know, how do they make sure, you know, they're staying competitive and ahead, and therefore, in that relationship between the business and IT, what do you hear from your customers these days? >> In terms of that? Well, I think for, you know, for customers, like I think EventBridge is a, a pretty good example of that, in terms of customers asking us for ability to, you know, integrate their SaaS providers, integrate a lot of different things and not have to, you know, not have to do a lot of undifferentiated heavy lifting and things like that and, you know, customers are increasingly moving towards like event driven architectures and they asked us, hey, we really like CloudWatch events and how you do things with IT automation and then bringing SaaS providers in and, we want to, you know, we don't want to build pulling infrastructure in order to access API's and do all all those heavy liftings. 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, you know, a lot of the relationships we have with our customers, listening to what they need and giving them what they want. >> And I think that, that's a very valuable thing. You know, we used to say, you know, five years ago, you would talk about, you know, let's get rid of undifferentiated heavy lifting. >> Yeah. >> Well, now it's like, no, no, let's enable, you know, something that you would have thought was heavy lifting and we're daunted to be able to do it but now hopefully, it's easier, because a lot of this stuff, you know, as Corey said, this is still a little bit daunting and you know, well you've got a lot of ecosystem and service providers and services to help us, you know, take care of, you know, because it's the Paradox of Choice with all the options that you have. >> And I think that's the beauty of what, I mean our customers are smart, they manage to find it 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 means to take all the tools we give them, which are the ones where they want to completely hand it over to AWS and give us the 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 fastest. I think that's what we're trying to do. >> All right, now and one thing that does absolutely permeates virtually every service team I've worked with at AWS, I mean, you I've had this experience with you, where I talked 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, is 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 heard Andy say there's 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've directly asked for but things that we've observed they've run into or that we've run into working with, you know, the one or two customers who are ahead of the pack. And Okay, they have this problem, how do you generalize that? And 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, GitHub issues. >> Yeah, so right. Final question I have for both of you. Directionally looking forward, you know, the roadmap, we love when there is publicly facing material not under the NDAs that we normally have to be able to hear. So what are you hearing from your customers? What direction are they pulling you towards and that we should expect to watch AWS kind of further, as we head towards re:Invent later this year. >> 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 a tooling is a big part of what you'll see us do. So, you know, 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, you know, down the road. Thanks so much and welcome to being Cube alumni. >> Thank you for have us. >> Thank you for having us on. >> Appreciate it. >> Aaron, Deepak you know, 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.