 from the Regency Center in San Francisco, it's theCUBE. Covering Serverless Conf San Francisco 2018, brought to you by SiliconANGLE Media. I'm Stu Miniman and you're watching theCUBE's coverage of Serverless Conf 2018 here in San Francisco at the Regency ballroom. Happy to welcome back to the program, Simon Wardley, who's a researcher with the leading edge forum. Spoke with you last year at Serverless in New York City and thanks for joining me again here in San Francisco. Absolutely pleasure, nice to be back. All right, so many things have changed, Simon. We've been talking off camera and we're not going into it. Your wardrobe stays consistent. Always. Technology tends to change pretty fast these days. 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? My CTO is like, well, if I put a 10-year forecast down there, I can be off on some of the twist and curve 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 positions 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-built examples, products and rental services, commodity and utility services. And that's driven by supply and demand competition. Now, that evolution access in order to create it, you have to abolish time. So one of the problems with 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 or 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 is 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 ship and product to say 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 Batille 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 on 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? Perfect. It does actually because you think we have in hindsight we always think that things happen a lot faster but it's funny. Infrastructure space, when I talked to some of the people that I came up with, they were like, oh, yeah, come on, we did this in the mainframe decades ago and now we're trying again, we're trying again, things like, yeah. Containers, for example. We've got LXC before that and we had Solaris zones before that. So it's all sort of interconnected together. Okay, so tie this into serverless for us. 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 and was it something else? What is the map we are on and help us connect things like paths 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. 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 characteristics. It's normally to do with something called MTTR, Mean Time to Recovery changes. And so you see rapid efficiency, rapid speed of development and being able to build new sources of 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 Zimki 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 then the past change of practice created DevOps. This is likely to create a new type of practice. But of course 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. All right, you've poked a little bit at some of the container discussions going on in the industry. 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 multi-cloud and how does things like Kubernetes and there was this new term, Knative or Knative project that was just announced and we're all, don't expect that you've dug into it too deeply, but if you look at kind of containers and Kubernetes and serverless to these combined intersects, fights, how do you see this playing out? So when I look at the map, you've got the code execution layer, the framework which has now become more of a utility and that's what we call platform. So the problem is people built application containers and therefore described their environments as application container platforms and the platform term became really messing, basically meant everything. 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 or 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. Only if something, maybe. Well, a lot of people these days wouldn't even go that far. They're just going by 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 plus 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 Knative, I've got 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 Istio and there was the GRPC stuff, which is sort of, I think, a hidden gem in terms of the Knative 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 Knative as a service rather than 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. There was too much focus on the lower end systems, but the announcements were good. Have I played with Knative? No, I've just gone along and seen it. So Simon, last question I have for you is we spoke a year ago to today. What are you excited about that's matured? What are you still looking for in this space to really make the vision that 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 and 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 suddenly does. So what I'm really interested in is the sort of 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. Simon Wordly, really appreciate you helping us to map out the space a little bit, understand where things have been going. Absolutely pleasure. And thank you so much for watching as always. The Cube.