Tech Talk: Making Sense of it all with Adrian Colyer

Table of Contents

For our featured tech talk this week, we travel to London where Adrian Colyer, Venture Partner at Accel and Advisor to ClusterHQ, delivered the closing keynote at ContainerSched. In his talk, he discusses what organizations are seeing in the adoption of container technology and the state of the market according to several industry leaders. Thank you Adrian!

The full transcript can be found by scrolling down and the video recording is available via Skillsmatter. We hope you enjoy the presentation as much as we did!

Making sense of it all

Presented at ContainerSched 2016




I fear I may have over-promised already on the title slide, but we’ll have a go in making sense of what’s going on. Normally my introduction goes something like, “Hi, I’m Adrian. Let me tell you about this great paper I just read,” but today’s a little bit different because I’m going to try and put everything in context. We need to do some of the small print first.

I’m a venture partner with Accel based here in London. It’s my day job there to help find and build great technology companies in Europe, which is actually a ton of fun. Accel is an investor in some of the companies in this space, particularly ClusterHQ and CoreOS and Skipjaq and Sysdig and Weaveworks. I’m also an adviser to a few companies I’m going to talk about, to Atomist to ClusterHQ to Skipjaq to Weaveworks, and some other players relevant to this space that I’ve had involvement with. I’ve previously had CTO roles with SpringSource, VMware and Pivotal. Now you know my biases, et cetera.

I said, “Well, what can I tell all you guys to make sense of it all?” How do I make a summary? I could do the high risk strategy of just arriving at the conference with nothing, listening and trying to do a summary. I thought I’d be a little bit more prepared than that, and so what I actually did, it turned out to be a wonderful excuse, so thank you to [inaudible] for setting this up for me to phone up a bunch of people and say, “Tell me, what are you hearing? What’s going on? What’s happening in the marketplace from your perspective?”

I’d like to say a few thank yous to a few folks that graciously gave me their time. A long list, Derek from Apcera, David from Atomist, Deepak and Aaron, who run the AWS ECS Service, John Gossman, who built the Azure Container Service and runs that team, Michael and Mohit of ClusterHQ, Scott Johnston at Docker, who gave me some great information, wonderful call with Don Duet and Devin Redmonds from the Goldman Sachs team. Don is head of technology there. David Aronchick, of course, from the Google team, Sam Newman, James at Pivotal, Fintan from Redmonk, a few others, Rob at Skipjaq, Joe at VMware, Alexis and Mathew from Weaveworks, and some of my colleagues at Accel.

What I tried to do is just talk to all these folks, find out how they thought the market was going, what they were seeing, and synthesize a coherent story. The good bits are theirs, the opinions I’m about to express are mine, it doesn’t imply that they endorse them, I take blame for all the bad bits, but thank you to all these folks who graciously gave their time in helping me to put the story together.

[2:40] I always think it’s really, really helpful if you’re trying to understand something to start with why. I want to begin there with, actually, what is it that customers are trying to achieve? Why are they interested in all of this stuff in the first place? That’s a very powerful place to begin because it really lets you understand what’s important, what’s not important, what the blockers might be and how things might move. I spent a lot of time asking people, why do people care? What’s interesting? What is it they’re trying to achieve?

Then the second part of this talk, I’ll talk just a little bit about the state of the market, so where are things at, what are all these folks seeing that their customer bases? What’s happening? Et cetera. Then go a bit more speculative in the end, what’s next? I revamped a bunch of that last night actually to teach you not just what I think is next, maybe how I think about what’s coming next, so the way that I structure my thinking. We may not get all the way through the bitter end of that. We’ll see how we do for time. That’s just fine. We can always hang around afterwards.

“Move quickly, but safely”

Let’s start with why. I talked to a whole bunch of people and three things actually resonate really strongly when you talk to people about why is anybody caring about any of this stuff we’ve been talking about. I think David Aronchick had one of the nicest phrases for the dominant drive that everybody’s seeing is, people want to move faster, expressing it in various ways, but I like this, “Move quickly but safely.” I want velocity, but I don’t want to just go careening off the cliff. I want some safety around it. How can I do that?

You’ve all heard the stories about the pressures that organizations are under and the need to compete with startups and to move quickly and to drive the feedback cycles. That’s really being onboarded and people have this Number 1 pretty much across the board. This is the thing that came back as what’s driving a lot of what happens. That has a ton of interesting implications. We’ll talk about those.

Platform portability

The second reason that comes out pretty strongly, not quite equal weight but it’s strong, is this notion of platform portability, one I’ll drill into in a minute and touch on why that is and what’s happening there, but looking for some layer that gives you insulation as you move across different runtime environments. Very, very strong.

Cost efficiency

The third reason which comes up but is in the “oh, and this is nice to have, and it’s a bonus thing, I’m really glad we’ve got it, but it’s not the Number 1 driver” is resource efficiencies/cost efficiency/utilization. For me, these three things came across pretty strongly and pretty uniformly as what people were seeing.

Scott was very kind to share with me some of the Docker materials that they share with their customers. This is from Docker’s own customer materials. You can see actually they’re hitting on the same three themes. They’ve got agility, they’ve got portability and then control, which in this case is all about utilization and efficiency one, two and three. Their kind of story is, “You don’t have to choose; why don’t you have them all?”

ClusterHQ survey

Also I’m very pleased to be able to share with you, as well as talking to all those people at all those companies, ClusterHQ have been running a survey, the results of which are not revealed yet, but they’ve got over 300-and-something people who’ve now responded. They kindly let me share some of the preliminary results and gave me access to them for this talk, so this is somewhat recent data.

[5:55] They’ve been asking, “What’s the main reason your organization is running container technologies at all?” Increasing developer efficiency and supporting microservices come out as the two strongest answers. They are both strongly aligned with speed of delivery for me, so that’s a strong endorsement around the “We want to go quicker.”

