Tech Talk: Simplifying the Future With Adrian Cockcroft [Video]

Last week, we watched the latest keynote from Adrian Cockcroft at SpringOne Platform in Las Vegas and immediately wanted to help share it with the greater community. While it’s deservedly a “must watch” talk, we have provided the transcript if you prefer to read it in a shorter amount of time. We hope you enjoy the presentation as much as we did!

Video

Transcript

Introduction

Hi everyone. I’m Adrian Cockroft, and currently work at Battery Ventures. Why am I here? Well, I thought you hadn’t enough drinking games, so I should just do an in-depth tutorial on microservices for the next two or three hours, how about that? Okay, well let’s not do that. What I’m actually going talk about, how do we wrap up a conference like this? I’m going to talk about simplifying the future in a number of different ways. Really, why am I here? Let’s just go with this, this is a tweet from 2012, retweeted by some guy called Andrew Clay Shafer. That what I was doing in 2012, was going around trying to explain all of this stuff Netflix was doing, and I called it “baffling late adopters-as-a-service”. We were pioneering, and we were trying to build things that hadn’t been built before, and we were trying to explain things that hadn’t been done before. This is now more than 4 years later. This has matured, it is now mainstream. It’s now what a lot of people are doing, and it’s what a lot of you are doing.

Life Is Complicated

Where do we go from here, and how can we apply these lessons as we go forward? That’s really what I wanted to talk about. Think about the future, let’s start with a bit of science fiction. Let’s start with this one. What’s the meaning of life, the universe, and everything? Right, you know that. What’s the answer? 42. Well, that was really simple. I can go now, right? Sometimes really complicated things have simple answers. There’s another really useful thing from this particular story. It comes with a really nice label on the cover about not panicking, so that’s good. If we think about this, life is complicated. It’s an extremely complicated world we live in. We seem to manage to deal with it. There’s a lot of simple abstractions we use for dealing with life, and dealing with all the things we’re working with and all the things we’re building. I’m going to talk about the things that are complicated in our lives, things that are complicated in the way we build things and the way we work, and then a little bit about where things might go.

What’s the Most Complicated Thing You Deal With Intuitively?

[2:19] What do I mean by life’s complicated? If you think about somebody saying, that’s too complicated. What they’re really saying is I can’t figure out what it’s going to do next. I can’t intuit it’s behavior. It’s got too many moving parts, and I haven’t figured out an internal model of how it works, and what it does. Think about that, what’s the most complicated thing that you can do intuitively? Let’s think about that question. Just think about it. How do you get around? You’re driving cars. Driving is one of the most complicated things that you could possibly think about doing. Driving across a city, you have to know how to control the car, you have to be able to deal with the other traffic. It’s insanely complicated, it’s quite dangerous. We expect just about every human being in the world to be able to do it. That shows the capability of humans to master complicated things when they have a real need to do it. That’s one area.

Think of something else. What’s the most complicated thing that your kids can do from about the age of two? How many people’s kids have an iPad? What is going on inside that little lump of glass and aluminum? It’s insanely complicated what is actually happening inside an iPhone, iPad, a tablet, whatever, a games console. Those things. Pre-verbal kids can pick up an iPad and just descend into it immediately. You don’t have to send them on a training class to learn how to figure out how to use this thing. We still have these problems with kids. One of the problems we discovered in thinking about TV and the way people interact with TV sets, we kept discovering that the bottom of your TV set has this mucky stripe on it, where the kids are trying to get the thing to go to next page. I have one friend who said they can’t watch TV with their kid in the room, but it gets incredibly upset that this stupid thing is not behaving properly. They learned, that you’re supposed to be able to reach into these images and manipulate it. This one wasn’t working right.

[4:29] That’s interesting. What’s going on, is you have built this portal to the internet that’s got the world’s information in it. It’s got incredibly complex applications in it, but it’s something that is incredibly easy to use with no training. That’s a different type of simplicity that people have added to an extremely complex system. We’re builders, we’re developers. We should be aspiring to build things that you can give to a 2-year-old, and they can intuitively understand how they operate, and what to do with them. You’d be really satisfied with yourself if you managed to build something that has that level of intuition to it. It was huge of amount of work, particularly at Apple when they first came out with the touch-based user interface, that is was that intuitive.

