>> 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.