Scott Johnston said this really interesting thing. He said, “Look, in the first half of 2014,” which seems an age ago now, but I do remember that, “we thought the market was going to be driven around increased utilization,” around these efficiency drivers, “It turned out the real driver was speed.” Market has coalesced on this as the driver.

Let’s think about speed. Strange thing, I like to use technical understanding and translate it to organizations. I found that helps me tremendously as a lens to look at it. When I think about agility, velocity, whatever, I think there are two components to it: “How fast can you deliver software?” that’s a thing we primarily think about and I’m going to focus mostly on, and, “How fast can you respond to runtime requests?”

Components of agility

We could break that down into three things that, as technical folks, you might relate to, which is latency, which is all about end-to-end, how long does it take, in this case from when we got an idea for a new feature to when it’s actually running and delivering value, so what’s my delivery pipeline, but also what’s my value chain, including the people and the issue trackers and the assignment of work and everything involved in that.

Then we can think about throughput, which is not just how quick can one thing go through but how much can I do in parallel, because that’s going to affect how much software my organization can deliver. That’s an interesting function of how we structure our teams and the architecture that enables that team to be structured in certain ways. It’s a lot to do with how much we can allow work to progress in parallel and how much collaboration we need.

Then if you’ve got latency and throughput, we might also be interested in, and how well as we get bigger and our organization grows to that scale. Can we keep on delivering faster and faster? Scalability always pretty much turns out to be about two things, which is about contention, so how much are we bottlenecking on the same shared resources, like for example, does everybody have to get in on the same release of the monolith that’s happening on a three-week timetable? It’s about coherence, which is roughly about, how many people’s PCs do we need to get to agree on what we’re about to do?

If you pull that together for the customers to achieve what they really want, you find that no one of these things on the bottom is actually sufficient on its own. You actually need to get a whole bunch of practices from CI/CD, from the DevOps culture, from microservices, architecture, containers, cloud, et cetera. These all have to come together to actually give the customers what they want.

One of the interesting high-level takeaways is, I think the real tipping point will come when the enterprise can see, wow, we are really getting dramatically obviously faster, and that requires a lot of pieces to come into play. If you think about what happens to many people now and it’s like, “I want to go faster. Therefore, microservices. Therefore, containers. Therefore,” blah blah blah, and what they actually do is grind to a halt for six to nine months trying to make sense of it. They don’t go faster at all. We really need to get to the top of all of this.

Docker: driving force behind modern app initiatives

You see the same thing, again, in the Docker surveys coming out, which is, look, there’s Docker itself and their perspective obviously at the center, but then you’ve got the DevOps and the cultural pieces, the approach, you’ve got cloud, you’ve got microservices all coming together, all these themes that make sense.

Understanding portability

Eighty percent of people are saying Docker is central to their cloud strategy or containers. That’s interesting. Let me drive into why portability pops us as Number 2. There’s this thing called public cloud, which I’m sure some of you have heard of, and the interesting thing about adoption of the public cloud and other technologies like this, they tend to follow an exponential path, is it looks a bit like this rather crude sketch I’ve done on the right-hand side here, which is that for the longest time it looks like steady linear adoption while we’re starting from a very small base. Then all of a sudden, you kick on to the red curve and you realize, oh, it wasn’t linear after all, actually this thing’s really rocketing off, and it feels like there’s a sudden phase transition and it’s just the nature of these things that double and have exponential growth. This really interesting change is happening.

[10:24] It wasn’t that long ago, I talked to organizations and it was big, serious, responsible, grown-up organizations, “We think the cloud’s interesting, but we can’t move to it because …” maybe a list of reasons, security, regulation, data, blah blah blah blah blah, and it’s flipping. It’s flipping to, “Damn it, we’re going to the public cloud, so find a way to solve these issues.” When you start to flip like that, then you need something that gives you this portability.

The drive to the cloud

This is something that Don Duet, the Head of Technology for Goldman Sachs, so a very progressive, forward-looking organization, says actually pretty amazing things. “Our goal used to be able to be 100% on the public cloud,” or at least to be able to run any of their workloads on any cloud, and public cloud is one of those. As he nicely put it, “This is just obvious,” and had been obvious to them for some time, and they’re working on this strategy. “But we can’t be only on one public cloud.”

The enterprise is wary of these kind of things, and so they don’t want to lock themselves into, for example, an AWS-only choice forever more. What do you do? You have to find this portability layer. The drive to get to the public cloud raises a need for something that gives you a layer across it, which brings in this whole container ecosystem.

Many people I talked to said, “You know what customers are going for at the moment? They’re saying, well, ‘We got to make sure that we can run on AWS. Then we’ll pick one other cloud provider to make sure that we’ve got some kind of portability we’ll at least test on that, and of course I’ve got my datacenters.’” This is the kind of enterprise reality where they may be in transition, they’re going places, but this is the world they’ll be staring at, and this is why they need something to take some of the friction out of that.

While I was just preparing the talk, it reminded me of the scale. This is Werner Vogels saying, “This is my room for meeting with press and customers. Not a small office anymore. Now I do it in a big theater.” It’s just a reminder of the power- There’s something about seeing the empty room rather than a sea of faces. It’s really striking. That’s a lot of customers and press interest, so this thing’s really happening.


[12:35] There’s this great symbiosis that happens, which is, containers are this portability layer that gives people the freedom to start thinking about accelerating their moves to the public cloud. The drive to get onto the public cloud, to be able to run on any cloud, is fueling the adoption of containers and there’s this lovely symbiosis.

I spoke to Scott at Docker and he said to me, “Look, we’re finding that there are these massively-funded cloud projects in all these organizations and we’re just attaching to them left, right and center.” This drive to the cloud is causing an adoption of containers, so that there are several conversations.

The first was really interesting. I spoke to John Gossman who runs the Azure Container Service, and actually their whole way they approach it, their whole design was to say, “Look, we’ve really got to put open and the standard at the very forefront of this,” because they recognize, I think very intelligently, that this is actually what was important to folks, and so it goes really deep.