[5:17] What does it actually look like though? Well, I took my phone and of course I added about several applications to it, and then I grouped them. If I give my phone to my wife, or I pick up my wife’s phone, I can’t find anything on it. It looks kind of like this, it’s just a big mess of apps and stuff. We get these things and we make them complicated again. I do want to bring up a really good book, some of you may know XKCD, the cartoon. When Randall Munroe wrote this an amazing book, The Thing Explainer book came out last year using only 1,000 most common words in the English language. I think it’s actually the ten hundred most common words in the English language, because thousand isn’t one of them. He explains lots of lots of things. This is a hand computer, and it’s got all kinds of description about what’s actually going on inside the phone. In words that pretty much anyone can understand. You can take complex things and reduce them to simple descriptions. That’s an interesting way of think about this.

Simplifying Work

That’s kind of in our daily life. Let’s talk a bit about the way we work, the things we do. Let’s talk a bit about simplifying work. One of the things that came out of Netflix. Netflix is several different things. There’s watching TV, there’s that whole movie and TV content. Then there’s all the technology that’s been largely adopted by the Spring platform. Then there’s the cultural side, the way Netflix operates. One of the really interesting things that I was part of, was the culture deck that came out of Netflix. The freedom responsibility culture, this is a SlideShare with 15 million views. 15 million views for a slide deck. That’s ridiculous all on it’s own. Then Sheryl Sandberg of Facebook said that this may be one of the most important documents to ever come out of the valley and got Reed Hastings to be on Facebook’s board, to try to learn what the hell was going on there.

Freedom and Responsibility Culture

That’s interesting. The story I have is I joined Netflix in ‘07. When I was interviewing at Netflix, they were trying to explain this culture to me, and half the interview was them trying to explain this strange set of ideas. I found it fascinating. One of the reasons I joined Netflix was to figure out how that worked, and to really get my head inside it. In 2009, one of the management off sites, Reed sent mail out before the off sites saying here’s a deck, I want to publish this. Everyone go through it, annotate it, let’s discuss it, let’s discuss what we want to put, what we will say, what we won’t say. We all, collectively, the management team then was maybe 100 to 200 people, probably over a hundred directors, VPs, all the people across the whole company. We worked on this document at the offsite, gave it back, and he merged all the input together and came up with the initial version of this. It was a collective thing.

[8:10] What we were doing was trying to preset the people we were hiring, so that they wouldn’t come in and be baffled and confused. They would see this document. If you were horrified by what it said in the document, you wouldn’t even bother applying, and we wouldn’t have to deal with you. Walking you out of the interview after the first half an hour. In fact, nowadays if you turn up for an interview at Netflix and you have not read this document, you can get walked out. 15 million people have read it, and you want to work here and you haven’t figured that out. That doesn’t make sense. What we found was that it started to condition people for how they expected to see when we onboarded them. It helped create the culture, and maintain the culture.

Intentional culture has become a really important thing. We’ve seen other companies do culture decks. Nordstrom has one, lots of other people have written down what do they value, and published it externally in order to try to do that. It’s become a thing now. Think about how could you externalize that. If you’re doing a startup, or you’re starting a company, you get to set the culture. Don’t wait until the company gets big, and you have accidental culture of whoever will happen to be there. Be very intentional very early about what you want to have.

Purpose-Driven Culture

[9:24] So what is in this culture? Here’s an interesting, just one slide from it. “If you want to build a ship, don’t drum up the people to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea.” That’s interesting. That’s a purpose driven culture. It’s like, if everyone agrees what the purpose of the company is, then they will figure out how to implement that purpose. The implementation, you don’t need to do fine grain, telling everybody what to do. You can just set, this is where we need to go, everyone else figure it out. This is from a book called The Little Prince. This was in the original deck in ‘09, and it just happens that Netflix has a deal for the Little Prince. It releases tomorrow. This is a pure luck thing. There’s an animated show. It’s an excellent little movie. You can go home tomorrow night and watch The Little Prince with your kids, and be all inspired and note when this quote comes by. That’s a whole interesting area, but what we’re doing here, the simplicity. How simple is it to have a purpose and express a purpose? Purposes are a simple statement. That’s a simplifying thing. Setting out all the individual processes that you would need to make people gather the wood, and build ships and stuff, is much more complicated. It’s actually easier and simpler to express a purpose driven culture, and then itself organizes around that.

