Containers won the battle, but will lose the war to serverless — Simon Wardley

The Serverless Superheroes Series featuring Simon Wardley

Welcome to “Serverless Superheroes”!
In this space, I chat with the toolmakers, innovators, and developers who are navigating the brave new world of “serverless” cloud applications.

For today’s edition, I chatted with Simon Wardley, an advisor for Leading Edge Forum specializing in situational awareness, doctrine and gameplay. The following interview has been edited and condensed for clarity.

Forrest Brazeal: You’ve been around IT for quite awhile, and you’re an enthusiastic proponent of serverless development — how long has serverless been on your radar?

Simon Wardley: In 2005, while mapping out our environment at Fotango, we realized compute was moving toward a utility, and code execution environments would head in that direction too.

So in response, we built something called Zimki, which was actually the world’s first Platform as a Service: a Javascript back end exposed through APIs, a true code execution environment with functional billing.

And it totally changed the way we developed, operated, the way we thought about things. Suddenly, we discovered we had levels of granularity, in terms of what our code was costing us, that nobody else had. Led to all sorts of interesting concepts such as worth-based development.

Unfortunately the parent company decided to shut down the service just as it was catching on, but over the years I’ve thought about these ideas a lot. And then eventually Lambda appeared, and I think it’s pretty spectacular.

More spectacular than … oh, I don’t know … containers?

I’m a big fan of containers, despite what people might think. I look at them as invisible subsystems. That’s not where the battle is. The battle is code execution environments, particularly with functional billing.

It seems like a lot of people still won’t admit that serverless is a game-changing concept — they’re still hung up on arguing the semantics of the word. Are you surprised that it’s taking so long?

I’m reminded a bit of EC2 in 2006. Sun had a play with utility computing much earlier, but most of the general reaction to EC2 was fairly dismissive: “That’s for kids, nobody will use it”. That sort of talk continued for quite some time.

In 2009 or 2010, you started to get all these management consultant reports saying things like “The future is private — AWS isn’t ready for prime time.” It’s like someone saying — “The future isn’t those car thingies — it’s better hay for horses!” And now look at Amazon — they’re running away with it.

Can anybody catch Amazon in the serverless space?

This is again like those conversations around EC2 at big hardware companies around 2008–09. Compute was shifting from product to utility, leading to co-evolved practices, what we now call DevOps: an explosion of higher order systems, rapid exponential change, punctuated equlilbrium.

And the big companies were sitting there with inertia, because of preexisting business models, saying: “It’s not going to be big. It won’t impact us.” But of course it did.

Remember, at this time the big hardware companies had all the tanks, all the airplanes, all the armies. Bezos and Amazon were at the bottom of the hill with a slingshot. And they won the battle. Not an engineering failure on the part of the other companies; it was a total executive failure. Now they’re trying to get back in the game — but Amazon’s got all the armies.

And we’re seeing the exact same pattern with serverless. Yes, other companies could challenge Amazon’s dominance. But they probably won’t, because they don’t believe it’s for real. And by the time they do, it’ll be too late.

So given the advantages of serverless, why do you think containers are such an attractive option for so many people?

Lambda is a huge educational barrier. It’s a different environment, a big jump. Containers are a smaller educational jump; plus, they offer things like portability that people, particularly vendors, really want to talk about.

It gives them a counter-story that somewhat ignores the whole platform shift to code execution environments. Containers don’t force you to re-architect, or discover that most of your code has already been written by other people.

But is Lambda really providing enough value to make such major rewrites worthwhile?

I did a Twitter poll recently asking how many times people have rewritten basic user registration functions. And from that poll I extrapolate that the basic user registration function has been written at least a million times.

Within organizations, the level of duplication you get is astoundingly high. People think government is inefficient — well, the worst example I’ve seen of duplication in government was 118 systems doing pretty much exactly the same thing.

In the private sector, I’ve seen banks with up to a thousand risk management systems all doing the same thing. Multiply that out across the world and you have millions, tens of millions, of duplicated systems.

