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