>> 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 you're watching theCUBE's coverage of Serverlessconf 2018 here in San Francisco at the Regency ballroom. I'm happy to welcome back to the program Simon Wardley, who's a researcher with the Leading Edge Forum, I spoke with you last year at Serverless in New York City, and thanks for joining me again here in San Francisco. >> Absolute pleasure, nice to be back. >> Alright, so many things have changed, Simon, we talked off camera and we're not going into it, your wardrobe stays consistent >> Always. >> But, you know, technology tends to change pretty fast these days. >> Mhmm. >> You do a lot of predictions and I'm curious starting out when you think about timelines and predictions, how do you deal with the pace of change, and put things out, I have my CTOs, like well, if I put a 10 year forecast down there, I can be off on some of the twists and curves, and kind of hit closer to the mark. Give us some of your thoughts as to how you look out and think about things when we know it's changing really fast. >> Okay, okay, so there are a number of different comments in there, one about how do you do predictions, one about the speed of change, okay? So I'm going to start off with the fact that one of the things I use is maps. And maps are based on a couple of characteristics. Any map needs an anchor, in the case of the maps of business that I do, that's the user, and often the business, and often regulators. You also need movement and position in a map. So position's relative to the anchor, so a geographical map, if you've got a compass then this piece is north, south, east or west of that. In the sort of maps that I do, it's the value chain which gives you position relative to the user or the business at the top. Movement, in a geographical map you have consistency of movement, so if I go, I don't know, north from England I end up in Scotland, so you have the same thing with a business map, but that evolution is described, sorry, that movement is described by evolution. So what you have is the genesis of novel and new activities custom-build examples, products and rental services, commodity and utility services, and that's driven by supply and demand competition. Now, that evolution axis, in order to create it, you have to abolish time. So one of the problems when you look at a map is there is no easy use of time in a map. You can have a general direction and then you have to use weak signals to get an idea of when something is likely to happen. So for example if I take nuts and bolts, they took 2,000 years to go from genesis to commodity, electricity was 1,400 years from genesis to commodity, utility, computing 80 years. So, there are weak signals that you can use to identify roughly when something is going to transition, particularly between stages like product to a commodity. Product-product substitution very unpredictable, genesis of novel acts, you can usually say when stuff might appear, but not what is going to appear because in that space it's actually what we call the uncharted, the unexplored space. So, one of the problems is time is an extremely difficult thing to predict without the use of weak signals. The second thing is the pace of change. Because what happens is components evolve, and when we see them shift from product to more commodity and utility, we often see a big change in the value chains that that impacts. And you can get multiple components evolving, and they overlap, and so we feel that the pace is very very fast, despite the fact that it actually takes about 30 to 50 years to go from genesis to the point of industrialization, becoming a commodity, and then about 10 to 15 years for that to actually happen. So if you look at something like machine learning, we can start with it back in the '70s, 3D printing 1968, the Battelle Institute, all of this stuff, virtual reality back in the 1960s as well. So the problem is, one, time's very difficult. The only way to effectively manage time is to use weak signals, it's probability. The second thing is the pace of change is confusing because what we're seeing is overlapping points of industrialization like for example cloud, and what's going here with Serverless. That doesn't actually imply that things are rapidly changing because you've actually got this overlapping pattern. Does that make sense? >> Yes, it does actually. >> Perfect. >> Because you think, we have in hindsight we always think that things happen a lot faster but-- >> Yeah. >> it's funny, infrastructure space when I talk to some of the people that I came up with, they were like oh yeah, come on, we did this in mainframe decades ago. and now we're trying again, we're trying again. Things like-- >> Containers, for example, you've got LXE before that, and we had Solaris Zones before that, so it's all sort of like, interconnected together. >> Okay, so tie this into Serverless for us. >> Okay. >> You were a rather big proponent of Platform as a Service, is this a continuation of us trying to get that abstraction of the application or is it something else? What is the map we are on, and, you know, help us connect things like PaaS and Serverless and that space. >> So back in 2005, the company I ran, we mapped out our value chain, and we realized that compute was shifting from product to utility. Now that had a number of impacts. A, that shift from product to utility tends to be exponential, people have inertia due to past practice, you see a co-evolution of practice, around the changing characteristic. It's normally to do with something called MTTR, mean time to recovery changes. And so you see rapid efficiency, rapid speed of development, being able to build new sources, new areas of value. So that happened with infrastructure, and we also knew it was going to happen with platform, which is why we built something called Zymkey, which was a code execution environment, totally stateless, event-driven, utility billing, and billing to the function, and that was basically a shift of the code execution platform from a product, lamp.net stack, to a much more utility form. Now we were way too early, way too early, because the educational barriers to get people into this idea of building with functions, functional program, much more declarative environment, was really different, I mean when Amazon launched EC2 in 2006, that was a big enough shock for everybody else, and now of course, now we're in 2014, Lambda represents that shift, and the timing's much much better. Now the impact of the shift is not only efficiency and speed of development of new things, and being able to explore new sources of value, but also a change of practice, and in the past, change of practice created DevOps, this is likely to create a new type of practice. For us, we've also got inertia to change because of pre-existing systems and governance and ways of working, sunk capital, physical capital, social capital. So it's all perfectly normal. So in terms of being able to predict and far-predict these types of future, well for me, actually, Lambda's my past, because that's where we were. It's just the timing was wrong, and so when it came out, it was like for me, it was like, this is really powerful stuff and the timing is much, and we're seeing it here, it's now really starting to grow. >> Alright, you've poked a little bit at some of the container discussions going on in the industry, you know, I look at the ecosystem here, and of course AWS is the big player, but there's lots of other Serverless out there. There's discussion of Multicloud. >> Yeah. >> How does things like Kubernetes, and there was this new term canative, or cane-native project, that was just announced, and we're all, don't expect that you've dug in too deeply, but, if you look at containers and Kubernetes, and Serverless, do these combine, intersect, fight? How do you see this playing out? >> So when I look at the map, you know, you've got the code execution layer, the framework which has now become more of a utility, and that's what we call platform. The problem is, is people will application to containers, and therefore describe their environments as application-container platforms, and the platform term became really messy, basically meant everything, okay. But if we break it down into code execution, this is what we call frameworks, this is becoming utility, this is where things like Lambda is, underneath that, are all these components like operating systems, and containers, and container management, Kubernetes type systems. So if you now look at the value chain, the focus is on building applications, and those applications need functions, and then lower down the stack are all these other components. And that will tend to become less visible over time. It's a bit like your toaster. I mean, your toaster contains nuts and bolts and all sorts of things, do you care? Have you ever noticed? Have you ever broken one open and had a look? >> Only if something's not working right. >> (laughs) Only if something, maybe, a lot of people these days wouldn't even go that far, they'd just go and buy themselves a new toaster. The point is, what happens is, as layers industrialize, the lower-order systems become much less visible. So, containers, I'm a big fan of containers. I know Solomon and the stuff in Docker, and I take the view that they are an important but invisible subsystem, and the same with container management and things like containers. The focus has got to be on the code execution. Now when you talk about canative, I've go to say I was really excited with Google Next last week, with their announcements like functions going GA, I thought that was really good. >> We've been hoping that it would have happened last year. >> Yeah exactly, I wanted this before, but I'm really pleased they've got functions coming out GA. There was some really interesting stuff around SDO, and there was the GRPC stuff which is, sort of, I think a hidden gem. In terms of the canative stuff, really interesting stuff there in terms of demos, not something I've played with, I'm sort of waiting for them to come out with canative as a service, rather than, you know, having to build your own. I think there was a lot of good and interesting stuff. The only criticism I would have was the emphasis wasn't so much on basically, serverless code execution building, it was too much focused on the lower end systems, but the announcements are good. Have I played with canative? No, I've just gone along and seen it. >> So Simon, the last question I have for you is, we spoke a year ago today, what are you excited about that's matured? What are you still looking for in this space, to really make the kind of vision you've been seeing for a while become reality, and allow serverless to dominate? >> So, when you get a shift from, say, product to utility, you get this co-evolution of practice, this practice is always novel and new. It starts to emerge, and gets better over time. The area that I think we're going to see that practice is the combining of finance and development, and so when you're running your application, and your application consists of many different functions, it's being able to look at the capital flow through your application, because that gives you hints on things like what should I refactor? Refactoring's never really had financial value. By exposing the cost per function and looking at capital flow, it's suddenly does. So, what I'm really interested in is the new management practices, the new tooling around observing capital flow, monitoring, managing capital flow, refactoring around that space and building new business models. And so there's a couple of companies here with a couple of interesting tools, it's not quite there yet, but it's emerging. >> Well, Simon Wardley, really appreciate you. >> Oh, it's a delight! >> Mapping out the space a little bit, to understand where things have been going. >> Absolute pleasure! >> And thank you so much, for watching as always, theCUBE. (upbeat music)

