Episode #110: Mapping the Inevitability of Serverless with Simon Wardley

September 13, 2021 • 68 minutes

On this episode, Jeremy and Rebecca chat with Simon Wardley about the advantages of using maps to gain situational awareness, how the evolution of utilities lets us build things more quickly, why inertia is delaying the inevitable, and so much more.

Simon Wardley is a researcher for the Leading Edge Forum focused on the intersection of IT strategy and new technologies. Simon is a seasoned executive who has spent the last 15 years defining future IT strategies for companies in the FMCG, retail, and IT industries—from Canon’s early leadership in the cloud-computing space in 2005 to Ubuntu’s recent dominance as the top cloud operating system. As a geneticist with a love of mathematics and a fascination for economics, Simon has always found himself dealing with complex systems, whether in behavioral patterns, the environmental risks of chemical pollution, developing novel computer systems, or managing companies. He is a passionate advocate and researcher in the fields of open source, commoditization, innovation, organizational structure, and cybernetics.

Simon’s most recent published research, “Clash of the Titans: Can China Dethrone Silicon Valley?,” assesses the high-tech challenge from China and what this means to the future of global technology industry competition. His previous research covers topics including the nature of technological and business change over the next 20 years, value chain mapping, strategies for an increasingly open economy, Web 2.0, and a lifecycle approach to cloud computing. Simon is a regular presenter at conferences worldwide and has been voted one of the UK’s top 50 most influential people in IT in Computer Weekly’s 2011 and 2012 polls.

Twitter: https://twitter.com/swardley
Medium: https://swardley.medium.com
Blog: https://blog.gardeviance.org
Wardley Maps (free online book): https://medium.com/wardleymaps

Simon's slides discussed during the podcast


Jeremy: Hi everyone, I'm Jeremy Daly.

Rebecca: And I'm Rebecca Mashburn.

Jeremy: And this is Serverless Chats. Welcome back, Rebecca. How are you doing?

Rebecca: It's Serverless Chats, I'm doing good. That's all I've got to say, right?

Jeremy: What have you been up to lately? Did you have an interesting weekend?

Rebecca: I did. It's wedding season and I used to be a florist. So I did flowers for one wedding until about midnight and then got on a plane at 5:00 AM to go to another wedding. So love is in the air and it's beautiful.

Jeremy: That's amazing. Well, what's not in the air at my house are kids because both of my teenage daughters are now in school at least for now. We'll see how that changes with the coronavirus and whatnot. So I have some peace and quiet at home. So thought this would be a great opportunity for us to invite a very special guest on today, I'm a big fan. He is a researcher and a giant fan of maps, he loves maps. Simon Wardley, hey Simon. Thanks for joining us.

Simon: Absolute pleasure, complete delight to be here and gosh, opening conversation talking about family, talking about flowers. I'm just planting a meadow at the back of my house so I'm totally exhausted this week having cut it all down, raking it up, putting all the seeds down but anyway, fantastic. Lovely to be here.

Rebecca: Oh man, but your hands in the earth is so nice, I just love having dirt in my fingernails. It's so good.

Simon: It's Serverless Chats, can we just ignore serverless because that's just been done.

Rebecca: Let's just talk about flowers.

Simon: Lets get on with it.

Jeremy: Whatever you want, Simon.

Rebecca: It's called floral chats today.

Simon: Sounds good to me.

Jeremy: So besides planting a meadow which sounds beautiful, what else have you been up to over the last year or so?

Simon: The last two weeks, I've been shooting, canoeing, kayaking, mountain climbing, hot air ballooning, quad biking and lots of eight mile hikes. I've had a two week holiday at home and archery and a whole bunch of other things. But prior to that, I've been very boring. I've been researching-

Jeremy: Those are very boring, maybe we can spice it up a little bit here and talk about something interesting.

Simon: Okay. So previous to that, I've spent the last year basically looking into industrialization technology and the reason why that's interesting is it's always the industrialization of technology that changes organizational behavior. So it's cloud compute goes from a product to a utility, more industrialization, get new behaviors, we call them DevOps. Serverless, the runtime goes from product to utility, you're getting new set of practices, FinOps. This is a very old pattern. So I've been looking at that in areas like space, retail, a whole bunch of areas and there's a common set of changes which are all carrying because of basically things like social media and more open data. And so we're heading into a world which is much more distributed, leaderless leadership, all this sort of good stuff as well. So that's what I've been doing, exciting stuff. Well, I find it exciting but then I'm a researcher who likes maps.

Jeremy: Right. And speaking about maps. So I think most people know about Wardley Maps and if they don't, they absolutely have to. Now I was chatting with Rebecca about this before, I keep kicking myself because I didn't take the time to learn maps and every time I see some great article written about Wardley Mapping and how they came to this conclusion and the theory behind it and so forth, I'm like, "Why didn't I just take the time to learn that?" So besides me or for other holdouts like me, could you just sum up or give us a quick overview of what are Wardley Maps?

Simon: Gosh. Well first of all, they're very visual. So really difficult to do it in words. So when we talk about maps in business, most things we have in business are not actually maps, they're graphs. The distinction between a graph and a map, very, very simple. In a map, space has meaning. So if you take something like a mind map and you leave pieces around but keep the connections the same, the meaning hasn't changed. That's because it's a graph, not a map. If you take a geographical map and you take Australia and leave it next to England, then of course the meaning has changed and that's because it is a map. So I set out many, many years ago, to create a map for my business because I would have to be the CEO of a company. I was completely clueless, didn't know what I was doing. Revenue was going up, profitability going up, I was making it up. I was really worried that eventually, people would discover I was completely clueless. I stumbled upon this idea that I needed a map of the environment. And so that's what I built.

Simon: It's pretty simple, you start off with users, you understand their needs, you understand the chain of components that make up their needs and then each of those components are a form of capital and they're evolving through a common pattern. You start of with a genesis, custom built products and commodities. And so you can simply position them to where they are, how evolved they are and that creates your map. Now again, really difficult to explain in words but it turns out once you do this-

Jeremy: You're doing a wonderful job, so keep on going.