Rather than writing their own schedules and orchestrators, they went straight into partnership with Mesosphere and Docker. They actually went Linux-first rather than Windows-first. As far as they possibly can, the Windows support is actually being done by contributions back to Docker. They’ve really embraced to what the customer’s after.

As John said, “This is really important because everybody wants an open system without lock-in.” We really have trained the big enterprise, which is the early majority, the late majority customer, which is the thing that makes this market tip and brings in all the revenue for all the vendors in the room. They’ve been burnt by this over the last two decades. They’ll well aware of these problems. It’s really interesting to see how that set the whole strategy.

Foundations and (anti-)lock-in

Of course, the other thing we’ve seen related to this is the rise of foundations, another way of giving anti-lock-in. It’s been interesting. Single-vendor open source is the new proprietary, basically, if you think about it. For some of these really important industry shared layers, there’s this push towards foundations. I’ve been involved in having to create some of them for my [inaudible].

The CNCF, the CFF, that’s the Cloud Foundry Foundation, the OCI, et cetera, they do two things. One is that they actually give the vendors themselves a safe place to collaborate. Suppose you’re IBM and you really want to throw your weight behind a project like Cloud Foundry, but every single committer is employed by Pivotal and it doesn’t feel quite right to trust it. It’d be much nicer if that went to a shared foundation and then everybody could align and they could collaborate on it and feel safe that no one company could run off with it.

Of course, it gives adopters additional assurance that this is not something where any one vendor can suddenly turn the steering wheel in a certain direction, but there’s some broad industry base here. These things are really important.

[15:25] I could pick almost any foundation and give you the logo slide, and there’s a ton of logos for all of them. They’re a great collective, but it’s a good collection of organizations, including Goldman Sachs here as an end user, who are, I’d say, quite forward-looking. This is the CNCF, the Cloud Native Computing Foundation, and I’m going to assume that you guys have some idea what that’s all about.

Case study: Goldman Sachs

In the wire then, just a few little mini case studies. Apologies, for me keep looking around. For some reason, the slide on my screen is about one inch by two inches. I can’t read it at all. Goldman Sachs, I spoke to Don. He did a lovely presentation at the European Tech Founders Summit recently. I think this is interesting.

It’s a big organization and there’s three key initiatives. One, improve the velocity of change in the organization. That fits with what we were also hearing in the container ecosystem. Number two, move from private to public infrastructure, enable that change. Number three, move from proprietary to open, so start embracing more open-source components, less proprietary middleware, et cetera. I don’t think any of those would be a surprise to any of you, but it’s fun just to see it netted out as one, two, three, all these trends we’ve been talking about.

The scale of the challenge is an interesting reminder, though. We see startups, and I’m going to give you a small startup example next, but this is trying to turn around an organization with about 8,000 technical employees. That’s a lot of two-pizza teams, but I said, since we were riffing on two pizzas yesterday, how do you go on to Pizza Hut, Pizza Express, et cetera and ordered a pizza? And eaten it? So is that like a two-person team. Anyway.

Eight thousand people, which is a huge change to getting in this new way of working. That’s going to be a lot of teams. About 5,000 different applications. These are Capital A applications, i.e. complex things. With about 75,000 database instances, a lot of data growing fast, running over at 165,000 servers.

They’ve already done a great job of getting most of this actually working on an internal cloud-style infrastructure, so it’s just some of the last challenges in terms of being able to get this out onto public cloud around some of the security and other things that they’re aggressively working on. They’re collaborating with the cloud platform vendors, et cetera and really pushing on this.

It’s interesting to think about this scale of challenge. The interesting thing that I really loved about this conversation with the guys at Goldman Sachs is that they’ve actually gone to the next level and they have I call it an application modeling layer. They’ve got a definition of the application that involves things like its security policies and other sorts of intense stuff around it.

The next level of maturity that Derek Collison also talks about a lot, if you’ve seen any of his talks, and from that, they’re able to actually deploy not just containers and not just in one kind of framework but also databases and all kinds of other things in a whole variety of formats. It’s a uniform, overarching system that’s got application modeling and ability to deploy a lot of different things. Really interesting to see an organization of this scale move this aggressively.

_Case Study: Skipjaq - Docker + Kubernetes

At the smaller end, this startup I’m involved in called Skipjaq, wonderful CTO there called Rob Harrop. We’ve worked together for years. They’ve recently completed a migration to a full container-based infrastructure. I asked him, “Why did you do that and how was it?”

Why containers? One of the things we’ve heard, they have to run across AWS, Google, Azure, vSphere because they actually do optimizations on all those platforms. They wanted something that would work across all of them. It’s that portability bullet. Really like the fact that the topology is separated from the packaging. That’s quite important to them, so they can run it in one configuration with everything on just a small number of machines or they can spread it out, whatever they need to do.

[19:24] They picked Kubernetes. Why? Because, again, portability was really important to them at that layer, say, for example, they didn’t choose to go with ECS. Rob was particularly complimentary about the pluggability of Kubernetes, the way they could wire in the various other things that they needed underneath it.

This is better than I remember it. I remember six, nine months ago people saying, “Wow, Kubernetes is really complicated. It’s really hard to get started.” Actually we did it in about two weeks, which I think is good testimony here. So the full stack running in about two weeks and seven weeks to get the full integration up and running. We’ll see some other timelines in a minute about how long big enterprises take, but that’s pretty quick for a small enterprise, a small startup.

What does it look like now? Now it’s containers end to end, basically, so starting from the developer desktop all the way through to production, with all the platform-specific bits isolated. Maybe they’re still in the honeymoon period, but super happy with this little migration and pickup.

Case Study: Atomist

Spoke to another startup I’m involved with, which is Atomist. Again, looking to go to the cloud, wanting something that gives them portability for that. Openness was an important criteria, it turned out, and their evaluation, which led them to look at, in this case, Kubernetes and Swarm. They ended up choosing Kubernetes where they feel that it was a little bit more ops-biased and Docker was a little bit more developer-biased in this team, so they went that way.

