>> Announcer: From Hell's Kitchen in New York City.
It's theCUBE, on the ground, at Serverlessconf.
Brought to you by SiliconANGLE Media.
>> Hi, I'm Stu Miniman, here with theCUBE
at Serverlessconf 2017 in New York City,
Hell's Kitchen, actually, happy to welcome to the program,
hard to believe, someone, as far as I can tell,
we've never had on the program--
>> Yeah, I don't think so. >> But I've known for
a long time, actually been drinking with him
in Hell's Kitchen before, so Aneel Lakhani,
thanks so much for letting me interview you.
Your current position is vice president of marketing
at Honeycomb.io >> Correct.
>> Do you just call it Honeycomb or--
>> We just call it Honeycomb. >> Alright.
So, Aneel, how are you doing?
Tell us a little bit about your background,
but keep it short and what gets you involved
in the whole serverless ecosystem?
>> Yeah, sure.
So, about me, I've been in tech
for a little over 20 years now, started out as an engineer,
moved through a bunch of systems roles, architecture roles,
and product roles, and now I run marketing at start-ups,
which is what I've been doing for
the last half decade or so.
>> I think back to when Amazon announced Lambda,
everybody's like, "Ooh, it's cool, what is it?
"How do I use it?"
Things like that.
One of the things I've heard out of this event, this week,
is tooling, monitoring, understanding, digging into it,
which really falls into Honeycomb space.
>> Yeah, I mean, it sort of does.
I mean, at Honeycomb we do what we call observability,
which is something a bit larger than just monitoring, right.
It's really getting to the point where you can
develop an understanding of what your services
and what your code do in real life
under real load with real users.
>> Speaking of John Willis, about what is the
role of operations when I don't own the infrastructure,
I have to trust someone else to do it.
So, bring us in there a little bit, what are some
of the challenges people are having,
how do they help when they're leveraging?
>> Yeah, so something that's very clear about
serverless approaches to building things,
and especially if you're using something like Lambda,
is that, as a software engineer, who writes a function,
you are 100% responsible for all of your operations
at that point, because the ops people
for your stack are behind an API.
You are on the other side of that API,
and what they do is effectively a black box,
which means you have to not only understand
what your thing does, you have to understand
what they do and how they do it,
and it's some means of accessing both those bits of data.
So you get what Amazon tells you for Lambda,
or what any of the other providers
tell you for their functions, but you also have to then
understand how your code performs on that specific provider,
which means you have to do things like wrap your functions
in timers and emit events which go into Kinesis,
or wherever else, so that you can track what's going on.
>> Yeah, one of the problems, of course,
any time you have any layer of abstraction is,
if things go wrong, how do you get the expertise to know,
how do you get in there, is this even worse in serverless?
>> Yes and no, I mean, it depends on how much faith
you have in your provider, right?
So, one of the companies here put up a chart that shows you
the performance, on average, of the call response time
for the functions for all of the providers
that provide serverless infrastructure.
And they're not even remotely consistent.
They're not consistent within even a few percentiles.
In other words, if you care about performance,
and you care about predictability for your function,
it's basically impossible to get
that from any given provider.
>> Alright, so, talk to us, what are you hearing from
users these days, what's exciting you in this space?
>> Yeah, so what we hear from our users, anyway,
at Honeycomb, who are using Lambda,
and using serverless functions, is that
the ability for them to get visibility
into how a function performs is basically
the highest priority outside of writing a function itself.
Because they don't know what's happening below them,
they don't know all the resource allocations
at any given point in time by the provider,
so the thing they have to go on,
for the rest of the black box,
is how their own function performs,
which means they need the ability to take any given function
and either decompose it into parts,
which have their own events or metrics
or telemetry that they emit,
or they need to do that to the
entire function from end-to-end.
So basically have a concept of,
this is an old concept for us,
which is an end-to-end check, right?
I want to know what happens when a point that I touch
with a sim until my entire set
of functions are complete at the end.
>> Yeah, we're going back to like an IP ping, right?
>> That's right, yeah, effectively.
>> Today, Honeycomb, do you only support Lambda,
do you support some of the other
serverless frameworks that are out there?
>> So, we are agnostic.
So, basically, the way Honeycomb works is that
our users instrument their code, and we're not service-only,
it could be any code running anywhere,
and they emit data,
and that data is in the form of structured events,
those structured events are consumed by Honeycomb,
and then Honeycomb turns around
and lets you do fast analysis against it.
>> Yeah, you've got a lot of background of,
"How do we leverage the knowledge of the crowd?"
>> Yeah. >> So many times it's
what are people finding when they're
really getting involved here, you're tooling and others,
what mistakes are they making, how can they get
better, faster at what they're doing?
>> Yeah, a common mistake that people make is
not thinking about what is and is not
blocking within their functions,
and not understanding the threading model
of the underlying stack, and when they should spin up
additional functions and split up work,
versus when they shouldn't, and the only way to understand
that is, one, to read all the damn docs,
and two to experiment. >> Yeah.
What about the maturity of serverless?
There've been a lot of discussions here.
I had Mark from Trendade on, we talked about security,
and the like, but what do you see,
kind of in the maturation cycle, of serverless,
anything you've heard, or still things
that are looking to get fixed even more?
>> Maturity isn't the word that I want to use here,
I think it's more interesting to think of it
in terms of breadth of capabilities, right?
So, all of the serverless offerings for all of the vendors
have limitations on either the programming languages
you can use or the nature of the functions that can be run
or the research allocation you can have.
I think there's not a lot of maturity that we're going
to see from the vendors other than
more consistent performance, what we are going to see
maturity in is, from the users' standpoint,
of how they construct things. >> Yeah.
Any data you can share is just how prevalent serverless
is out there in the wild, you know,
what's the typical use taste, typical customer
kind of order of magnitude, how many people are doing it,
and therefore driving discussions?
>> Yeah, I have no idea. >> You have no idea about this.
>> What I do know is, in our user base,
we have some significant users of Honeycomb
who are 100% run on Amazon Lambda,
but that's my tiny, little sample size.
>> Okay, want to give you the final word,
serverless conference and serverless in general,
what's your take today, what should people be
looking at in the next six or 12 months?
>> Yeah, so I more-or-less agree with Simon Wardley
about this, which is, effectively this is a way
for Amazon to eat most of the tech ecosystem,
assuming people become dependent on it.
>> Alright, well, I always say with theCUBE
we like to take those hallway conversations,
someone that I've had many hallway conversations with,
and over the Twitters, and other ways,
it's great to catch up with you, Aneel Lakhani,
thanks so much for joining us >> Thank you so much.
>> I'm Stu Miniman and thanks for watching theCUBE.