Imposing Process Drives Away Talent

[11:02] One of the other things we found, if you impose process on people, it drives talent away. This is a big problem, because everybody needs more talent, right? I was trying to explain this when I was doing one of my explanations that this is all the Netflix stuff, and this is what we did. I was doing it at an executive CTO summit. Somebody said yeah, we can’t copy Netflix because it has all these superstar engineers and we don’t have those people. I look around the name badges of the companies and said, well we hired them from you. You had these people at some point. There isn’t a cloning machine at Netflix that produces Netflix engineers from nothing. They come from other places, and they bring experiences with them. What we found, over and over again, was that people were producing a fraction of what they could produce at most companies, because they were being held back by the process and by stupid rules, and by all kinds of things that were just slowing them down.

When you get out of the way of innovation, and you get behind people, you find that you’ll magnify their ability to do things. You can get many, many times more out of a good senior engineer by getting behind them and pushing, instead of getting in front of them and getting in their way. There’s a lot of tricks to how to actually get that done. That is the essential reason why we were able to do, with a relatively small team, build an awful lot of things. Build a very pioneering culture. This is one of the things about Netflix, that time I was there, was that we built a culture and a team that could build things that had never been built before. It’s moved on now, you can build on top of those things.

[12:39] How do you organize people? It wouldn’t be a microservices presentation without Conway’s Law in it. This is the fore thing for Conway’s Law, the basic thesis of this article is that organization of the design systems are constrained to produce designs that are copies of the communication structures of the organizations. It turns out the way Netflix was structured was there was lots of autonomous groups with relationships between them, and APIs between them. When we wrote a bunch of code, it came up with this architecture that is now called microservices. We started with a company organization that was already cellular in nature, with lots of local responsibility, and lots of fairly well-defined interfaces.

[13:24] If you’re trying to build a microservice architecture, and you haven’t got that organization, you’re going to have a lot of trouble. The people that are succeeding in this space have co-located small teams that own a thing. They own all the different stages in producing that thing. Then they have relationships to other teams. They are very high trust, high cohesion within a team, and relatively low trust across teams. In the two and half years since I left Netflix, I’ve been talking to lots of enterprises who’ve been trying to figure out, how do we apply the lessons here to an enterprise that’s much bigger, much more complicated. Maybe government organizations, which are low trust organizations. Say, well you have a small group that has high trust, and you really want them to be co-located and own a thing, and then have a trust boundary to the other parts. You can have low trust across those boundaries.

[14:18] It’s really no different to programming on the internet. I can use an API from Google or Twitter, or wherever. I don’t necessarily have to have a high trust, and know the people that implemented the Google Maps API to use it. It’s just an API to a thing, and I assume a stable API. You build your organization out of a series of stable APIs, and because they’re people you can go talk to, you can maybe mutate those APIs a bit more readily, than if you go ask Google for a new feature for Google Maps. You’ve got a bit more leverage, but you should be treating these things as stable interfaces between parts of your company to build everything out.

Systems Are Flexible and Simple. Rules Are Complicated and Rigid

What I’m really saying here is that if you build purpose driven cultures, and systems thinking based approaches, that you’re building flexible models for building companies. You’re building organizations that can evolve as technology moves on. The more rules you put in, the more complex it gets, and the more rigid it gets. You end up with the sort of scenario, we have version two of the company architecture, and 3 years later, there is huge piece of work to try to get to version three of that architecture. A few years later, a huge project to get everybody to version four of the architecture. That’s an old, rigid based way of thinking about it. What you want to do is build an architecture that’s continuously evolving. There’s no actual version of Netflix. There’s no version of the system there. It’s a collection of hundreds of versions, that are changing all the time.

You Built it. You Run it.