>> Narrator: 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 in New York City, really excited to have on the program one of the keynote speakers and a first time guest on theCUBE, it's someone I've know through the interwebs and have read his stuff for many years, Simon Wardley who's a researcher with a leading edge firm, Simon, great to see you. Thanks so much for joining us. >> Thank you ever so much for inviting me. It's a delight to be here. >> Alright, so my understanding is thanks to this event, you've reached a lifelong career goal. You're now a Sith Lord? (laughing) >> Well, somebody basically took a quote of mine and put it on a Star Wars poster with The Empire at the bottom, so yes, it is absolutely there you are, I am a Sith Lord, so delightful. >> The quote was that Serverless will just fundamentally change the architecture of how we build things. Something along those lines, I believe. >> Absolutely, yes. >> Alright, so let's start there. There are so many, come on, we all got really excited when containers came out. We're going to talk to John Willis >> You did. (laughing) >> We're going to talk about unikernels. The industry as a whole, there's frothiness and buzz >> Okay. >> So Serverless, you know, how's it different? How's it the same? Why's it so important from your standpoint? >> So, really good questions. So, to explain that question, we have to start off with a subject that is dear to my heart which is mapping. So when we look at the value chain of any organization, the components in that value chain are evolving and they evolve from the genesis, the novel and new to custom built examples and eventually products and rental services and then commodity and utility services. And that process is driven by supply and demand competition. It happens not only to activities, but to practice and data, but we give them different terms. They have all of the same characteristics as when they evolve. Now, when you look at that evolving environment, what you discover is there are two basic forms of disruption. There is the highly unpredictable form, which either occurs due to the appearance of something novel and new, which we don't know what it's going to impact or to product substitution. So that's the Nokia versus Apple, sort of battle, you don't know which way it's going to go until after the battle. And there is a second form of disruption, which is much more anticipatable or predictable and that is the product to utility change. So we know that when things evolve from product to utility we're going to see a rapid period of change and then there's a punctuated equilibrium. Explotion of higher order systems. We're going to see co-evolution of practice, disruption of past companies stuck behind inertia barriers. Yes it's going to be a bad efficiency, no we're not going to save any money 'cause we're just going to do more stuff with it and we're going to have all these new things as well. And we can anticipate that in advance. So when you start looking at value chains of organization, it's always the shift from product to commodity and utility which makes the big transformation in industry. And so one of them was compute. Shifting from products, as in servers, to utility as in cloud. Unfortunately dreadful term, cloud, an awful word, you know it's not a wispy thing up in the sky, it is something very specific, the shift from compute to utility. >> Would you put virtualization along that continuum? >> Okay, so virtualization was one of the underlying components, which actually helped with that happen. >> Yes. >> And so you've also got the explosion of practices around that co-evolution of practice, things like DevOps. Well, the same transition is now happening in the platform space. So, we're moving away from a product stack, things like, LAMP and .NET, to much more utility-based code execution environments. And that's what we're getting with Lambda. And we're going to see an explosion of new things built on top, inertia barriers, companies stuck behind, they'll die off, It'll be a rapid change punctuated equilibrium. You'll get all sorts of new things built. So we're going through that big transformation. Now, these transformations have been going on for about 300 years, some of them impact micro scale economics, some macro, the biggest we call ages. And that all depends upon how widespread that component is in other value chains, so when we're talking about software, we're talking about a component which is in almost all other value chains, it's shifting from product to utility, massive change, highly predictable. This is what Serverless is about. So, will it change everything? Absolutely it will. >> Alright, so Simon, I'm wondering, if you've mapped out for Serverless, where's the land of economic expection, the land of happiness and the land of despair? (laughing) >> Well, okay, happiness, despair and expectation? >> Yes. >> Okay interesting one. So the land of despair will be getting stuck behind the inertia barriers, dismissing it, saying it's not going to impact, it's not going to impact, no, no, because there's a punctuated equilibrium, it'll surprise you because it's an exponential growth, so you'll think you've got loads and loads of time and 10 years from now, you're like, be panicking, oh my gosh, it's impacting, I can't get the skills for people to help me do the transformation. My entire industry and business model is starting to disappear, so that is the land of despair that's coming to people, that's easy to defend against because most people can't see the environment. They're going to just walk straight into that one. The land of happiness. Well, obviously other than being the utility providers who'll be extremely happy about the growth of their industry, another area of happiness will be some of the novel and new things built on top. So, we're bound to see the, sort, of, one person, two person company who builds a fuction which is sold through something like the marketplace and everybody uses and they sell it for a billion. So, we'll get the two person billion dollar company and I'm sure that will make them delightfully happy. So, that's despair, happiness, also inflated expectations. So one of the big lies will be, Serverless is going to save me money in terms of reducing my IT budget. I'm afraid not. This is Jevons Paradox, this is being going on since 1865. All that's going to happen is yes, it becomes more efficient but we'll do more stuff because we're in competition so we'll spend exactly the same as we've always done, but just doing vastly more. But none the less, loads of consultants will write reports about how it will save you money and lots of people will be disappointed. >> I want to poke at that for a second. (laughing) I don't disagree with Javons Paradox when it comes to power, but example, say you know, our host for this event, A Cloud Guru. >> Yeah. >> They're priced to deliver per user is way lower than if they'd have done this the traditional way and I've heard many examples here at the show already where they've said, oh if I had built it this way, you know, it's now an order of magnitude less dollars, so. >> Let's forget order of mag, let's go many orders of magnitude. So from now to say the 1980s, for a thousand dollars, I can get a million times more compute resource than I could back then. Has my IT budget reduced a million fold during that time? And the answer is >> Yeah. >> What, my IT budget has reduced a million fold? >> No, no, no my IT budget has not reduced a million fold. >> Not at all, because we've just ended up doing vastly more stuff. >> Yeah, yeah. >> So the point is, yes. >> Budgets are always flat, yes. >> So the point is yes, we will be able to do the same things but more efficiently, but your IT budget doesn't reduce because we end up doing more things. So we're in competition, say, you and me and say you evolve, you use these environments you don't reduce your IT spending, you do more things, I'm now having to spend more and more just to try and keep up with you. So eventually I'm forced to adopt to that new world. So what happens is the individual acts become more efficient, but because we do more, we don't save anything. >> You know, want to look at kind of, maps versus strategy. >> Okay. >> I guess one of the things, if I'm talking to the typical Enterprise CIO or Board and they say, oh, well, a year ago I heard about Serverless, or today I heard about Serverless, you know, the strategy is going to change greatly because this is changing so rapidly, how do you help companies understand when things are changing so fast, how do I set a strategy for today? How long do I keep it? How often do I revisit it? >> So, if you map an environment, like all maps, they're dynamic, so you're constantly adapting and changing them as the environment is changing. So, when you look at, you have the purpose of your company, you have the landscape you're operating in, there are a number of climatic patents, about 30 of them, which impact that environment, will change it, so you need to understand those. Then there's sort of university useful patents known as doctrine, then there's game play. Now, for most organizations, because they cannot see the environment, they cannot distinguish, or may just be completely oblivious to any of this, so when they were talking about change, if I look at how things evolve from genesis, custom built product commodity, most organizations will go genesis, that's an innovation, every custom built feature differentiation of a product's an innovation, every shift in product to utility is an innovation, so all they see is innovation, innovation, innovation. And therefore, it's very easy to get sucked in to one size fits all methods work. One size innovation programs, where in fact, the genesis you would be using something like a lightweight XP, the product development, much more lean enterprise, so SCRUM and MVP and the utility is much more outsourcing or Six Sigma. So you should be using multiple techniques and multiple methods and most organizations aren't in that position. And if they're not in that position, of being able to see the environment, it's difficult to see where to attack, it's difficult to understand why here over there, it's difficult to manipulate the market. So, what happens is most organizations work on gut feel, whatever's popular in HPR and just act. And you can call that strategy if you wish. >> Alright, so I wish we could talk for another couple of hours, but want to give you the final take away >> Yes. >> Serverless today, how should people be thinking about it and what should they be looking for over the next six to 12 months in this space? >> So, the key thing about Serverless is we're seeing a shift from platform from product to utility, so you should be developing skills in that space. And we're seeing co-evolution of practice. By that, we mean there is a new set of practices combining finance and development together. What those practices are, we don't know yet. You have to experiment and explore. That's why attending events and being involved in building stuff will help you discover those practices. So today if your company, well it depends on your position, so if you're a company which is behind the game, you, say, haven't gone into infractructure as a service, you're not doing DevOps, you're own people are resistant to this change cause the other vendors say you're going to lose their jobs and blah, then rather then embarking on a five to seven year program, 'cause that's how long it will take to do that, you should move up the stack and start with Serverless and learning those practices. 'Cause no one knows them well, so you can take your people who've got inertia and re-train them in that space overcoming that inertia and give yourself a path forward. So, depends on your position, but I think most companies should be experimenting in this space. >> Alright, well Simon Wardley, it's a pleasure to catch up with you today. >> Delight. >> Hope to have you back on theCUBE at another event soon. Thank you so much for watching theCUBE.