Simon: Oh, thank you. It turns out there's a whole bunch of common patterns you start to discover. There's about 30 common economic patterns or climatic patterns. So these are the rules of the game, 40 different forms of principles and ways of operating, about a 100 forms of gameplay and people are completely oblivious to this. So what does it mean in practice? I used to run strategy for a company called Ubuntu. We were 2% to 3% of the operating system market up against Red Hat and Microsoft. We spent half a million to 18 months and took 70% of all cloud computing. So we went from two to three to 70%, cost us half a million, took 18 months and that was because we mapped out the environment and we knew where to attack.

Simon: So think of it like you've got two... I hate military analogies because everybody thinks kinetic warfare and the whole thing but it doesn't have to be that. But imagine you've got two generals, two military commanders battling it out and one of them has got a map and the other one hasn't. You can tell who's going to lose pretty quickly and unfortunately in most of our organizations, we run on what are called stories. Stories, lots of problems with them. First of all, it's really difficult to challenge a story because they're highly political because you've got something called a storyteller, et cetera. They have very poor understanding of context, so you can't learn patterns from them but that's what we basically run most organizations by and that's what I used to do as well and then I had maps and then I made it all Creative Commons and then people started to use it all over the place. Wonderful stories are here and first of all, don't worry about being slow to use again.

Simon: One particular organization in the defense area, they came across mapping, they used maps. They looked at maps and they thought this was really important, we must do this and then they were very busy so they didn't and about a year later, they had a bit of a disaster and somebody went, "Oh, if only we had mapped it." So they got really excited and then they got busy and so they didn't and then they had another disaster and this went on about six or seven times before they eventually started to map and that's fairly normal. I normally say it takes about seven years to learn to map. The first six years, nine months is going, "I really must start to learn to map." And the last three months are actually mapping because it really is quite simple. So don't worry. And the other thing is these changes to management methods normally take about 30 to 50 years to spread through society. So we're only 15 years in, so you're way ahead of the majority.

Jeremy: I'm probably pushing six years now of saying I've got to learn maps. So I'm getting there, I'm almost there.

Simon: You're right on the cusp then.

Jeremy: I'm right on the cusp.

Rebecca: Yeah. So I would love to apply a real world application of this mapping that you've done and you've done it across all sorts of industries and different types of products but we're here to talk about flowers. So if we could... I'm kidding. We're here to talk about serverless. So I'm going to dive in with a serverless question in terms of mapping and how you arrived at the conclusion about the inevitability of serverless.

Simon: Okay.

Rebecca: Yeah. So I would love to see, there still seems to be a lot of skepticism around serverless but you point out in the past, that the same was true early on in cloud, right? You reference the McKinsey report, cleaning the air on cloud. Your theory was one and the McKinsey was nil. So I'm curious about what you think the reason is for what you and I'm sure Jeremy and I both agree is short sightedness in that space and how did mapping lead you there and what kind of map did you build in such a way where you're like, "Okay, now I've arrived here. Serverless is inevitable."

Simon: Okay. So do you mind if I show you a map?

Jeremy: Go right ahead.

Simon: Is that okay?

Rebecca: We would love it.

Jeremy: You can show us a map, yes.

Rebecca: Please do.

Simon: Because I remember that we're trying to do this as audio. So I will show the map and you can take the slides or whatever if you want to use them, that's great.

Jeremy: We can put them in the show notes.

Simon: Okay, super. So this is a basic map. So all maps have three common components. You've got an anchor like Magnetic North, you've got the position of pieces on a map and then you've got something called consistency of movement and it's those that give space meaning. So what we've got is that anchor, here is user. User needs an application, application needs best coding practice built on a runtime, built on an operating system, built on best architectural practice built on compute. Now each of these components are laid out on an axis of evolution from the genesis of compute started in 1943, digital compute, that's the Z3. Custom built examples like LEO Lyons electronic office products, IBM 650, eventually more and more advanced products and eventually, you get commodity utilities. So everything evolves along that axis. Practices do as well, we just give them a different term, novel, emerging, good and best.

Simon: Okay, so what you've now got is a user and you've got a value chain and as you go down the value chain, things become less visible to the user. They're still critical and each of the components evolve and if I move any of these components, it changes the meaning of this map. Now this is a map of compute roughly 2004, 2005. So compute was servers, we had best architectural practice, operating systems were not quite commodity, neither was the runtime but we had best coding practice and we built applications. Right. Now you've got the introduction. Let's go through it. There are a couple of basic patterns you learn, everything evolves. If there's supply and demand competition, doesn't matter what it is, money, penicillin, computing starts on genesis, ends up as a commodity. Right, pattern number two. Past success breeds inertia. So if we get very good at the past, we have inertia of the chain. So we built big data centers, compute becomes more of a utility, we're like "Oh, that cloud stuff is bad." Mostly because spent all this money on big data centers.

Simon: Third pattern, you get co-evolution of practice. So as things evolve, you get a change of practice. It doesn't matter whether we're talking about electricity or compute or Fordism or DevOps with compute going from product to utility, you get a change of practice and that new, emerging practice gets a new name and eventually becomes the new norm. Another pattern, efficiency enables innovation. As the underlying components become more commodity like, we build things more quickly. So bricks to build houses are better than if you've got standard bricks and standard pipes, it's faster to build a house and higher order systems create new sources of value or worth. So these are a couple of basic patterns. Now I use this to work out where to invest.

Simon: So as I said, I was running strategy for Ubuntu. So we could use the map in 2008 and say, look, compute was going to utility, we need to attack there. We need to attack the emerging practice, we don't know what it's going to be called. It turned out it was going to be called DevOps by Andy and Patrick. We know we're going to get new needs, so we need to attack there. We can also invest in building applications on top but one area we want to get out of is best architectural practice for compute as a product, data centers, all that sort of stuff. That's where we want to escape from and this is a simplified version. We could use the map to attack the space, pretty basic and that's how we went from 2% to 3%, 70% of all cloud. So we're up against Microsoft, Red Hat, they've got all the money, they've got all the people, we've got a map. Bang, we win. All we have to do is sit there, wait and eventually, everybody else catches up.

Jeremy: Right.

Simon: Now, evolution doesn't stop. So the emerging practice continued to evolve, eventually got a name, DevOps and distributed systems, designed for failure, chaos engineering, continuous deployment, all of that sort of stuff. But also, evolution occurs right up and down the chain. So what's happening is the runtime started to shift from product to more of a utility. So we went from LAMP, .NET stack, all that sort of stuff to Lambda. And of course what you're doing is you're getting the same co-evolution of practice because all of a sudden, we've got billing by function, we can look at capital flow in applications, we can associate value to the actual cost. So you get an entire new area of management practices appearing which is called FinOps. It's that combination of the finance, operations, development together. Okay.