A lot of what we do in IT, I’m sorry to say, is waste. But radically changing your architecture to focus on the functions that actually provide value is a big shift, and it’s not as comfortable as saying: “Hey, I’ve got a container! I can move it around between providers, and it’s more similar to the environments I’m used to.”

Since you mentioned moving code between providers … there’s a lot of FUD out there about serverless being “the worst form of proprietary lock-in in the history of humanity.” Is that legitimate? Should we be concerned about vendor lock-in with serverless?

Sure, it would be nice to have a competitive environment with different providers you can switch between. But that is secondary to usefulness and functionality, because companies are in competition with each other anyway. And the chance of getting the actual providers to agree is pretty close to zero. Everybody goes: “Well, we’re going to differentiate on this or that.”

The one exception, of course, being how everybody seems to have come together around containers. So now everybody’s excited about containers, but the battle’s shifted up. So you’ve won the battle, but lost the war.

We seem to be talking a lot about battles today! Who do you think are the winners and losers if serverless as a movement plays out the way you expect?

Winners at the moment are Amazon and Alibaba, who seem to be clued into the changes that are going on. Then there are the companies that build on top and are adaptive — very sharp companies like Netflix.

And then out of the blue we’re going to get these billion dollar one- or two-person companies. All they’ll do is provide a function, and you won’t know where they came from, but everybody will be using that function as a service.

As for losers — I’m sorry to say that one set of losers will be those who hold on to DevOps practices.

Recall that when compute was a product, we built architectural practices based on the characteristics of compute as a product. One of those characteristics was high MTTR (mean time to recovery) — so we focused on scale up, capacity planning, disaster recovery, etcetera.

And then when we went to compute as a utility, we had low MTTR, so we built new practices: distributed systems, design for failure, chaos engines, continuous deployment. Over time that set of practices got a name — we called it DevOps. And of course the product world was legacy.

Well, as we continue to shift up the stack toward a new change of practice with serverless, I think you’ll find that the new legacy is going to be DevOps. And that won’t be popular either.

I mean, there’s plenty of shops out there that haven’t even really gotten into DevOps yet.

There’s people out there right now saying “We’re starting on our seven year DevOps journey.” By the time they get there — oh well. It was a nice try. The world has moved on.

So what do you think software development will look like seven years or ten years down the road?

Well, we don’t really know yet what kind of best practices will evolve around serverless. It’s still in what we call the uncharted space. I can sort of hazard a guess, though.

A lot of it will look like development and finance combining together. The cost of a function becomes really, really important. So you’ll see whole new models of worth-based development: companies building a system for others for free, but taking a metric of the value they generate.

Of course that presupposes that businesses have any understanding of the value that a system creates!

Organizational structures will change too. This is not unusual. Electricity evolved from a product to a utility, creating an explosion of higher order systems. Manufacturing following the same pattern with Fordism and the American System.

Often this industrialization of particular bits of technology from product to commodity to utility causes a new set of practices which changes organizational forms. And I’d expect to see this with serverless as well.

So you’d see software development trending overall toward reduced waste, greater efficiency?

We have to be very, very careful on this point. Because people think “reduced waste” means “reduced IT spend”. And it certainly does not.

We’ll see more efficiency and rapid development of higher order systems. But in terms of reducing IT spend, people said the same thing about EC2 in 2007, 2008. And they quickly learned about something called Jevons’ Paradox.

What happens is that as we make something more efficient, we wind up consuming vastly more of that thing. So when people say “Oh, we’re going to spend so much less money with serverless!” nah — forget it. We’re just going to do more stuff.

Last question: if you met somebody today who is wavering between building their application on serverless or containers, what would you say to them?

[laughing] Well, it depends on if I like them or not.

Let’s say you like them!

So in the short term, if it’s not a long-lasting project, pick what you’re comfortable with. If it’s containers, that’s fine.

But longer-term, I’d be investing my time in learning about serverless practices. Because that’s where the future is.