>> Narrator: From Hell's Kitchen in New York City,
it's The Cube on the ground at Serverlessconf.
Brought to you by SilliconANGLE Media.
>> Hi, I'm Stu Miniman with The Cube,
and we're here are Serverlessconf in Hell's Kitchen
New York City, really happy to welcome
to the program, another one of the keynote speakers.
Ben Kehoe, who's the Cloud Robotics research
scientist at iRobot.
>> Yeah. >> Ben, great to see you.
>> Great to see you too.
>> All right, so tell us a little bit about
how you got involved with Serverless.
>> Yeah, I mean it all started, I was a grad
student in robotics, and I started thinking
about, you know, we have all these robotics algorithms.
And as the cloud can enable robots
to do more and better things, how do we
help turn those robotics algorithms
into web services.
And I didn't get very far in that, right towards
the end of my PHD, and then that was
2014, LAMBDA was released, and it was like
hey, that looks like it does the kind of thing
that I was thinking about that we needed.
So then I joined iRobot, and we were developing
a cloud solution, a cloud application for
our connected robots and apps, and
to help us scale that to stay lean.
Serverless was the right choice,
and we've been doing that since 2015.
>> Yeah, so Ben, what is it about Serverless
that made it a fit for this?
You know, I think about, doesn't their
responsiveness, performance, latency
if I have to go >> Yeah.
>> up to the cloud and back like that way.
I think some of this needs to kind of live locally.
And some that goes there, maybe you can just
briefly tease through some of those
dynamics for us.
>> Yeah, when you're talking about robots,
you definitely have to keep things local.
You want a robot to be responsive to its environment.
You want, that even if its cloud connection disappears,
that it can still accomplish all of its tasks.
So it's always a mix of keeping it
as a timeless robot that is enabled
to do better things through the cloud,
in terms of additional computational power,
or accessing libraries of information to help
it understand its world better.
And of course, when one robot learns something,
all robots can benefit from that experience.
>> Excellent, so this is the first step for Skynet
is what you're saying, right?
>> Could be.
>> All right, bring us in a little bit.
Your keynote, what were you looking to share?
You know, some of the key points.
>> Yeah, I think in the talks that I've given at
Serverlessconf, they tend to be as much as I am
enthusiastic about Serverless, fully bodying,
I try and pull us back a little bit to say,
"What are we still missing?
"What's not here yet?
"Where do we need to go?"
And so I had some frowny face emoji
in my talk about event driven programming,
event driven Serverless, and Serverless without
event driven programming.
Now we're still, you know, we have areas to improve
in each one of those.
And then that transitioned really into,
"How do we start bringing in people who
"are just starting into Serverless?"
Larger organizations, more traditional architectures,
and people who are experienced with that,
and understand traditional architectures well.
How do we get them on board with Serverless?
And so that starts with just the gateway drug,
which is infrastructure automation at the edges
of their application, taking scripts that
they run from developer machines with Cron jobs,
and moving those into a function that's triggered
by some cloud event.
And then from there, starting to bring them over
in terms of you can reduce your costs
by eliminating idle resources.
You can start to simplify and strengthen by
refactoring some of that.
And then once you really get them thinking about,
"Oh, this is really working for the things
"that we're doing."
New features will start to be developed.
Serverless native or event driven native.
And then sort of at the end of the talk,
the key is that because Serverless architectures
look different from traditional architectures,
there's something called Conway's law that says,
"The design of your application will follow
"the communication patterns in your organization."
>> Stu: Right.
>> And so you have to sort of flip that around to say,
"Well if our design is changing, then we have
"to make our organization change as well."
>> Right, does that mean we're going to have,
micro-employees you know?
Instead of micro services we have, you know,
employees that we hire them, and then we
fire them pretty quick when we don't need them, or?
>> I hope not. >> Yeah.
>> I hope not. >> (crosstalk) that that's
the part time, the uber's >> Yes.
>> nation of the workforce. >> Yes.
That would be, I think an inefficient way
of going about it. >> Yeah.
>> But I think we do need to reset expectations
around what we have control over, and what we don't,
because when you're on a traditional
architecture with servers, you can reach in
and fix problems that you have.
And recognizing that when you're running on
functions as a service platform, and using managed services,
that when the provider has some sort of incident,
you're out of control of that.
It's a very uncomfortable place to be
of not being in control of your own destiny,
even though when you look at the big picture,
that's going to happen less often,
then if you were doing it yourself.
>> Stu: Yeah.
>> And so that's making sure that the mindset
inside the organization, and the way that
people communicate, is appropriately tuned
to that sort of new paradigm.
>> Okay, yeah.
Ben, some of those frowny faces, what are things
that the community is working on that you're hopeful for?
What are some of the areas that
we need for the maturation of this space?
>> Yeah, I think something that I talked about
previously that's coming around, is monitoring.
So there's much more tools out there to monitor
the infrastructure to know what's going on
inside these functions and these managed services.
And there's now some security analysis tools
that are coming out, that some of these
people are present here.
And that was a big aspect that I've harped on
for a long time of...
We have a lot of mature traditional tools, that
will do network analysis of your servers.
Well it's like, "I don't have any servers."
And those vendors then say, "Well, we can't help you."
And there's static code analysis vendors
who say we look at your whole application,
and the flows inside it.
And we say, well most of my application exists
outside of code that I've written.
I just write little bits, that glue it together
in the way that my business works.
And they say, "Oh, well we can't help you."
>> Yeah.
It reminds me, I think you know for so many years,
people were really excited about how they could
build their infrastructure.
>> Yeah. >> And now they look
to environments, well I can get out of that.
So it caught my eye.
You know, you put out on twitter, said
"Maybe we need to have, you know, my next
talk will be, "Work dumber not harder."
Maybe explain that a little bit.
>> Yeah, so I think, >> Yeah.
>> I've been thinking about, you know,
with some of the talks here about how it's
not building it yourself.
That in some ways, there's not invented here syndrome.
And we kind of want to go a little bit down
the road of invented here syndrome,
of if you're building something that is not
business logic, you're probably ideally thinking,
"Maybe I shouldn't be doing this."
So turning it into, I don't want to have to be clever
in setting up my architecture, because being clever
and like writing, it's always interesting to do, right?
When you're developing, you're solving a
computer science problem.
But often that mean you're not delivering business value.
And so, in Paul Johnson's talk, he was talking
about the kind of people he looks like.
What the kind of people he looks for, look like.
>> Yeah.
>> And he was saying, you know, "It's people
"who want to get stuff out the door.
"And who think about good enough."
And I think that's really the thing of,
how do we, when the people you hire are people
who just want to ship features, they're going to say,
"I can pull together services to do that
"without having to actually solve any hard problems."
And that means that you're delivering value,
and you're operating more in your business space
then in a technology space."
>> All right, Ben I want to give you the final word.
>> Thank you. >> You know, only 460 people
here, which is good growth for the show,
but a lot of people out there that are
still learning about Serverless, what tips
do you give them?
You know, first steps to get involved, get
involved with the community, (mumbles) some
early wins they can have?
>> I think there's a couple of things.
There is training out there, there's blogs.
There's twitter.
Ask questions.
You know, ping me on twitter if you wonder about something.
And there's a Serverless slack that's very active,
and if you ask basically anybody, the link
is floating around.
>> All right, well Ben Kehoe, thanks so much.
Great to meet you, and thanks for sharing
in this community. >> Yeah, thanks for having me.
>> And our community, I'm Stu Miniman
and thanks for watching The Cube.
(upbeat, exciting music bumper)