Simon: So this is where you learn another pattern, this is one of the basic principles is the strategy is iterative because if in 2008, where would I attack? Well I attack at the cloud space, the DevOps space, et cetera. By 2016, 2017, all of that stuff is going to become the new legacy. Where you attack is now the serverless space and the new, emerging practices. Now these changes are never not nice and linear, they're punctuated equilibriums, they're exponential in nature. So the best way of explaining that is with marbles. If I take a big room and I put a marble in the corner of the room and I double the number of marbles every second, then in about 10 seconds, I have a nice big pile in the corner. And if I say to somebody, "How long is it going to take to fill the room?" They probably go, "It's going to take hours." But I know it's going to take about another 10 seconds because I keep on doubling on size and people are really bad at getting this.

Simon: This is why when EC2 launched in 2006, you were saying it will take five to eight years, the battle will be over for the utility computing. The winners will be announced and 10 to 15 years to become the new norm and of course people are going, "Oh, it's going to take 30 years or 40 years or whatever." As they're always caught out. People always react too slowly and too late and this pattern occurs throughout history over and over and over again. So currently, this is about 2015, 2016, that's where it was. And so today, it's just the same. What you're seeing is exponential growth in serverless and FinOps and that's all growing but from a very small base there, everybody thinks they've got loads of time because they've got all the inertia created by preexisting practices and infrastructure and it's not just computer servers and data centers, now it's also the DevOps crowd and all of that as well. So Kubernetes containers, they're all in that area of the new legacy. And so what's going to stop this? Nothing unless you stop competition. It's as simple as that. Did that make sense?

Jeremy: It does and I have a couple of points I'd like to make. One, I feel even worse now about not learning mapping because again, this was amazing and two, I do feel like I'm getting a private lesson here. So I'm already on my way which is good. So the map that you were just showing us has serverless as that utility. You said 2018-ish, somewhere around there of where that was then and I'm curious, serverless keeps getting harder and this is probably a strange thing to say but it becomes more complex, there's more services, there's differing technologies, there's competing technologies, there's a lot of cloud providers innovating on this stuff.

Jeremy: And so I guess my question is where does that utility go? And by utility, are we talking about primitives, are we talking about SQS Queues and DynamoDB and API gateway as being these primitives that are their own separate utilities that you then have to string together or is there some progress that we're going to make where we're going to say, "Look, all of these utilities can start getting bundled into other utilities and maybe we can put SaaS aside for a minute." I'm just curious if that's maybe where the cloud providers go.

Simon: Okay. So first of all, when we talk about utilities here, we're mapping. We're mapping the fundamental concept itself. So what we're talking about is the runtime. So the runtime when it was a product was things like LAMP, .NET. We had a long, long period of time where it was very much in that product stage. Then what we're now talking about is it's become so widespread, so well defined, so well understood that we can start to provide it as more of a utility and that is what you're seeing with Lambda. I avoid the words like innovation and other bits and pieces because the problem with the word innovation is the genesis of the novel and new we call innovation, the custom built examples we call innovation, every feature differentiation on a product, we call innovation, every product utility business model, we call an innovation.

Simon: So all we ever see is innovation everywhere and it's impossible. These are totally, totally different things with totally different characteristics but we'll use one word for it. So when you are mapping, you're mapping the fundamental concept, the thing of what is it is. And so in which case, we're talking about the runtime and that is shifting from product to utility. Now, there's a slight confusion because the runtime as a utility we call serverless but when building a system, we need to talk about serverless architecture. So the serverless architecture is not only the runtime but also the services that we consume as well some of which maybe more or less serverless. Some of them will be very much in that utility all the way down to zero if you're not using it, completely based upon usage, et cetera. Some of them maybe less so, some of them maybe more of the rental sort of model, minimum subscription, all that sort of stuff. Maybe not so well defined.

Simon: So you have to distinguish between the serverless architecture which is the system you're building, it's going to have the runtime plus also the services you consume and the runtime itself which as a utility, is what we call serverless. So I suppose that's would be where the confusion is. Now, whenever we get a shift from something like product to more commodity, invariably what happens, generally, a defacto standard appears. So something becomes dominant, everybody adopts to it. Various standard bodies like to say we're going to do on by de jure, we're going to decide what the standard is. It wasn't IPX/SPX, that was a different network protocol. It was seven layer model, wasn't it?

Jeremy: Mm-hmm (affirmative).

Simon: So it became, "We're going to have the seven layer model, blah-di-blah, none of this TCP/IP nonsense. We're creating that as a standard." And of course they absolutely lost because the market chose TCP/IP. So they reinvented the seven layers and said, "Oh look, TCP/IP is compliant." And that's what standards bodies do. And so in cloud, EC2 just ran away with it. And so if you wanted the standards and the infrastructure, EC2 has three and this problem OpenStack made, they went "Oh, we're going to build our own APIs and all the rest of it." Good luck with that, you're just created a prisoner dilemma. It doesn't work, you should co-opt but there we are. And to be brutal, Amazon has pretty much ran away with it again with Lambda. At least Microsoft was a little bit on the ball, Google less so. The rest of the people are just out on the field. So pretty much, they're defining the standard but you're going to get competing. People will go, "Oh, you don't want AC, you want DC or whatever." And eventually, the market will tend to gravitate and shrink down to hopefully just a few standards. So that's roughly where we are.

Simon: So separate between the runtime and the architecture. So you've got serverless in terms of the runtime becoming a utility. So you've got serverless architecture which is the combination of your runtime, your code plus all the services you use which some of those will be more utility, some of them less are evolved at the moment and we will eventually get standards in there and those standards will be defined by the market. It's pretty much Lambda is defining it at this moment in time. Does that answer your question? Sorry.

Jeremy: It answers that I need to spend more time learning mapping but yes, it does answer my question.

Simon: Okay.

Rebecca: This reminds me of a conversation I had, the first person to introduce me to mapping actually was Aleksandar Simovic.

Simon: Oh, he's fantastic. He's brilliant.