Really interesting to see those kind of little case studies. From the very large to the very small, people are looking at going through this transformation.

State of the Market

[21:00] Let’s talk a little bit about the state of the market. This is the section in which I realize, whatever your preferred technology of choice is, there’s a slide where you can take a picture and tweet it and it’ll look like the world aligns with your viewpoint. I just realized that incidentally afterwards.

Because the thing that really struck me after talking to all these people is that everybody is winning. That’s a really key takeaway is that actually this whole movement is bigger than any one company. Everyone is doing quite well as this thing starts to grow. The size of the pie that’s in front of us is always way bigger than it is now. I encourage you all to think about helping the overall movement go forward rather than fighting over the small piece of turf that we have now, because everybody’s winning. It’s very clear when you go and look into this.

Containers are very much in production. Numerous, numerous, numerous stories of people, currently we work with people who are actually doing real things in production. Not everybody, but it’s increasing. There’s a clear trend. Importantly to me from an investor hat on, revenue is starting to flow. Companies are actually making money, which is good news. I would say the typical journey for the enterprise, and not the little startup that can do it in seven weeks, is roughly, asking a few people, 18 to 24 months. I’ll go into what that looks like in a moment.

Everyone’s winning. Docker are doing quite well. They have about just over 10,000 paying customers on their cloud platform. Docker DataCenter are really impressed, over 75 Fortune 500 customers already using that inside their enterprises. I’m taking paying customers as an expression of serious intent here, so I think this is a really, really healthy sign.

They’re doing really well and they have a thriving ecosystem of logos that you can’t see, but that’s the point of the logo chart, isn’t it? There’s just so many you can’t take them in. They’re doing really well, unexpectedly. I’m sorry, expectedly, not unexpectedly. You just edit that bit out. They’re doing really well expectedly. Solomon will never forgive me.

Kubernetes is on the rise

If you like Kubernetes, this is your slide. Kubernetes is on the rise as well. This was Chris Gaun. I’m sure many of you have seen this saying, “Hey, look at stack overflow questions,” which is either an expression that Kubernetes is more confusing than everything else and so you need to ask lots of questions or there’s a rise in interest. I’ll leave that to your imagination, but there is some other data that might help us.

For example, if you look at search interest comparing Kubernetes, Cloud Foundry, Mesos, Swarm, sorry to the other frameworks that didn’t make this particular chart, you’ll see an interesting trend for Kubernetes. Also I really took notice that the Slack channel membership has doubled in three months. That’s actually really impressive. Doubling every three months is serious growth if that continues.

It’s interesting, if you take this particular chart, I wanted to recreate it just to have a look, so I went off to Google and Google Trends and, that’s the same chart, you saw it before, interest over time, same line, same trajectory, et cetera.

I just observed, by the way, that of course they’re looking at Docker Swarm versus Kubernetes, which is a reasonable comparison, but yet, look, if I add another term, just to remind you, this is what the interest in Docker is. For many people who are not living in the bubble that we live in, container equals Docker. That’s the first word they’ve heard of. Everything else squashes, so they just don’t know how to put things in perspective a bit.

Docker Survey 2016

Their own data, what orchestration framework, see, roughly even split between Swarm and Kubernetes, which I actually think, given what you just saw about the prevalence of the Docker brand and mindshare, it’s actually quite impressive to see Kubernetes score so high. That’s in their own survey.

ClusterHQ Survey

This is the ClusterHQ one which, again, is coming out, have been asking a similar question saying, “What do you see people using?” Internally-developed tools is Number 2. We’ll come back and talk about that. Kubernetes and Swarm, 1 and 2, then ECS, Mesos, et cetera. You can take your own pick of surveys. You can take the polls from what you’ve seen over these last couple of days, but you’re getting some of the main names and definitely Kubernetes is showing pretty well here.

Containers are in production. Again, a Docker survey from 2015 had about 40% of respondents saying they had something in production. The ClusterHQ number from their survey seems astonishingly high. Obviously it’s a sample of people that are already likely to respond to a survey about containers, et cetera, but definitely showing that more people are moving into production now or got at least something in production.

The testimony across a number of these vendors I spoke to all correlates with this. There really are people who are moving and getting to this next phase. Actually, that fits with the timescales that people were telling me about as well.

Amazon ECS

[26:11] This is what Deepak Singh was gracious to spend some time with me. “We’re seeing a growing number of customers across these industries that are healthcare, media, et cetera, entertainment that have embraced Docker and are going into production on the ECS platform.”

Interestingly, the story behind ECS is not like, on, there’s this bandwagon, “Why don’t we build something and see what happens?” In the classic AWS way, they built ECS because they were getting traction and demand from their user base for something in this area. It’s that way around, not the other. They’re already focused on unsurprisingly container management, scheduling, but deep integration with the AWS platform. Makes a ton of sense if you’re them.

A couple of examples of people in production there that shared with me, Linden Lab, Second Life, doing really big deployments on ECS. At the other end of the spectrum, you’ve got the Empire platform from Remind, I think it is, which is a good example and something that Kelsey opened with. I think he said like “everybody that starts to build on top of Kubernetes, et cetera ends up building app engine or Heroku.” That’s actually exactly what these guys did, but on top of ECS they built a Heroku kind of clone.

Healthy partner program, lots of logos. We can do this in many, many ways, but it’s interesting, it’s not all just AWS lock down. They’re really working well with partners and bringing them onboard.

Azure Container Service

Azure Container Service, quite interesting. When I spoke to John, who actually has only been GA for a few weeks, so this is fairly recent, the thing that he was particularly pleased about was they’re already seeing sustained very large deployments on ACS, even if it was only a few weeks old, where they’re not dropping off at weekends, et cetera. Super early days, a few weeks in, but really encouraging signs and lots and lots of interest, beyond what he would’ve expected at this stage, perhaps what get up for. Again, very encouraging signs for the ACS team.

Mesos is on the rise

