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