Rebecca: Oh yeah, him and Slobodan and Fer actually all big fans of yours and I've worked with all of them. Anyway, I used to joke with Aleksandar that being a software engineer, he really understands the plumbing of the internet, he's essentially the internet's plumber and he always got a big kick of that saying, "I'm just going to go in and do some plumbing." And I'm wondering when you're talking about utilities, are cloud providers the utility company? Are they the new utility company or will it be SaaS providers, will it be both, is there space or room for both or is AWS so far ahead that they are the new utility, they are the utility especially with Lambda in their back pocket or their front pocket, if you will.

Simon: So a couple of things, [Aleks 00:23:25] is great.

Rebecca: Yes he is, agreed.

Simon: By the way, as a recommendation, Cat Swetel fantastic to talk to. If you don't know Cat, she's absolutely brilliant. Talk about all the changes that are going on maps, DevOps and everything else and I'm saying this while I'm looking for a book and I know I've got it somewhere but I can't see it at the moment because I probably lend it out all the time. So Amazon, AWS itself created a book which is called Leading Cloud. I've got the title wrong, so give me a second. Hang on so you can see what a scruff I look. Let's see, have I got it here? We'll have to find it out.

Simon: But in this book, AWS, it's the second ever book they created which is all about cloud and everything else and within there by the way, there's an entire chapter pretty much on mapping and in there is a particular gameplay. I'd say there's about a 100 different forms of gameplay. There's a gameplay known as ILC, innovate, leverage, commoditize and it's a simple way of basically you take something which is a product, turn it into a utility, allow everybody else to build on top of it, mine the metadata to spot future patterns which you commoditize to new component services and that way, you just move up the stack. Same gameplay the Chinese government has been doing since the 1970s and they're about to dominate the world and everything else. Amazon does this pretty much in the commercial world.

Simon: So the answer to it, when to shift a product to utility, does it distribute or centralize really depends upon the gameplay of the players involved and the brutal honesty is Amazon has played a good game, Microsoft has not done too badly, Google is okayish and everybody else are off the cliff. So it's centralizing, it didn't have to be. If execs spent more time thinking about their strategy and landscape rather than playing golf, then it wouldn't have been the case that Amazon would've piled in and just taken this entire market but they don't. And so that's the brutal honesty of it. Amazon is moving up that side of the stack. Hang on, cloud book. Let's have a look. I'm going to get shot, I should know this book off the top of my head because I'm mentioned in it. I'm just having one of those moments or I've just forgot what it's called. I know the authors as well, isn't that dreadful? If they ever see this.

Rebecca: We won't tell them.

Jeremy: We'll put it in the show notes.

Simon: Oh yeah, you put a highlight.

Jeremy: As soon as we figure out what it is.

Simon: I have no shame or whatever. Is it Jonathan Blood? I've got to get you the link. Reaching Cloud Velocity, that was the book.

Rebecca: It's a beautiful title.

Simon: It's fantastic. So it's a fantastic book actually and the second ever book by AWS and in there, you'll find a chapter on that. It's about 17, 18 pages of mapping in there is the ILC model. So it didn't have to be this way, just Amazon plays the game. Loads of other people had inertia, very dismissive, they're listening to what McKinsey are saying, clearing the air on cloud, it's not the future or whatever or it's just for startups which is where it was back in 2010, 2011. So Amazon plows through, they're pretty much doing the same game at the runtime, Microsoft is a little bit more on the ball. It doesn't have to be this way.

Jeremy: It just sort of is.

Simon: But that's the way it is.

Rebecca: So Simon, you've mentioned inertia a few different times and so often, we hear about momentum or inertia being a friend, right? But in these ways, it's a foe. So I'm curious if you can maybe talk a little bit about that distinction, when momentum is a good thing and when inertia or momentum becomes a bad thing.

Simon: Okay. So if I'm selling a product, having inertia to change as in driving it to a utility is actually a good thing because I'm selling a product, I'm maximizing my profitability and revenue around the product. And I start building up more and more success, maybe I'm selling servers and I'm selling ever increasing volume, good margins, I'm quite happy. Then somebody comes along and says we're going to turn it into a utility. We're not going to sell physical servers, it's going to be provided on a utility basis. We'll I've got this entire business which is my past success and everything else and I'm looking at that thinking, "That's the future, that's what I do." If I don't understand how things evolve, it's very easy to dismiss that as it's some startup, it's a book seller. What do they know about compute? A book seller. I've been selling servers for 30, 40, 50 years, you just get back to selling books.

Simon: There's 16 different forms of inertia. Preexisting business, preexisting capital as in financial capital, political capital, existing governance practices. So not only do vendors have inertia, the customers of those physical servers and buyers of data centers have inertia and so forth. And so there's a point where it's good because it maintains profitability and revenue but once the thing has evolved to be suitable for a utility, then it becomes bad as in the inertia is the thing that stops you changing, gets you to dismiss that future and that transition can be five to a year. So it can be really quick. So it's very easy to get caught out because you get wave after wave of ever slightly improving product. And so you think it's a slow cycle, you've built up this business around the product and then it gets converted into a utility. You're very, very dismissive, it rapidly grows and before you know it, you're in no man's land. You suddenly wake up one morning and find out you're IBM or somebody along those lines, okay?

Simon: So the interesting thing here, people like to talk about Christensen and disruption theory. Christensen and Lepore used to argue about disruption theory. Christensen said it was predictable, Lepore said it was not predictable and the interesting thing about disruption theory is there's two different types. Things like the shift from product to utility is highly predictable in terms of roughly when it's going to happen, that it's going to cause co-evolution of practice, that you're going to get an exponential change, a punctuated equilibrium. There's a long list of things you can say about it. So it's a form of predictable disruption but product to product substitution like Apple versus Nokia is highly unpredictable, you don't know which way it's going to go which is why Christensen said that Apple wouldn't succeed and it turned out they did. Not because he's daft, because it's unpredictable.

Simon: So what you've got with disruption theory are two different forms. That which is unpredictable, product-product substitution, that which is predictable, product to utility. So IBM versus AWS. Unfortunately, if you can't see the evolution, you can't map it. You can't tell the difference between them and which is why you end up with these arguments going on about whether it is and isn't predictable and the answer is there's two different forms. Sorry, that was a bit of a ramble.

Jeremy: It was great.

Rebecca: I loved it.

Simon: I have a tendency to do that.

Rebecca: I was deep head nodding, yes.