If you like Mesos, this is your slide. Mesos is also doing quite well, it turns out. We had MesosCon last week, very recently. Some staggering numbers from Twitter. Of course, maybe that’s not so surprising, but I picked up on a couple of testimonies from the guys at Uber, from the guys at Netflix. There’s a number of these.

[28:29] What’s really interesting to me about Mesos is the number of the users are also using it for data in particular for Spark, and that’s really interesting because if you think about ultimately wanting a platform or a layer that’s going to give you this portability role, then what good does it do you to move your applications but not have any story for your data? They go together. That’s something for us all to think about. Mesos are certainly doing well in that regard.

Microservices are on the rise…

Microservices are on the rise. Getting a theme for these slides. The interest over time is showing a nice steady growth. Yet Docker. Again, if you look at the Docker Survey, “What are you planning to do in 2016?” Build a new microservices app, migrate Legacy app to microservices, scoring very, very highly.

ClusterHQ Survey correlates. A missing number, I think it’s 36% on that one, saying their prime reason for moving to containers is to support some kind of microservices architecture.

The other very interesting thing, you know Spring Boot and Spring Cloud and all the Netflix integration is doing astonishingly well. There’s a really interesting correlation about the time that I left the team and when this started. I’m sure that’s only correlation. They’re up to nearly four million downloads a month now. Really, really strong interest and people with a hunger to build applications in this new style.

Again, this is Deepak saying that, “We’ve seen this interest in microservices and containers grow up together.” They’re intertwined in many people’s minds. These themes are interlinked, which makes sense if you think that the top driver is all about agility and velocity because you do need to embrace a collection of things.

Cloud Foundry is on the rise…

If you like Cloud Foundry, this is your slide. Cloud Foundry is also doing pretty well. There was a Cloud Foundry Summit recently, had about 2,000 attendees, impressive number of user groups and members, et cetera, 63 foundation members. I haven’t given you a logo slide, but you can imagine what it might look like. Lots of good names. I think Bridget talked on this one. This is a slide that James likes to talk about. He calls it the Value Line slide. You’ve got this slide. You only used just a picture of it. Okay, yeah. I’ll stand next to James’s slide. The thing that if you heard James’s Pivotal team give you this pitch is like, how much differentiated value is there to your business in focusing on these things below the line versus the things above the line?

The only thing I question is, why is the line so low? Because, actually, you shouldn’t be building your own Java microservices framework, either, but building your own microservices using those frameworks, yes. I want to come back to this value line idea because I think it’s quite interesting. We’ll try to later on figure out where it is.

[31:28] From the Cloud Foundry Summit, I picked out this Comcast testimonial. It’s interesting to see, is it delivering on velocity and agility? Their testimony is, it usually takes us weeks, which I think is pretty good for many enterprises frankly to get from an idea to a feature implementation. They can now do it two to three days. These are clearly fairly small features. They can scale their applications much more quickly, unsurprisingly.

Typical customer journey

What’s the typical customer journey? What was I hearing? I asked everybody like, “What happens to your customers? What does it take?” It’s a classic question to try and figure out. This is Scott’s answer. He says, “We see about 20% top-down-driven interest,” the C-suite, et cetera coming to say, we really want a platform, “and about 80% bottoms-up,” which is roughly the ratio I would expect.

Within that, how does it plan out? Roughly, first phase, the landing, tends to be an existing application, we’re just going to package it up in a container. We’re not even going to worry about microservices or do anything fancy, just all the cultural and organizational things to get something in a container with a CI/CD pipeline and actually have it flowing end to end. It takes a long time for a big company to get its head around all of this.

That’s about six to nine months. You may wonder what they’re doing all that time versus the several weeks that a small startup does it end to end, but this is just big enterprise timescales. Once they’ve got that flowing, it takes about another six months roughly on average for the enterprise to get confident enough to say, “Yes, we can run this in production.”

We’re talking about 12 to 15 months from first contact to the first thing that’s actually gone into production, which is why if you think back to how long this game has been playing out, the fact that we’re starting to see a few more first fruits making production makes sense. Once they’ve got to there across Phase 3, so as the platform phase, is when the floodgates open, and then you get top-down-driven big re-platforming project. That’s roughly how they’re seeing it play out in many customers.

I talked to David Aronchick at Kubernetes. I asked him the same question. This is roughly how they’re seeing it. Again, the land, starting with a single application, just in one data center. The first expansion there would be to do several applications maybe just within one data center. Then the final phase is starting to bridge across data centers doing the more global re-platforming project.

A little example that we mentioned was like an organization going to across four data centers and several thousand nodes, all in on their big re-platforming in about a 2-year timescale. Again, it fits with about two years to go through this process.

[34:20] Cloud Foundry example. Spoke to James. He was very good to share. Cloud Foundry is a more traditional enterprise top-down, so you’ll see a lot of C-suite messaging, et cetera. That takes a bit longer, but once the platform is in, what really impressed me about that conversation was how quickly within some organizations’ usage drives up. He gave me several examples of 500-plus developers and 1,000 applications, which is an interesting ratio, but being on the platform very quickly.

The other thing that was impressive in that testimony is customers managing that with a very, very low operations overhead, so a small number of people compared to the number of applications, et cetera that are running. Moving to these higher levels is helping customers move quicker.

I didn’t ask him what happens to the operation, but Bridget will be perfectly placed to tell you about that. The answer was that they work on running the platform and on the operability of apps, which of course is another really interesting thing we’re seeing.

With another hat on, investment funds in this space are continuing to flow. If you just look at back across the last few months, that’s a lot of millions of dollars that have poured into companies in this space. That’s just going back to March. I probably missed some, but these are some of the more major investments.

What’s next?

What’s next? Close out the session. One of the things I think is really interesting next is that we might get over our obsession with containers, actually, and that we might get back to the applications because that’s really what it’s all about from the enterprise perspective, that rapid delivery.