[15:50] One more sort of thought here, there’s one things that you can do if you’re trying to get to this kind of model. One systems thinking sort of trick to try. This comes from one of the first things that we really took to heart in 2009 when we started looking at that. Which was Werner Vogels, in 2006 published an article on the way that Amazon was doing stuff. He said, you built it, you run. If you built some code, you’re on call for that code. If you do nothing but put your developers on call, it will make the biggest difference. It’s the place to start. Magically developers start writing reliable code that doesn’t break. They don’t push stuff to production on Friday afternoons, because they want to go home for the weekend and not have to deal with broken things. You’re sending the pain back to where it can do the most good. If you put an ops team in charge of production, and sort of throw it over the wall and it’s their problem, then you’re giving up on that feedback loop. It’s very powerful, and it’s one of the things we did.

We went from a monolithic architecture of everyone wrote a Java file, and QA mashed it together into this big monster. Every two weeks we’d try to get this monster into production, which would usually take several days of debugging to get the thing to work right. To everyone that was delivering a JAR, now delivered a service that incorporated that JAR with an API, and you could manage, you were on call if that service broke. That was the transition that we went through. It cleaned everything up enormously. That’s how I think you can simplify the way that you run your organizations, and take some lessons from the cultural changes there. I’m seeing lots of large companies doing this. This is not just a unicorns get to do this. Really, everybody is doing this now. The people that are being successful are doing a good job of it.

Simplify the Things We Build

[17:46] Let’s talk about the things we build. How can we simplify the products we’re trying to build, and how do we decide what even to build? One of the first things that I suggest you try to do, is to get away from thinking about projects, and start thinking about products. Unfortunately if your title is Project Manager, that’s not a good time. See if you can find a company that hasn’t done this yet, and go work there for awhile while you’re trying to learn to code of something. I’m sorry, they’re really aren’t any Project Managers in this new model. The ration of productive developers to overhead staff that are involved in managing and delivering stuff radically changes. You have more developers and fewer people doing deployment and management and delivery. That ratio has to change, because your competitors that have figured this out have already changed that ratio. That’s kind of the bad news, I feel like.

From Project to Product

[18:46] The thing about a project is you form a team and go do something like upgrade SAP, or here’s sort of my horrific thing, you spend 9 months desperately trying to get this thing upgraded. Then everybody runs away from the project in horror and goes to work on something else. Operations is left holding this thing which is no longer able to change. They are locked into it, and they are locked into that vendor and they cannot get in. If you are in a product environment, where your team owns a product, they own the continuous evolution of that product. They are continuously unlocking it. They are changing from one tech version of a technology to another. They are switching out one API to another, they’re switching from one technology or hardware platform to another at small, incremental changes in the evolution of the thing you’re building. It’s very hard to get locked in. In fact, I have a whole talk I did on this where I pointed out that basically, developers don’t care about lock in, because they’re continuously unlocking anyway. It’s the ops people that get stuck with the thing that hate lock-in.

This was actually last summer, I basically pointed out that it was kind of like the developers were dating and getting married. Then the ops people were dealing with the divorces. Then you say, why don’t ops people like lock-in? Divorces are not nice things, right? If that’s your general experience of technology, is you’re trying to unlock yourself from it, it’s a very unhappy thing. If the developers are on the whole life cycle, they’ll just keep dating. They’ll never actually get that locked into a thing, and they’ll keep unlocking from it. The analogy gets a bit stretched here, but you get the general idea. That’s one of the reasons why this is such a powerful move, you’re building a team that owns a piece of the system that is continuously evolving that system. If that piece of the system stops evolving very rapidly, you just put it in some maintenance mode. You still need somebody that owns it, because they’ll be a heartbleed bug or something, and you’ll have to go and rev it with some new base components or the platform will change underneath it. Even if the business logic doesn’t change, the platform is going to continue to change. Somebody needs to be responsible keeping it working.

That’s one thing. I was at the CIO summit yesterday, I was wearing my jacket. I don’t always wear a jacket, but if I’m pretending I’m a CIO kind of person or something. I notice that everyone else is wearing t-shirts on stage, but I decided I just stick with this.

Time to Value