Jeremy: Right, yeah. Just trying to process all of that. So it's interesting because again, I think for most people and maybe this is just me because I'm more in the cloud space now but I think for most people, they see the benefit of moving to utility computing. So put serverless aside for a minute but just utility computing and not having to own and maintain your own servers and rack and stack and all that stuff that goes along with maintaining your own data centers. Clearly there are reasons that people still do that but if we go towards the adoption side of things, even more down to just the runtime as you're again, talking about serverless.

Jeremy: So you wrote this, I think it was a full report about what's the fuss about serverless. So this was I think three years ago now, or almost three years ago and you said back then that companies should start embracing or sun-setting old ideas like infrastructure-as-a-service, containers and then obviously hardware focused view of DevOps. So I'm curious now, you said earlier on the show that Kubernetes is now in that legacy thing. Kubernetes is a juggernaut and every other platform provider that's building serverless applications or building any type of platform seem to be building and standardizing on top of Kubernetes. So AWS is following that to meet customers where they are, it's still innovating on serverless but I'm curious. Are all these people wrong or are we just in this weird stopgap where people haven't quite figured it out yet?

Simon: So I'll take you back to cloud in 2008, 2009. When you listed to talk about the shift from product to utility and how it was moving to more of a utility that would be a new set of practices, that was the future, you'd have to get out of the data center and out of server as a product. The argument was now that's nonsense, the future is virtual data centers. We're all going to have virtual data centers and I'm not just saying that was one or two people, that was the vast opinion, the overwhelming opinion was the future was virtual data centers. That's what we're going to have. This utility compute message is for startups and everything else. So you even roll forward to 2001, clearing air on cloud, it's all about startups, it's not for proper enterprises. Proper enterprises use virtual data centers and all that sort of stuff. So can a whole bunch of people be wrong? Oh yeah, all the time absolutely.

Jeremy: So that's the thing that I've always or what I've seen lately and everybody is doing this. Everybody who is now hosting Kubernetes, especially as part of the cloud providers, they've all got a service. So whether it's EKS on Amazon or it's GKE and IBM has their own one. Everybody is embracing Kubernetes but they're also embracing the idea of essentially hosting it for you so you don't have to deal with the management of it and I always get this impression of are we just evolving Kubernetes with these hosted Kubernetes services just to get us right back to where we already are with something like Lambda.

Simon: Okay. So those four, that's lower down the stack. So Lambda is at the runtime, Kubernetes is where we're messing around with containers and all the rest of it and everything else. So it's further down. So Lambda really is the whole thing about writing functions, billing functions et cetera. It's really focused on the cone, not any of the underlying components which you're seeing which is where people are. So people have inertia. You asked me why would Amazon provide Elastic Kubernetes service and all that sort of stuff? Well, because it meets customers as you say, where they are but it's dominating the future space as well. So it's just saying, you want Kubernetes? We'll let you have Kubernetes. It's much easier than you trying to manage it yourself and by the way, it's dominating in Lambda. Lots of other people are saying that Kubernetes is the future, it will dominate. The same story with OpenStack is the future, it will dominate. Docker I noticed they've just changed their license agreement, I don't know if anyone has seen this but anyway.

Simon: So yeah, the future is worrying about things like capital flow through your applications, where money is actually being spent and what functions, monitoring that capital flow, tying it to the actual value you're creating. You look at companies like iRobot or Liberty Mutual and what they've done with serverless. iRobot provide those rumbas, there's 10s of millions out there and the entire thing is run by six people.

Jeremy: That's very true.

Simon: Or the BBC started using Lambda. I think they converted the entire thing, got it running on Lambda before the Kubernetes team even setup their cluster. Okay sure, we can make it even cheaper by using Elastic Kubernetes Server or whatever. It's focused too low down stack, to be bluntly honest. Great, I would say perfect strategy if it was 2008 but it's not, it's 2021.

Jeremy: Interesting.

Rebecca: So I think you're getting back now to perhaps my new found favorite theme which is inertia and thanks for introducing me to this. Also, real quick shout out to both Ben Kehoe and Tom McLaughlin who are real big, serverless proponents both in iRobot and Liberty Mutual. [crosstalk 00:36:46].

Simon: Ben is fantastic.

Rebecca: Great folks.

Jeremy: And Matt Coulter.

Rebecca: Yeah. So many really [crosstalk 00:36:52] people we've been able to work with.

Jeremy: Gillian Anderson, yeah. Mark McCann, yeah.

Rebecca: Just going through all the names out there to be like, "Simon Wardley just mentioned you."

Jeremy: Check the show notes, we'll just put a whole list.

Simon: Also, you've got to think about people like Liberty Mutual, David Anderson then you've got all the people over at Capital One and things like that.

Rebecca: Right.

Simon: Because people often say to me serverless, that's just for startups. I'm just like, "Really? Come on."

Rebecca: These are some pretty prolific thinkers in this space. So Simon, governments come to you maybe after seven years or 14 or 21 depending on how long their seven year cycles are but your consulting people whether or not its huge governmental agencies which you can only talk about so much or large companies. People are coming to you for advice and I'm curious about when we're talking about people with any change against inertia, the antagonist against inertia, it takes a total mind shift. And so I think there's a big difference between wanting to change and then being actually prepared to change. Perhaps even as subtle as it's a map, not a graph. There's different axes that you need to look at. So I'm curious if you've seen people who want to make the shift towards serverless but keep getting stuck and is there any specific place they keep getting stuck and do you have any advice for them to get unstuck about taking those first incremental steps that can unlock that shift?

Simon: Okay. I've been blunt enough anyway, I'll be brutally honest. Most inertia I don't find in people, in engineers, people doing the actual work. Most inertia I actually find in the management layer, in the executive layer. So where inertia occurs. For example, one government department very much resisting the shift to cloud mainly because the systems admin people within there and their managers were like, "Oh, we can't do that." Because the vendors were in there saying, "Well if it all goes to cloud, you're all going to be out of a job." And all that sort of stuff. So it was quite simple, it was to say well look, we don't want to shift to cloud actually. Totally agree because the runtime shifting. And so what we want to do is build up where which of course means that all the people will have to retrain up there and of course that creates a problem because those people will suddenly become incredibly valuable because this was 2016, 2017. They will become valuable over time. And all of a sudden, all these arguments because you gave people a path to go.

