>> From the Regency Center in San Francisco,
it's theCUBE!
Covering Serverlessconf San Francisco, 2018.
Brought to you by SiliconANGLE Media.
>> I'm Stu Miniman and this the CUBE's exclusive coverage
of Serverlessconf 2018 in San Francisco.
Happy to welcome welcome back to the program to help me
dig into what's happening in this space
is Cory Quinn who's the Editor
for Last Week in AWS.
Comes in my mailbox every week, you should sign up too.
>> Well thank you for having me back.
Most people aren't foolish enough to invite me
to appear on a program twice.
So it's nice to know that some people
don't always learn their lesson the first time.
>> Cory you're spitting out the newsletters,
you've got your own podcast now, so
you know, you've been getting better,
people are used to hearing your voice
a little bit more, I think, so
we got to put your face out there too.
>> Exactly.
Watch the next quarter and see what happens in that front,
but for now it's mostly I have a face for radio
and I try to embrace that.
>> Alright, so, I'm a little bit nervous.
About 500 people here at the show,
which is about the same as what they did in New York City.
It's bigger than some of the little developer shows
that kind of might cover this space,
but probably the largest single-focused, serverless event.
I was excited to come for our second year
doing theCUBE here,
have you been to this one before?
>> This is my first Serverlessconf.
Generally speaking, they've been very good at
weeding out nonsense proposals
from things people actually want to listen to,
and this year was no exception.
I mostly snuck in to help MC the sponsor track,
and I'm giving a lightning talk
towards the end of the conference.
>> Oh, okay.
You said they're mostly good at filtering,
but you managed to sneak one in anyway.
>> Exactly, you can always sneak through the cracks.
The bar raises very highly,
but you can generally get a ladder, rope,
something to get you over it.
>> Exactly, or you can just duck under real quick
and say I totally jumped over!
>> Exactly, I was so fast, you never saw it.
>> Alright, so.
Tell me, what are you hearing from your customers,
your consultants; do they understand Serverless?
What do they get, what don't they get?
What are some things you have to help with?
>> Serverless is still very much an emerging technology.
There's a perception of it today
that it is something of a toy,
in that you can use it for certain edge-case uses
that you don't want to have an entire fleet running for,
you want to just be able to set it and forget it.
And, that's where it starts to work its way
into an organization.
With time, people start to get comfortable with it,
and then they start to look at applying it
to things that are more directly in-line,
as opposed to back-end processing.
That's one adoption model.
Other people just jump in, full-hog, first day,
as far as figuring out what we can do with this technology;
how do we wind up embracing this
and being forward-looking?
And that's neat to see too.
>> The users I've talked to,
they can start playing quickly,
it's easy, it's very inexpensive to play with,
but they can build real things really fast with this,
and that's what's pretty exciting.
>> Absolutely, the only challenge to that is there's, first,
a fair learning curve, as far as approaching this.
Once you surmount that, it's incredibly fast to work with,
it's fast to iterate with,
and the economics of it are stand-out, fantastic.
>> Yeah, I just had Erica Widdish on the program,
and Erica said,
"Well, some applications you can lift and shift,"
and I'm like, hold on, wait a second.
Well, if I was building microservices,
state-lists, environments,
getting that into Serverless could make some sense.
As opposed to if I had some giant honking stateful thing,
y'know, legacy application, I'm sure not going to do that.
>> Absolutely, every time someone from AWS gets on stage,
I'm excited and I hope, and every time I'm disappointed
they do not announce an AWS 400.
There is still not a great cloud story
for mainframe workloads, for example,
and re-factoring something 20 or 30 years old
that generates revenue to take advantage,
even of the idea of containers, or stateless VMs,
or scaling horizontally,
is still foreign for a number of companies.
It's--
>> We don't need to go down this rabbit hole but,
I talked to Walmart who's doing Global Z
with Docker on their ZBM,
so they could probably run OpenWhisk on that, right?
>> With enough spit and duct tape, anything's possible.
>> Yeah, so I mean, y'know anything's possible,
but would you want to do that?
I guess that brings up a point;
there is a broad eco-system here,
but in the cloud world there's Amazon, AWS,
and everybody else.
There are, last I counted,
at least seven to 10 open-source, y'know,
function digi-service, serverless projects out there,
and you've got the big three or four cloud guys out there,
so there's a lot of options out there for Serverless.
What are you seeing from people you've talked to?
>> I think this is a microchosm
of the cloud ecosystem in general.
There are a number of companies experimenting
with Azure, with GCP, with Orcale, with IBM,
with all of the others
I'm probably not thinking of at the moment,
but everyone is doing something with AWS,
and when you start experimenting with something that is
as far up the stack as serverless functions,
you're generally going to go
with the provider you're already using;
the provider with which you have comfort,
the provider which holds all of your data,
and as a result Amazon has
a tremendous competitive advantage in this space,
and I think they're really
presenting tooling that emphasizes that.
Building out this serverless thing
on some completely different platform,
you lose the event source-mapping,
it's not just about run the code,
it's about how it ties into what's happening
as data flows through your infrastructure.
How does it interface with your existing applications?
>> So to something like Kubernetes,
coming to the conversations you're having,
and I guess that the Google event,
I'm not sure if it's co-native or K-native,
but there was the new K-native project,
which is supposed to, it almost sounds to me like a bridge
to get from if I was doing that istio containers,
Kubernetes type environment, bridge into a serverless world.
>> Yes, to an extent.
There's also their big push, to my understanding,
as far as running a number of Google cloud managed equipment
in your on-prem environment.
Which, they're still going to manage from their end,
so there's an entire security story there
that it would be just as easily, if not more easily,
answered by migrating things into their cloud,
so I'm not entirely sure
as what to the business and strategy play here is.
I assume it's something blindly obvious
that I'm just missing, but we'll see.
>> Yeah, Cory,
I mean I understand if I'm using Microsoft applications
why I might want something like Azure Stack,
I'm looking forward to going to Microsoft in-site
and digging in a little more there,
but they're also doing serverless,
GCP or GKE or whatever it is on-prem,
maybe for some edge-use cases,
like you can do with Snowball, I'd understand it,
but you're right.
I'm a little bit flummoxed trying to understand why this is.
We've spent years with companies like IBM and Oracle saying
you're going to build that same stack here and there,
and there's part of the stack,
and I want to be a managed multi-cloud, but,
how much of that do I really build
and I don't have the Google engineers,
and I probably don't need, y'know,
how much do I need?
I'm still not sold on some of those,
I guess hybrid case, you would call it.
>> Absolutely.
I'm still beating the drums for the concept
that cloud agnosticism is something of a myth,
when you look at it in a per-workload basis.
Okay, I'm going to build this thing
and be able to deploy it anywhere I want to go,
and by doing that I have to build a lot of abstractions
I would otherwise get for free
by picking a certain provider.
That's a lot of work, it slows my feature velocity,
and all I'm buying with that
is an optionality I likely will never use.
>> Alright, so,
you talked about, there's training
and customers need to get involved with this.
What are some of the pitfalls, the roadblocks, the internal,
you say networking, the layer eight-nine,
the politics and organizational--
>> And the financial level, of course, too.
>> Come on, this is all free, right?
Or it's going to lower my costs by 90%,
CFO should be real thrilled, right?
>> Absolutely, and there's the question now of,
okay, how do we wind up running Lambda functions locally
on our developer desktops?
Now, yes, you can more or less build
some Frankenstein monster to do that
in your environment, mostly.
But given the tremendously low cost
of running a function in AWS; run it there.
Have a short enough development cycle time
so you change a line of code, press the button
and you're running this as a task inside of 10 seconds.
If you can drop it down to that speed,
the nine seconds you spent waiting
for that to return its results to you
are probably not substantive
with respect to how you wind up spending your day.
Having to wait 10 minutes for a CICD process
to go through all of its steps
and then return only to find, whoopsy-doozy,
you forgot a semi-colon, is a terrible experience.
There's a how do we wind up fitting this new paradigm
as it stands today, into our existing work-flow model?
And that's something that a lot of companies
are putting a serious amounts of thought into.
And the consensus that has emerged so far
is that everyone else is doing it wrong.
There is no consensus.
Best practices are still emerging; it's still early days.
>> Well we always say, in the emerging spaces
you can't have a best practice, it's a next practice
and I love at an event like this,
you get to hear some of the people,
and there's some of the presentations at this show saying,
Here's what I learnt, here's the good things and, oh yeah,
here's the bear trap that I found myself into.
Any bear traps that you want to point out?
>> Only the ones that have already been beaten to death
by hammers by other people.
There are very few surprises left
in this space as far as Lambda is concerned.
I would say that the things you think you know about Lambda,
with respect to resource limitations, language runtimes,
how many you can run concurrently at a time,
what size package you can have,
double-check that once a quarter or so,
they have a tendency
to change the story around these things.
That's the biggest pitfall I see across the board with AWS;
people are still walking around with the impression
that you can only have 10 tags per resource,
even though that was raised to 50 almost two years ago.
It's the sort of thing where once you've learned something,
it's difficult to keep in touch
with what has changed and how.
And that's part of the problem I started
the newsletter to address.
That, and the fact that I think I'm far funnier than I am.
(laughing)
>> You make me laugh so--
>> I make myself laugh and that was really the entire point.
>> Well hey, if you make yourself laugh,
that's good enough sometimes.
But you brought up a really good point.
This space is changing so fast.
Y'know, used to be you'd plan things out,
you'd roll things out,
and the challenge is that now it's like,
from when I think about it to when I deploy it,
a bunch of these things change.
The underlying assumption changed.
It should mostly be in my benefit, oh wait,
I had a certain limit,
now it's expanded or it's now infinite.
So, other than reading your newsletter,
what do you recommend to people?
How do they even try to keep up?
>> Part of the trick is you don't
have to do that, necessarily,
we've long since crossed a Rubicon
where I can have intelligent conversations
with AWS employees about AWS services
that don't actually exist.
But no-one can keep them all in their head anymore.
It's a terrifying problem;
the first time you sit down
in front of the AWS console and look at the services,
there's 130 some odd of them now,
and it's oh my word,
I am never going to understand all of this!
and that's right!
You don't have to, some are more important than others.
If you are going to be building almost anything today,
understanding EC2 and Lambda would be terrific,
Sumerian, on the other hand,
is a great service that's terrific for VR and AR worlds,
but if you're building a crud accounting app,
maybe virtual reality isn't going to be in your baileywick,
and that service is not for your use case.
And, every service has a story like that.
For example, 8Cloud Guru is built
entirely on top of serverless technology,
they have no EC2 functions;
they don't need to think about anything EC2 does
in the context of running their application.
>> Excellent, I think that should be your tagline
for your consulting clients.
You don't even need to think.
>> Absolutely, that's
generally not how people like to think of themselves,
but we'll see.
I am working on the new tagline for the newsletter,
of course: Last Week in AWS;
"because save money by moving to Oracle
"shouldn't be the most ridiculous thing you read this week."
>> Alright, what other ridiculousness are you seeing out?
I want to give you the chance to poke and prod at
things that you're seeing that are driving you nuts.
>> I used to make jokes about this,
and now I see people start to consider doing it in reality,
where they'll take things like Greengrass,
which lets you run Lambda functions inside of,
on-premises environments on your own hardware,
stuff it into a container, take that container,
schedule it with FarGate,
put it last in a application load balancer in front of it,
so you've rebuilt Lambda without the event bits
all so you can be cloud agnostic
on a different proprietary stack
of everything that they're offering.
This started as a joke,
and somewhere people started taking that seriously.
That's always disturbing.
>> Alright, I've got one last question for you.
You've got a presentation tomorrow,
this video will actually air after you've done it,
so give us the future, according to Cory.
>> So, one of the most defining characteristics of serverless
is there's going to be someone popping up to say,
Serverless runs on servers.
You talk about monitoring, that same person pops up,
and says that it's not monitoring, it's observability.
I am combining the two useless semantic
arguments into observerless.
Which is exactly something that you should be doing,
and probably already are.
You can read more about this at observerless.com
>> We always appreciate when you come on,
because we're never humorless when you're on the program.
So, Cory Quinn.
Be sure to check out Last Week in AWS,
and your podcast also is?
>> Screaminginthecloud.com
>> Thanks Cory, always a pleasure to catch up with you.
And thank you so much for watching theCUBE.