People are saying what is the thing you want to optimize for, what’s the metric? The one I think people should be optimizing for it time to value. If you write a piece of code, or you build a thing, and it’s not reached the customer yet, it’s not added value. How quickly does the thing you did get in front of a customer so you can find out, does it work, does it add value. If you’re in a hypothesis testing environment, is this hypothesis now in test mode where you can find out, is this version of the signup flow got a better conversion rate than the old version, or whatever you’re working on. Figure out how to build a value chain, all the way from the customer down through all the different components and dependencies. Figure out how to get a better time to value on it. That’s the really interesting thing.

Optimize for the Customers You Want to Have

[22:06] Another thought, and this is something that’s a little subtle. Optimize it for the customers you want to have, rather than the customers you have now. What does that mean? Just take the example of a SaaS application like Netflix, you get a month’s free trial, and then at the end of that month, they’re saying please give us ten bucks. Please stay on and be a customer for another month. Almost every test that Netflix is optimizing for that conversion from free trial to paying customer. If you’re in a SaaS business with a free trial, that’s what you’re optimizing for. What you’re actually optimizing for is for customers who’ve never seen the product before. That causes the product to stay simple.

Going back to Netflix, they just launched globally. If you live in Zimbabwe, and all of a sudden there’s this thing called Netflix you’ve never heard of, and somebody’s trying to explain it to you, the more complex and the more features there are in it, the more confusing it will be. The harder it will be to figure out, and the less likely you are to sign up and to convert to a paying customer. There’s a built-in feedback loop in here which keeps the product simple. Power uses are always annoyed that there aren’t all these clever features that they keep thinking of that Netflix should do. You end up with Word or something, millions of features that no one knows how to use. Unless you’re a lawyer, lawyers know how to use about half the features in Word. That’s the power thing that they do, redlining documents.

[23:44] Think about this, if you optimize for the customers. Sometimes the business you’re in, you have a fixed set of customers. You’re not actually trying to grow, you’re trying to extract more value or hold onto a customer base. Yes, you should optimize for the customers you want to keep. If you optimize for your power users, the product will get more and more complicated, and you will mysteriously discover you will get fewer and fewer new customers. You’re basically painting yourself into the corner, where you’re going to get disrupted by the next simple product that doesn’t have all your features, so why would anyone care about that? It’s missing all these features. Well, that means that people can figure out how to use it. Think about that as how you should be simplifying the things that you are trying to build, and optimizing for the customers you want to have rather than the customers you already have.

I talked about the product itself, about how do we build these products. You get to drink again now, here’s another microservices thing. Monolithic apps. People say well they look simpler than microservices, so actually they’re more complex. They only look simple from the outside. If you draw your architecture diagram with one box on it, that looks simple. Then you look at the number of things it’s talking to, it’s obviously not really simple. Then you try to look inside it. One of the things we did at Netflix once, was we tried to create an object hierarchy of our monolithic app. I think there was a line of queue about as wide as this stage, there was 8-point font. The object hierarchy was wall papered on this thing. Bill Jackson is somewhere in the audience, he went and built this enormous object hierarchy so you could see just how complex this thing was inside. It was just massive layers of Java methods and stuff.

Microservices Enforce Separation

What happens when you break it into chunks? You find out how tangled together it is when you try to break it into chunks. Microservices enforce a separation that makes it less complicated. If anyone ever says microservices are too complicated, no they’re not. They’re less complicated. Fight back, argue back on that one. You’re isolating things, you’re preventing methods from creeping in and gathering data where they shouldn’t be seeing it. You’re preventing end runs around methods to go into the data store. You can see what the real connectivity of your application is.

[26:02] Then think about onboarding a new engineer. You’ve hired somebody from outside, they’ve never seen the system at all. You say, okay change this monolith. What’s the probability that they’ll get that right? It’s a lot of stuff that they need to learn. When you say, change this microservice, it’s got 3 inputs, it’s got 2 dependencies. It does one thing. The code can fit in one engineer’s head. They sit down, and they go okay, I’ve changed this. I’ve safely modified a piece of the system, because it’s this bounded context. It’s a simpler thing. It’s simpler to learn, it’s simpler to get people onboard, and it’s simpler to manage.