Simon: So one of the things I use with maps is I use the maps, I apply economic patterns to it and I look at points of inertia then you can directly counter those strategies for all different 16 forms of inertia that you can counter but the most important thing when it comes to people is give them a path. I hate this when people talk about people as resources or things like that as disposable assets. It's just a horrible way of thinking about things and I generally find that people are resistant to change. What they're resistant to is having a bunch of management consultants coming in and telling them they're fired while they're employing somebody else to do it. So not being given the chance, that's what I generally find.

Simon: So in terms of when it comes to adopting serverless, you've got several problems. One, executives like to talk about we have a strategy and it failed because execution wasn't right which is just a way of blaming other people for the fact that strategy was wrong in the first place. And so you've got to be mindful of the fact that you're going to have inertia within the executive areas, particularly talking about loss of manpower. You're going to have inertia within the people doing the actual work if no one has given them a path forward. Those things are fairly normal. So it's a good idea to map it out and find people a path and tell people where we're going to attack and how we're going to attack it as well.

Simon: You're going to have inertia coming from the vendors, the vendors will always tell you that you can have the future just like the past. So your capital investment, we can make sense of that. We can turn your grody data center into a private cloud, it can out compete Amazon. They're going to tell you all that stuff as long as it sells them servers. So you've got to be mindful of those sorts of things. One of the other big problems is of course once you get into serverless, you're really tying value down to where you're spending money. So this is like capital flowing applications.

Simon: Unfortunately, most organizations are very poor in understanding the landscape, very poor at understanding of the value that things create. If they actually mapped it, then it becomes a lot easier to do this sort of stuff. This is why you should definitely talk to David Anderson from Liberty Mutual, that's a great example or Drew Furlong is at Capital One, another great one. If you're going to have an honest discussion and for that, I use a map and we talk about what's changing, where are we going to have inertia and we talk about the inertia that we have and how we're going to tackle these issues, how we're going to give people a path forward because we're going to need them, we;re going to need them just working in a different area. I always find it relatively easy to overcome as long as you do the thinking beforehand. Right, okay?

Jeremy: Do enough people do that?

Simon: If you've just announced we're doing this great, big change program, it's all going serverless and the vendors are coming in saying, "You're all going to lose your jobs." Then you're going to have problems. So I generally find in it's in the executive layer.

Jeremy: Yeah. So actually, I've got a followup to that because I'm really curious about the inertia thing as well and I'm wondering. A lot of things we talk about, especially with technology adoption is friction and where some of the friction is in order to do that and inertia helps you push past some of that friction. Obviously vendors creating better services or creating commodities and things like that, utilities that you can use in order to do some of this stuff. But I'm curious because if I'm a developer in a big organization and maybe my boss hasn't figured out mapping yet or they're not sure what strategy direction they want to go, I can adopt serverless for a small project internally with very little friction. So I don't need to spin up a Kubernetes cluster or buy a giant license to VMware or something like that, to try something new.

Jeremy: So I'm curious, does that low amount of friction, does that play into potentially the strategy of adopting serverless from the ground up and then maybe the executives saying, "Hey, this is saving us money or it's giving us whatever." Or is it really going to take a cultural shift and a strategy at the top to bring companies over.

Simon: So I used to read the FLOSS Reports, Free-Libre Opensource Software when they were produced back in 2004, 2005 and it was great reading because you'd get these executives going, "We don't use opensource software but we use things like Apache, MySQL, Linux but we don't use any opensource software." And it was wonderful seeing these surveys because they had no idea what we were talking about. And so you'd often get these diktats of we cannot have opensource here and people just going and installing Apache, MySQL, Linux and all the rest of it and just saying, "It's not opensource, it's Linux." So yeah, it was happening all the time. It's a bit like shadow IT and all that sort of stuff. People have jobs to do, they want to get the job done. At the end of the day, they want to provide something which creates some value somewhere. So they're going to use the best tools they can get and sometimes, people are going to say, "We can't do serverless." So you're always going to get testing examples.

Simon: One of my favorite was a big... Anyway, I won't name the company. So let's just say they're a TV company and they launched their online service and what happened is the CIO at the time said, "Right, well we're building an entire new data center and everything else and it's going to have all these wonderful servers and complies with all of that but we're going to have a backup solution on AWS." And on the day of launch, the data center version wasn't working so they launched with the AWS backup and that was perfect and that's where it's stuck since. Now the reason why the data center version wasn't working is because they never built it. The CIO basically just said we're going to have this then didn't build it.

Jeremy: Interesting.

Simon: So on the day of launch, failure, it doesn't work because we haven't built anything. So we'll run it on the AWS, hunky dory and it was all running on his credit card this entire time. [inaudible 00:46:12]. Sometimes, the inertia, the response is going to be very, very irrational. Sometimes, people have to. If you can't discuss the environment because you haven't got a map or when you talk about environment, it's all being story driven. Sometimes people will just go, "I've got to get the job done."

Rebecca: I wonder and I feel like there's maybe a sneaky thread between exec level decision makers and what you've said a few times, vendors or analysts lets say and I think also from reading some of pieces, there's maybe a thread to be drawn between inertia and memory. And I'm going to get around to my question here which is are vendors a bit of a villain to actually making the right decision in terms of by creating these pieces of content that basically at the very beginning, the cloud is not everything that you think it's going to be. They actually imbed a memory and a culture of decision makers who are the people that are reading those things and then they're actually taking away from inertia. When is it perhaps good? How does someone be healthily skeptical about supposedly what these vendors are saying but they're actually embedding memories that could be negative or are creating the doom loop in terms of cultural memory.

Simon: Yeah. If I'm selling you a product and I'm making money from selling you a product and I'm selling product, inherently, my organization is going to have inertia to change. Inertia to the idea that is going to disappear and it's going to be a utility. Why? Because I'm making loads of money and I'm selling stuff. I've got all this past history and past data which says I've been selling stuff, I've got all these customers building and there's just this little group over there doing this utility. So I've got all the reasons to stay exactly where I am. It comes back to your point, you actually want that in the early stages of a product but when it shifts to a utility, once it's become widespread and well defined, that's when it becomes a problem. So what do you try and do? As a vendor, you want to sell more of your product. So of course people latch on to old, it's not secure or you can do it cheaper. If it sells more and more of their product, of course that's what they do.