John’s saying, “We’re seeing this shift from containers-first to apps-first, but of course we’re using containers for it.” Deepak also confirming, “We’re really seeing the mindset shift where people first think about their app and then they think about the infrastructure.” That’s a healthy change.

Three things in this section I’m going to rattle through pretty quickly. One is a reality of the enterprise, if you’ve been around long enough, that it’s going to be a heterogeneous world. We’ll talk a little bit about what that might mean. I want to riff a little bit on the value line idea, what might happen to that and why it moves up. Then we’ll close out by thinking about, if customers really want this velocity or agility, are we giving them what they want and what’s missing?

David Aronchick said something about, what do you see, what’s next? He said, “Look, we have to accept the fact that bridging possibly multiple-cloud environments and data centers is going to be a reality for the enterprise for many years to come.” The completely all-in, immediate transitions, switch of everything you had before is unlikely.

In fact, even if you wanted to as an enterprise get to this wonderful homogeneous world, which is practically impossible, you couldn’t do it, but if you think about the Goldman Sachs sale, but imagine you’ve achieved it for a brief moment of glory, your [inaudible] will mess up the next week. You’ll do an acquisition, you’ll bring it and bang it. It’s just an impossible dream in an enterprise to be completely homogeneous.

Multi-cloud challenges

If we think about this requirement to go to a multi-cloud world, so a multi-cloud world first of all, for you to be able to run on any cloud, you do need this portability layer, we talked about that a little bit, which by definition really can’t come from or be totally tied to any one cloud vendor. That’s an interesting opportunity. That’s why we see some of the foundations, et cetera.

[37:56] By the way, I really believe a very important cloud for a lot of this technology is the developer’s laptop. That’s a very small cloud. It really matters with the bottoms-up adoption motion. Even if you’re not targeting different production environments from Day 1 through the development lifecycle, actually you get a lot of different environments from the laptop on up, there is always a reality, I touched on this before, and you need to consider not just the compute piece, but if you think back to your Infrastructure 101, it’s compute, networking, storage, those three things. How does the networking help you to join up these environments and how do you think about storage/data? It’s got to be part of it.

We don’t have time to go into it, but there’s two really interesting things intention here. One is data gravity, so where you run your apps tends to be where data accumulates, which is hard to move, and so you run more apps there and you get these clumps. The first is this idea of data agility, which is if I really want to have this portability and to be able to move things around, the data has to move. That’s an interesting other topic, but there’s some stuff to be done there.

Multi-platform? The Platform Wars

Multi-cloud world. Multi-platform world. Almost certainly. Again, I talked to Goldman Sachs who says, “We’ve got 8,000 developers. Some of them are going to use Kubernetes, some of them are going to use Swarm, some of them are probably going to use a framework that hasn’t come out yet but we’ll have done next week. We can’t top-down lock-down all of that, but what we can do is provide an overarching platform that all that fits into.”

[39:23]]There will be multiple platforms in these big enterprises. “What kind of platform?” is an interesting question. Particularly, at what level? Is this a Cloud Foundry more structured, more opinionated, higher-level platform? Is it something that’s at a Kubernetes plus plus? What does this look like? That’s an interesting question. I think we’re moving higher and higher over time.

Bottoms-up is not here a clue that now we should go to the pub, but something I think that’s really important is, when we’re thinking about how platforms get into these enterprises, thinking about those customer motions that everybody said they’re seeing, it starts with a small thing, with an app, with a team, with a few people experimenting.

I think this is key to remember. From a vendor’s perspective, does your technology work well with that model? Does it work well in the small for a developer experimenting on their laptop and can it grow from there? Bottoms-up is a really important motion, but at the same time, you’re not going to have all these 8,000 developers all doing their own thing or running their own versions of whatever platform it is, and all operating the whole thing top to bottom. That’s insanity as well.

[40:31] We’re all going to see a striation of people who operate platforms and stand them up and then people that are responsible for their applications and making sure they’re functioning well, which we’re coming to call AppOps, and in the purchasing decisions, there still seems to be a very real role for good old-fashioned IT. They are an important stakeholder in some of this, so don’t forget about that. I would say the orchestration seems to be a layer, not the be-all and end-all. We’ve obsessed a lot with orchestration here, but it’s just another step.

Deployment granularity

The last kind of heterogeneity, deployment granularity. Again, we assessed there are containers, but we’ve got a spectrum, some sort of physical machines. They still are out there. People deploying things that are packaged in virtual machines, in containers, unikernels coming, lambda even jumping over unikernels and being used right now, so that’s just deploying a function.

We’re going to see a mix. It’s not like one is going to win. In fact, interesting, again, talking to Deepak, we’re seeing interesting patterns like, for example, you might use AWS Lambda to do some of your API frontend sitting behind an API gateway, where you don’t need deep-level control, but behind that you might have a layer of containers running on ECS that you can get a little bit deeper, or maybe they go and talk to some of the big data services, talk to Goldman Sachs.

Their application modeling layer will provision not just containers in various orchestrators but it can configure and provision their databases, et cetera, and they do that in a different way, or actually, [inaudible] also had a good example of doing some marathon things and also provisioning RDS from the same uniform description. It’s a pretty safe bet that in the enterprise, things will be heterogeneous. That’s always good to remember.


[42:20] This is a little bit different how to think about it. This is my personal framework that helps guide some of my thinking. You can look at technology and how it evolves over time, which I’ve shamelessly stolen from Simon Wardley, so credit to him. Roughly, you can say a lot of things start out as a brave, shiny new idea, and then people hear about that new idea and they create one of them in-house because they’d like to have one. Then eventually, some folks open-source it. They start to build products, et cetera. You can get one off the shelf rather than rolling your own. Eventually, that becomes sufficiently standard and commoditized and it moves to the end of this cycle here.

We’re moving from genesis through to commodity over time. Once it becomes a commodity, then it’s very interesting because you can start to exploit that and build on top of it. An interesting way is it creates a new foundation for people to do interesting stuff on because they don’t have to do all the other stuff first. That unleashes a wave of innovation.

