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