The problem back in 2009, 2010 is the tooling, the monitoring systems couldn’t deal with it. All right, we were trying to build a monitoring system that could deal with a microservice architecture, and they were blowing up. We had to build our own, and it just got too complex. I went to the expo today, and we have monitoring vendors saying yes, microservices we know how to monitor those things. The tooling is now there. They’re now much easier to deal with. Don’t get the push back that it’s too complex.

Four Principles to Keep Architecture Simple

If we’re trying to build these architectures, so how do we keep the architecture simple? There’s four principles I like to encourage. One is symmetry. Every time something is more symmetric, effectively you’ve created an invariant. If you’ve deployed in more than one region in AWS, and you’re deployment is exactly the same in an automated manner, you’ve created a symmetry. You’ve now got an invariant. It’s going to behave the same way. You don’t write the different set of processes for dealing with this thing, versus this thing.

Commonality is important. You want to think how you’re doing it, because you still want to be evolving. You don’t want to say, I need everything to be the same. You need to look for places where you can create symmetry, because that creates invariants, and that lets you create assertions that things are in a known state. Automation is really the key here. If you know every machine in an autoscale group, or running in a thing, is running exactly the same build. The same build packets, the same AMI, it’s the same whatever. Then, you know it’s the same thing. We used to have problems in our data center where we didn’t even have the same firmware revision on all the machines we were running, and that would cause problems. You can get in some very low level problems.

The final thing is just systems thinking. Trying to figure out ways to get feedback loops that drive people to do the right things, and drive machines to do the right things. I’ve done talks in a lot of detail into this. You can go find my slideshare account if you want to get more on that. Just to wrap up a bit.

Where Are We Going Next?

What’s the next thing we’re going to be doing, and how do we figure out, how do we get there? How do we spot what’s happening? I like this quote, there’s a book on systems thinking and creating platform designing business architecture. “We see the world as increasingly more complex and chaotic, because we’re using inadequate concepts to explain it.” Once you have the concepts, once you’ve built your mental models, all of a sudden it’s no longer chaotic or complex.

Think about driving a car, there’s a mental model around driving and how cities work, and how traffic works. Once you’ve got that model, it’s no longer chaotic and complex. You can drive to work, and barely even think about driving to work. You’ve said, oh I’ve just suddenly arrived. You were on autopilot in your brain the whole way. We’re dealing with a lot of technologies, and we need a model to figure out which ones are changing fast and which ones are maybe not changing. The model I like to use is something from Simon Wardly. He divides things into things that are innovating, things that are being leveraged, and things that are commoditizing. I’ve got a link to his blog post here. If you actually Google innovate leverage commoditize, it’s the first hit. It’s pretty easy to find.

[30:03] What am I talking about here? Well, for innovate let’s go back to something that’s from 10 years ago was an innovation. You can tell it’s an innovation because people are arguing about it, and their words aren’t very well-defined. Let’s think of say something like virtual machines. When they first came out, it was controversial. Then we figured out, okay we have virtual machines, but we get VMs. That sounds like a good thing, and the tooling is starting to come together, and now you can buy them from VMware and Citrix and Microsoft, and then there’s KVM. We got 4 different implementations. Now we’re in the leverage phase. It’s a well understood concept, we’ve got lots of different implementations, maybe we have to switch implementations occasionally and we’re getting there. Then we got to public cloud, I’m using say AWS or Google, I have no idea. Is it KVM, or it’s Zen I’m told. I have no idea. It’s invisible part of the platform I’m using, there is a VM system there. It’s commoditized out, don’t care anymore. I’m not spending money on virtualization management stuff. It’s just baked into the things I’m using. Think of that kind of cycle, and where we are in things.

Innovation Stage

Right now, I’d say things like Serverless are in this stage. People are still arguing about Serverless, and what it means, and all these things. It’s a relatively poorly defined concept. Some people have still not heard of it, and what you’re seeing is pioneer adoption. There are definitely people out that doing it, but you can mostly ignore it unless it actually seems to have pushed your buttons and you want to go play with it. That’s kind of where it is right now. I’ve also called Serverless architectures monitoring-less architectures, because we can’t figure out where to install any monitoring agents for it. You’re kind of stuck.