Very brief aside, this looks awfully like an innovate-leverage-commoditize play. I’ve got to exploit here because ILC is actually a very particular strategy where the person commoditizing also does the monitoring of who’s exploiting and does the next drive, but anybody could exploit, and we’re seeing that in this world. This is the basic zig. What happens is, you can guess where you see this here, this forms this zigzagging ladder over time where you get a new layer, it sediments, people can exploit it because it’s commoditized, and so what starts off with the value line down here like, “Hey, containers are a thing now. I can start doing stuff on top of containers,” becomes, “Hey, orchestration layers are a thing now. I can do stuff on top of orchestration.” The value line moves up over time. That’s very exciting.

To make this very explicit, back to our conference, roughly containers moving rapidly into the commodity end of the spectrum, probably already there, container orchestration was in genesis. If you remember DockerCon around the time of that in Amsterdam 2014, end of year, I’m just thinking back to it, if you remember that time, it was like everybody suddenly announced, “Hey, we’re open-sourcing our in-house orchestration framework.” This is great. There were like 30 of them.

[44:27] What’s happening now? The field is narrowing down a little bit. There’s a smaller pack of emerging winners. You’d be mad to go build your own in-house orchestration framework at this point in time, I contend. What happens further? Certain vendors, particularly, I would say, Google seem to be following this strategy with CNCF and all the things you see in place to drive that layer towards commodity.

Evolution: Death of the in-house framework

Here’s an interesting thing that happens. Suppose you were at this point in time when you built your in-house framework, because it was the right thing to do then because there weren’t any, and you’ve moved on and you started to build things at a higher level on top of that. It’s a pattern we also saw with Spring back in the days, so you had your in-house framework, and then you eventually get over time the death of the in-house framework.

Why does that happen? Because you’ve moved on up there and you’re building this thing, but meanwhile, underneath you, the industry or somebody is heavily commoditizing the layer beneath you, and now, what was your competitive advantage having this in-house framework has become a competitive disadvantage because you’re tied to maintaining, tending or feeding for this thing that actually there’s a much bigger community taking something else rather forward that other people competing with you are just building on.

It’s interesting how this shift happens, and I can’t tell you exactly when the moment is, but watch for that pattern and you’ve got to think about, when is it that we should get off of our in-house whatever it is you built on whatever layer and jump on the bandwagon? I’ve seen this play out a number of times. Really interesting pattern. Think about that one. What happens is of course the value line moves up and you’re now doing work below the value line, so watch out for that trap. We don’t want to be underwater.

Giving customers what they want

[46:12] What else can we do? We can come back and think about this, I want velocity, all these component parts of it, and we can pick that apart and say, if a customer wants to go quicker, what’s in this value chain? What do I need? I might need, as a culture, I might need something better, some kind of OODA loop, I might need to embrace microservices, I might need CI/CD, I might need a bunch of things. It doesn’t really matter what they are, but it’s a bunch of things that go underneath that.

If I look at what it takes to do all of those, I can go on and I can build out my value chain. I might need a high-level microservices platform, and that might depend on orchestration, which might depend on the runtime, there is the registry, and way down there there’s some IaaS, et cetera. We could take this kind of value chain.

What we can do that’s really interesting, which is the Wardley Map, is we can actually take those things and we can plot them as to their state of maturity. Just to show you, this is somehow I think about what’s going on. You can see the things that are commoditized. You can work out how the value line might move. You can see the things that are still evolving. Maybe there’s a few other things that you see on the horizon that are coming like this question of data, like policy security intents, like more stuff that really supports AppOps rather than platform ops. Those are in genesis being custom-built right now. You can look at that plot. You may argue about where I’ve put the dots, what dots I have, but the exercise is useful.

Then you can certainly say, look, we can draw a ring now on this kind of space and see this is where we expect to see innovation, excitement, hype, et cetera over the next little few years, because these are on the left of the curve, and you say, in this kind of area, we should expect to see more productization, more mature open-source projects, more things we can just pick up and use. On the right-hand side, we should expect to see a dying away of the hype and excitement. They just become something that’s there in the substrate that we all take for granted and forget the ones that were shiny.

Within that we can also look at likely movements. For example, the higher app-level platforms, I think they’re going to start pushing towards the right, and it’s a fairly safe bet. Likewise, I think we’re going to see more off-the-shelf things around the AppOps movement. Weaveworks is working in that area, for example.

I think the data question is huge. We don’t get the portability benefits without that. I’ve seen a few people starting to talk seriously about the policy layer. These are the kind of arrows and movements we might expect to see. This is a great exercise to do your own little plot and see what you make out for reading the runes.

Zero to one is still too hard

Just to wrap up for the last few minutes, some thoughts about trying to achieve that velocity for the customer. One thing that really occurs to me is what I call the zero-to-one problem is still way too hard. Many customers, they’ve got an existing monolith. The first thing they do is they extract a small little thing and that’s their first microservice. They’ve gone from zero microservices to one microservice.

The minute you do that, you get this whole bunch of problems that just rain down on you, because now you’ve got two components. You need things like services discovery, you need to worry about how you independently update them and they find each other, you need to worry about circuit breakers and, oh, my goodness, just a ton of things that actually you have to worry about the minute you take this one tiny step. Zero-to-one I think is too hard and it’s something that we should be thinking about.

Velocity vs Complexity

[49:26] The other thing that scared the hell out of me when I first drew it, you should do this as a build, we don’t have time, take a monolith, any monolith, it doesn’t seem to matter. When they get broken down, I’ve observed that they often end up in about 20 to 30 different microservices, which seems an insane amount to me, but actually, I’ve seen it a lot of times.

Let’s say that it’s roughly that order of magnitude and let’s say that per service because you don’t want to just have everything be a stateless thing. Let’s say you’ve got perhaps two to three container images per service. Let’s just say two. You don’t want to run only a signal instance because that would be a single point of failure, so you’ve got one-to-n instances for every one of those images that’s up and running, but you’re doing deploys all the time when you’re pushing out new versions and feature-flagging or whatever you want to do, so you’ve probably got one to two concurrent versions as the blue’s coming in and the green’s going out.