>> Narrator: 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 Serverless Conference in New York City, Hell's Kitchen. Happy to have with me, first time guest on the program Sam Kroonenburg, we had your brother on the program at the AWS Summit not far from here, at the Javits Center in New York City, but you're also one of the co-founders its the two brothers for A Cloud Guru. Thanks so much for joining me, and thank you for allowing us to come get some phenomenal content here. >> Yeah, no problem. Thank you for coming for the conference today. >> Alright, so Sam, take me back, you know, we talked to your brother a little bit about, well it was an interesting story, he said actually I got turned down for a job from Amazon and ended up creating a training company. But you built this and you built it on Serverless. >> I did yeah. >> So walk us through a little bit the thought process, the timing, you know, aren't you a little bit ahead of your time on that? >> Yeah, it was mid 2015, it was a strange time. We decided we wanted to build this school, this online learning platform, but the challenge we had was that we didn't have a lot of time, we both had families, kids, you know, mortgages, financial commitments. Basically I had four weeks. I had four weeks of leave owing to me, from my employer at the time. My wife and I had been planning this big family holiday with the kids for years and we were about to take it, and I remember having this phone call with Ryan and we were talking about how there were these people taking these online courses and they were really liking them. And we thought, what if we could build this school to teach people cloud computing. It was such a buzz and we just thought, there's something in this. But the challenge was the timing. I remember my wife turned to me and she said, "Look you've got to do it, we'll cancel the holiday, "take the four weeks and give it a try." So that's what we did, we actually flew down to live with Aaron, my in-laws and help look after the kids and I locked myself in a bedroom for four weeks and tried to build an online school. And that was there was no epiphany to go Serverless there was no grand plan. It was, we had a constraint, which was time. I had no time to build this thing. And so ended up using some of the latest technologies like AWS Lambda, API Gateway, a whole bunch of Serverless technologies because I saw that they would help me build this faster. And I could get something to market in the four weeks that I had. I actually spent the first couple of days trying to skin and configure Moodle, the learning management system and I tore my hair out and yeah, ended up putting this thing together with Serverless technologies. >> Ryan just walked by-- >> Oh, there he is. >> It's a llama unicorn with a cat or something like that. >> I'm going to put in the background. >> In the back of our video. Sam, what's your brother doing here? >> He's always trying to troll me. >> So talk to us, you know one of the things the maturation, kind of the speed of change in the industry for new technologies is just so fast these days. Take us through from those early days to you know Serverless today. What's your experience been? What would you say to people that look at this technology? >> I think it's a lot easier to get into now than it was two years ago. The ecosystem has grown around it, the core technologies are pretty much the same as they were two years ago, function as a service, execute functions in the cloud very similar, but the tooling around it, the ecosystem around it has grown. There's great deployment tools, orchestration systems that have come along. It's a lot easier to just get in now and early on, when we started we had to roll a lot of things ourselves, which took a lot of time, and that's what you're trying to stop, is losing time. Yeah, so there's that and the community has really grown, there's a lot of support in the community now. >> So if you had to do it all over, you could have done it in a weekend, rather than the four weeks. >> Yeah, instead of the four weeks. >> Yeah, I mean what's-- >> That's the interesting thing about what happened to us, we would not exist, our business would not exist if it wasn't for Serverless technologies. I literally couldn't, we could not have, built that school. It's not like it was the most amazing school when we launched it, but it was enough. It was just enough to get people using it, to get to market, to start to build a business around it. >> Alright, talk to me about this event. So, its the 5th Serverlessconf, not unheard of a company that does training to get involved with physical events, 'cause you bring them together, you know, what's the thought process, talk to us a little bit about that journey and this event itself. >> Yeah, I mean, a lot of this is organic for us. We built, it was early last year, you know we're part of the Serverless communities, a lot of pioneering going on here, a lot of people facing the same challenges. And we thought, well there's no event to bring all of these people together. And there's a lot of very fast pace of change here, a lot of rapid ideation and new technologies. Let's bring everyone together and see what we can do. That's what we did with Serverlessconf. We've never run a conference before, we just hired a warehouse in Brooklyn, a bunch of Australians and British guys coming over and we just invited a bunch of people on Twitter and 250 people turned out to the first one. It just got bigger and bigger from there. So this is actually the 5th Serverlessconf now. >> Well, its a hot week again, so we appreciate that the air conditioning works at this one. >> Yes, we have air conditioning at this one. >> 460 people here, you brought in some great speakers, we had a number of them on our program this week, speak to us, I mean you've got sponsors here, you've got good speakers, give us some of the highlights. >> We've got all of the main Cloud vendors are here, Google, IBM, Microsoft, Amazon and it's actually the product teams who build this stuff. That's what I love about this event, it's actually the people who build it. It's vendor neutral, it's really cool. You get great thought leaders from the community, Simon Wardley was a highlight this morning, his talk on Value Chain Mapping and Strategy was really interesting. Randall Hunt from AWS X Space X, talking about the continuous integration process when building rockets. Space X was absolutely fascinating and what bugs in production mean when you're building a rocket. It means the rocket blows up. Really interesting variety of talks from those tooling providers, companies like us who are just building on Serverless and then Serverless tooling companies and vendors. Really fascinating. >> Alright, Sam what should we be looking for in the future from Serverless and from A Cloud Guru? >> We're going to be doing a whole lot more Serverless content. You're going to see a lot of really interesting new content through our site, a lot of teaching on Serverless, we're going to be doing more Serverless Conferences. You'll see a lot from us, not just us, but from the wider community who come to the conference, who we know well, a lot of the experts, we're going to be doing a lot of work with those people. >> Well Sam Kroonenburg, really appreciate you joining us, appreciate the media sponsorship to allow theCube to come get some great content and share it with our communities, hope to see you at many more events in the future. >> Thank you for coming. >> Thank you so much. Sam Kroonenburg, I'm Stu Miniman. Thank you for watching theCUBE. (upbeat music)

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