Simon: Now if you are a customer at that point, you've got to say, "I've built all this team, I've got all this practice, I've got all this experience, I've got all this capital invested in it and I've spent 400 million on a data center. What do you mean I can run it on a credit card?" Oh my God, don't tell her, don't tell the CFO. I've got political capital, I've got all of this invested in this so of course I'm going to have inertia to it as well. I'm going to want to somehow make this stuff make me look good or I'm going to want to keep going until I retire. Once I've retired, then I don't care.

Simon: But I don't want to rock boat, I want to keep things going. The vendors are telling me all the practices are new, they're emerging, no one knows how to do this stuff, it's not secure but are they giving me all the reasons for me to stay exactly where I am because I've spent all this money and I have all this capital investment, I have all this past there, I have all this political capital and I've only got four years to retirement or whatever it happens to be. So all of that stuff comes into play.

Jeremy: Right. It's that sunk cost fallacy that probably creeps in there. But actually, Forrest Brazeal has a really great one of those cloud cartoons points out the amount of effort or whatever it is for when you're buying versus building but then the regret index that if you've built something and have to get rid of it, that's really high but if you've bought something and have to get rid of it, the regret index is much lower. So probably also again, wise strategic move to buy things that are more utility based as opposed to building custom things which you then own and have to manage and maintain.

Simon: Yeah, here we are.

Jeremy: All right, great. So we've got a couple of questions from listeners. We're only going to ask you one because I know we're running out of time from our Serverless Chats Insider List which people can sign up for if they want to get updates. They knew you were coming on. So the question has to do with the single biggest objection that you hear from folks when advocating for serverless. So what's the biggest objection you typically hear and then what's your counter argument to that other than it's inevitable.

Simon: It's just for startups, it's the startup thing. And so I just point to Capital One, Liberty Mutual, those well known startups. iRobot, I think they've been going for about 30 years. So that's the first thing. The second thing is we're already invested in this path, okay. That's just an issue of inertia. The next is the practices have not fully developed and all the rest of it. That's true enough. It's very much you can go back to 2010 DevOps, we had the flag but the practices were still evolving at the time. So you could make the decision 2012, 2013 you're going to build yourself a new data center and use all those past methods and all the rest of it because the practices were still evolving in this new world. Not necessarily a sensible thing to do but a lot of people will justify it in their.

Simon: I suppose the biggest one and the biggest objection is this is the story they've already sold. So one of the problem is if you've got a team of people who've created a story for why they need to do something, you can't challenge a story and the reason why you can't is because there's that entire industry of saying to be a great leader, you've got to be a great storyteller. So when I challenge your story, I am saying to you, you are not a great leader. So I'm challenging you directly. This is the problem with stories.

Simon: So that's probably the biggest obstacle I face and what I have to do then is get them into something like a map because once I've got them in a map, I can say I think the map is wrong. I'm not challenging you, I'm not saying you're not a great leader and your story is wrong. What you've done is translate your story into a map and then I can attack the map and then it becomes quite easy for you and me to both gang up on the map because obviously the map is rubbish and then we end up in a completely different place. So I suppose that's the biggest objection that I have or the biggest one is they've already decided that's the story, they don't want to change the story.

Jeremy: Interesting.

Simon: Make sense?

Jeremy: It does.

Rebecca: It does. I'm going to take us on an aside really quick but Simon especially, I have to know. So in that same piece that you wrote about memory, you do pay homage to Dungeons & Dragons and I was really curious. I have to know, I imagine you would be an incredible DM and I was like, "I need to know, the world needs to know if Simon Wardley, if they could play with him."

Jeremy: He's a dungeon master guide.

Simon: So I play Dungeons & Dragons with the wee lad, I've got the original set and all this sort of stuff. So I love both being a player and being a dungeon master really is enjoyable. I think it's a great thing. So yes but I play with the wee lad as well and actually, [crosstalk 00:54:35].

Rebecca: And is he a mapper?

Jeremy: Does he map while-

Rebecca: Yeah.

Jeremy: You just trade off.

Simon: We use it occasionally and talk about all sorts of things in terms of things that are going on in political systems, et cetera because mapping isn't just about technology. You can do nation state competition, you can do it for culture, you can do it about political systems, all different sorts of areas. So you do a lot of that sort of stuff and trying to challenge the ideas. So that's quite fun.

Jeremy: Well that's one of the reasons why I had kids, so that I could keep playing games and not seem like I was an adult playing games by myself.

Simon: Well I have no shame. Play is a really important thing. I have to say we have this somewhat terrible attitude towards play is the idea that you shouldn't play, you should grow out of these things. Play is critical for imagination and for socialization. Gosh, I always think I'm over the hill. So when I was 20, 25, I thought I was over the hill or I've messed up something, career is over. I think I was having an interview to work in Boston Consulting Group but I'd failed in the first round because I wasn't executive material or something like that. Maybe at 10 years, Oh God, I feel dreadful. But I then went and built and sold several companies anyway. So 25, I thought I was over the hill, 35, I thought I was over the hill. When I hit the 40, it was like massive doom. Doom, I'm too old now, you're too old to be creating.

Simon: And I went back and started looking into the core research behind this and one of the core pieces of research was they followed and I can't remember off the top of my head, it was about 1,500 scientists and looked at the rate of publishing papers and what they noticed is they published a certain number of papers in their 20s and 30s and then it peaked at about 35 and slowly went into decline and then by about 50s, 55, 60 was really dropping off. And so this is where this whole idea that as you get older, you get less creative. The problem is if you look at the core data, they hadn't accounted for the fact that people tend to get older as they get older i.e., they tend to retire or die. And one of the reasons why people might not be publishing might be because they're dead or retired and if you actually adjust for the numbers who are active on the field, it's pretty much a flat line with a tiny little peak about 45 but pretty much flat.

Simon: But nonetheless, we created this whole myth, this whole idea that to be innovative, we've got to be youthful and all the rest of it as well and when you get older, that's it, you're completely gone, all the rest of it. Terrible. I don't know why I said this? What was the question again? It doesn't matter, this stuff is too [crosstalk 00:57:41]. Let's talk about gardening.

Rebecca: That play is critical.

Simon: Oh, play is critical.

Rebecca: Play is critical. There's a timeline, I've got you.

Jeremy: I think you said I'm going to peak at 45 I think is what he said. So I've got a couple of years and then I'm going to peak at 45.