Maybe inside that you’ve got some feature flags. You’re doing some A/B testing or some multi-armed bandit testing. Maybe you push stuff out multiple times a day. If you just go through this exercise and you do the multiplication, it’s scarily easy for one, fairly easy to understand from an operational perspective monolith to end up with a few hundred continuously changing parts. The complexity is a killer to the velocity that you were trying to achieve in the first place, and so you’ve got to be really careful with this stuff.

Humans gets harder and harder and harder as it gets more and more complex, absolutely, yes.


The question is, do people start to automate the automations? I guess the thing that’s really stuck in my head was a conversation with a guy called [inaudible] who’s at Halo who was sharing with me his microservices experience.

He said, “Look, something happens around about I think a 20- to 30- up to 50-microservices point,” and the phrase he used, he said, “it became brutally hard and painful.” It’s like humans just can’t quite get the hang of it. Beyond that, you really do need to start doing smarter, more sophisticated things.

Here’s something else that’s really interesting is thinking about how that scales as you add more and more microservices and there are times go in-depth, but this is your ideal, as you add more, you get more throughput, and the first thing that happens is that you get contention, like in the monolith, and so you don’t quite get that ideal and you drop off the curve.

Actually there’s this other factor in the Universal Scalability Law, you can read about it on Neil Gunther’s site or on my blog, where essentially there’s this second term, the beta coefficient, which is squared in the number of things that need to communicate. Getting to agreement really slows you down over time.

I’ve actually had a CTO of a company talk to me and say, “Huh, please, do I have to do microservices? I feel like I really should, but I’ve got two people on my team who’ve done it before and they said that like, after they got a little way in, everything ground to a halt, and it was really slow and they couldn’t move.” Why is this? This is because you’re using quite a mature approach to architecture, to break something down into these pieces and not have it gridlock. You’ve got to really worry about the coherence piece.

In fact I think it’s quite interesting, you’ve seen all these proudly tweeted [inaudible] diagrams of who is my architecture. It’s interesting, if you actually look at Network and Graph Theory, there’s this Erdos and Renyi Theory for random graphs, so I’m just going to take a trite assumption that a big enough microservices thing looks like a random graph and there are all these other models that maybe are a bit more realistic.

Something really interesting happens, which is that if you start to make enough connections between the nodes and enough calls between your services, with increasing probability, it ends up that you get what’s called a giant component inside your network. In other words, everything becomes connected to everything else pretty darn quickly if you’re not careful. This is the gridlock scenario where you went into this path go quicker and you ended up going slower. You’ve got to be super careful about this stuff.

Cognitive load

To close out, I asked Sam Newman, who seemed a good authority to go talk to about microservices, “What do you think about this space and what’s happening? What do you see?” He cited another authority. It would be a shame to go through the whole talk and not mention Adrian Cockcroft, who I don’t think I’ve heard mentioned in this conference yet, so here he is.

This is his microservice architectures chart, all the things you have to think about. Sam’s observation is, look, a lot of attention has gone in these areas, which means there’s other parts of the puzzle that we haven’t really been focusing on so heavily, particularly around figuring out what the hell’s going on around state, around the actual developer experience, et cetera.

Problems that remain

I’ll leave you with a few of his thoughts. Security in microservices is a mess at the app level. Understanding what the hell is going on is actually really quite difficult. Everybody’s hand-rolling it, so we’re in the custom-build stage. Even things like knowing who the hell to talk to for a given service is hard. They don’t know who to go call. There’s not a lot being done to help developers beyond making things easier to deploy, and of course the framework stuff like Spring, et cetera is doing. Data is still a problem.

That was a really whirlwind tour. We have one minute left. The things we touched on. Start with why. I think it’s really, really important if you … If there were anything else, remember why people are doing it in the first place, because that helps you actually unlock the real value for them. Velocity, they want to go quicker, but safely. They want portability so that they can move it across different environments and avoid lock-in. Efficiency is very, very nice to have and you’re delighted to get that along the way.

[55:04] The state of the market, the interesting result for everybody I talked to is doing well, so it’s like a rising tide floats all boats. This is good news for everybody. People are moving to production. There’s a number data points across all the different services to suggest that roughly an 18-month to two-year journey. We’ve been at this just over two years in real earnest, so that fits.

Thinking about what’s next. Heterogeneity is inevitable. We don’t have to perhaps obsess quite so much on who’s going to be the winner amongst ourselves but on moving the whole industry forward. The value line moves up over time. Watch out for how it moves and think about what your strategy is in respect to that.

Remember when the right time is to kill the in-house framework. The last thought is to really deliver on what the customer wanted in the first place. We’ve still got work to do, and a lot of that work is in now moving up to the higher parts of the stack, and it’s around how we architect our applications, how we support microservices and everything that goes with that.

It’s now 5:46. I’ve kept you for 30 seconds longer than I should have. I hope you had a fantastic conference. Thank you very much. I’m happy to stay around and take questions, et cetera. I’ll let those of you that need to get home get home, but it’s been a pleasure to spend a couple of days with you, so thank you.

About the speaker

Adrian Colyer Profile Photo

Adrian works three days a week as a Venture Partner with Accel Partners in London. His duties there include forming investment theses, sourcing, helping to assess investment opportunities, and providing CTO guidance to select companies in the Accel London investment portfolio.

In the remaining two days, Adrian acts as advisor and board observer or member for a number of the Accel portfolio companies including ClusterHQ, Skipjaq, and Weaveworks.

Adrian also writes a popular technology blog, ‘The Morning Paper’​ ( in which he reviews an interesting/influential CS paper every weekday.

Like what you read?

Signup for a free FlockerHub account.
Sign Up

Get all the ClusterHQ News

Stay up to date with our newsletter. No spam. Ever.