There’s a number of places where this has got some really interesting characteristics, we’ll go play with it. That’s a fine thing. Even beyond the innovation stage. What’s the opposite to a microservice? My opposite it a tera-service. You can actually sort of almost, it’s not quite public yet, but both AWS and Azure have multi-terabyte instant sizes coming. They’ve announced them, and they haven’t quite got them out yet. For $14 an hour, you can get a 2-terabyte machine with 128 virtual CPUs running on it. For $14 an hour. I just want to see what people are going to do when they finally get their hands on that thing, because it’s going to be amazing. It’s even harder to find, but Asur has a 3-terabyte one. They were announced around SAP, for the SAP Hana product, which is the new memory system. They are going to be generally available. Think of that as an innovation that’s still out there, hasn’t quite happened yet. I’m just trying to put a label on it, call it terabyte scale services. Forget these tiny little 10 lines of node, I’m trying to figure out how to run a 2-terabyte graph database in memory or something. That’s what I think is interesting at the innovation stage. It’s going to be, maybe next year. In a year’s time there’ll be people talking about these things that they’re able to do, that they weren’t able to do.

Leverage Stage

[33:14] If you look at the leverage stage, people get the concept. We know we need to do this thing, we pretty much understood it. The terminology is no longer controversial. There’s too many choices. How many different ways are there to schedule a Docker container right now? It’s just ridiculous. Every week there’s another one, probably. You can do it with Cloud Foundry, you can do it with Kubernetes, and Swarm, and Nomad, and Mesos, and I’ve probably forgotten two or three of them. Too many choices, but you’re getting mainstream adoption. This is where you have to be able to continually evolve, because maybe you pick one for now and then another one hits 1.0. Yesterday Mesos hit 1.0. Okay, maybe we should be using Mesos now. People make decisions as things mature. Maybe the best option moves around as they add more features. Eventually, they all end up having the same feature set. There was a Twitter discussion yesterday, because Kubernetes is now going to add frameworks, and Mesos is added pods. Swarm or Nomad, bundled everything into one process. Things are getting to the point where people are kind of figuring out what is the feature set that matters on this platform. You can get it all jammed into one thing, and then it starts to become a commodity.

Commodity Stage

At the commodity stage, you just stop worrying about it. The point about commodity is there is multiple, compatible implicators. I have a container that needs to run, and they don’t care who is running it for me, they don’t care whether I’m running it under Cloud Foundry with Diego, or I’m running it on Google Container Engine, or Amazon ECS, or on Azure. I just don’t care. That’s the commodity level, and we’re not quite there with container schedulers. I think we’re getting there with platforms now. This is really good to see. This is the SpringOne platform conference. We have Cloud Foundry, and we have the Spring Cloud Spring Boot stuff. It’s just there. If you’re doing Java, there isn’t really anything else out there that’s got this level of support. That’s just going to give you all of this stuff. You don’t need to go build it yourself anymore. You need to build on top of it. You need to go build something interesting that is your product, that is going to be the next generation thing that adds your business value. If you decide you’re going to do a microservices architecture, I published one time a little thing with boxes for every different piece of the architecture. You could spend 2 weeks trying to figure out what to put in each of those boxes, or you could just say let’s just do SpringBoot on Cloud Foundry, and use a bunch of those Netflix projects that got bundled into it, and move on to the discussion.

It’s scaffolding. It’s kind of like Ruby on Rails. The rail system is scaffolding so you don’t have to think about this. You can build stuff really quickly, and get on with your life. I think it’s great to see these technologies, that we were pioneering 5 years ago, turn into something that is just now an ubiquitous platform that you can just go use, and build new innovations on top. I’m just really interested to see where this goes. It’s not that the platform stops changing, it’s continuing to evolve. It’s evolving as a commodity with lots of competing implementations, and lots of suppliers, and you’ve got a market here. I’m very encouraged to see that. That’s basically it. I’d like to thank you and get Andrew back up here. Thanks so much.