Rebecca: Jeremy, you better learn mapping fast.

Jeremy: I've got to go fast.

Rebecca: There's some things you've got to get going.

Jeremy: Amazing.

Simon: I think the figures showed you had to get to your 80s. I think it was late 70s, early 80s before you're as uncreative as you were in your 20s. So that's what you've got to think about is you've got loads of time.

Rebecca: You've got time, yeah.

Simon: Good.

Jeremy: All right, good to know. Speaking about time, we are out of time. So Simon, thank you.

Simon: Oh, this has been too much fun and we haven't talked enough about gardening.

Rebecca: Simon, thank you.

Jeremy: We haven't talked-

Rebecca: I know.

Jeremy: We're going to start a new podcast.

Rebecca: We're going to have you on again.

Jeremy: We're going to start a new podcast called the gardening podcast with Simon and we'll do a whole thing on it.

Simon: We could talk about-

Rebecca: The Meadow Tiller, we'll call it the Meadow Tiller.

Jeremy: I love it.

Simon: I've done all the work on the meadow at the moment so it's a bit-

Rebecca: The Constant Meadower.

Simon: Anyway, sorry. I shouldn't, we could go on for ages. Anyway, it has been a delight, it's a pleasure. I hope people enjoy your show, you've been wonderful. I really enjoyed it, thank you.

Jeremy: Well, thank you.

Rebecca: They will enjoy you on the show.

Jeremy: Absolutely. And if people want to find out more about you, contact you on Twitter, how are they do that?

Simon: Go @swardley or you just look up Wardley Maps, you'll find there's a Creative Commons Medium.com/wardleymaps. And then there's a whole bunch of people out there doing interesting mapping stuff, Ben Mosior at Hired Thought teaching people how to map. There's a bunch of work going on in all different organizations from the UN to combating poverty to combating slavery. All sorts of fascinating stuff going on with mapping. So that's easy to find. There's also something called Map Camp. So it happens 13th of October each year, Mapcamp.co.uk. It's mappers from all over the world get together, we share maps on all this sort of stuff, share the techniques. It's all creative commons, help yourself. So yeah, just search on [crosstalk 00:59:44].

Rebecca: And there are mapping meetups, right Simon?

Simon: Oh yeah.

Rebecca: A lot of people that host their own mapping meetups so people who just want to get started can even look for their own local chapter and see if they can connect with people at a meetup, right? To even dip their toe in.

Simon: Yes. Yeah, there are people who do their own meetups. Aleksandar was doing a Battle Camp where people were doing competitive mapping against each other. So there's often things within companies as well. Just remember, the thing about a map, all maps are imperfect representations of a space. If you take a geographical map, a perfect map of France would be 1:1 scale which means it would be the size of France, therefore it would be France and as a map, that's absolutely useless. I'm not saying France is useless, I'm just saying a map the size of France would be useless.

Rebecca: A simulacra of France is useless.

Simon: Yes. So the point about this is all maps are imperfect representations because underneath this is a model of evolution, they're also wrong. So they're imperfect and wrong. But because they're imperfect and wrong, that gives us freedom to challenge because going back to the trick about getting somebody... Well, put a map down on a piece of paper and I can just ask questions and I'm saying the map is wrong. Have you got three minutes?

Jeremy: Absolutely.

Simon: I can just give you a very, very simple example just to show this.

Rebecca: For you, anything.

Simon: Oh, that's very kind. Hang on a second. When he says three minutes, he takes two minutes and 50 seconds. All right, let's open up this. Hang on a second. Right, this is the insurance company, big company. This is their process flow. I've got to hide the bit at the bottom, hang on a second. Right, this is their process floor. They need compute, they order a server, a server comes in, goods in. They modify, mount and rack it. And they're given lots of servers and oh gosh, this is about a decade ago. They had a bottleneck in their process flow which is to do with modifying, mounting and racking the servers. So they came up with this plan to invest in robotics. It was millions of capital expenditure in robotics and that was going to get rid of their bottleneck and and everything else and improve their process.

Simon: They had the business case, they had spent six months working on this and all the rest of it which had an investment calculation, it was the whole lot. So they asked me what I thought and the thing is, I can't go, "Why are you doing robotics?" Because that's their story they've sold, it would be an immediate fight. So I said, "Can we map it?" They went, "Oh God, what's the point of this?" Anyway, this was a 10, 15 minute exercise. Here's the map. A user needs compute, they put compute in product. Order server, goods in. They put that in utility. I thought server is a utility, compute is a product, it seems a bit odd but that's okay, all maps are wrong, we can challenge. And they went rack, mount, modify and this was literally 10, 15 minutes. And I was able to ask them a question, "Why have you got racking custom built?" And they went, "Because we have a company that makes our racks for us."

Simon: "So what are the modifications you're doing to servers?" "Well they don't fit our racks so we have to take cases off them, drill new holes, add new plates in order to get them to fit our racks." Right. "And that's why you need robotics?" "Yes." And of course in the room, somebody just went, "Hang on, why don't we use standard racks then we wouldn't have to do all this and we wouldn't have to do the robotics and we wouldn't have to spend all these millions?" Now these people were not stupid, they were bright. The problem is they had been trapped context, trapped by the stories. At some point, the custom built racks made sense but because they were trapped by that story now, they had no way of challenging it.

Simon: So they came up with a plan to spend millions investing in robotics to basically improve a process flow when in fact actually, that's not why you want to do, what you want to do is take a rack and evolve it, use a more standard commodity rack then you don't have to do this stuff at the bottom. And this is probably one of the most common problems I see and I'm not talking small money, 10 million, 100 millions. I'm talking billions wasted in people constantly improving process flow when actually, what you want to do is evolve the components in the process. What you don't want to do is improve because it's a highly ineffective process and so there's no point in making it more efficient.

Jeremy: That's brilliant.

Simon: Okay. And that's a simple example, that's literally they'd spent six months and it's not because these people are daft by the way, they're not.

Jeremy: I can think of many examples right now where this would apply to and save people a lot of time and wasted human capital. It's just amazing.

Simon: Yeah. There we are, that was easy.

Jeremy: All right. Again Simon, thank you so much for being here. It was great to have you, thanks for taking the time.

Simon: It's great fun. Anyway, it has been a pleasure, a delight. You take care, keep safe.