“Containers won the battle, but lost the war to serverless architecture,” Simon Wardley

Simon Wardley Visits Serverless Superheroes

Welcome to the Serverless Superheroes!

Here I communicate with the creators of tools, innovators and developers who lead us into a bright serverless future.

Today, I talk with Simon Wardley, a consultant for the Leading Edge Forum and a specialist in situational perception, principles and gameplay. For convenience, I edited the interview.

This is the usual degree of repeatability. That's why I say that serverless architecture (FaaS) will speed development by several orders of magnitude. Any of your system is already 99.9% written by someone. The trick is to find the right piece. Containers? Do not make me laugh. Another clumsy fixture. - Simon Wardley

Forrest Brasil (Forrest Brazeal) : You are not the first year in IT and you are now ardently advocating serverless development. Have you been interested in this for a long time?

Simon Wardley : In 2005, at Fotango, we planned the environment and realized that the calculations turn into utilities, which means that the code execution environment will evolve in the same direction.

As a result, we created Zimki, and, in fact, it was the first platform as a service in the world: a Javascript server, opened through an API, is a real code execution environment with functional billing.

We immediately took a different look at the development, maintenance, and in general everything. Suddenly, we saw new levels of detail in terms of costs. This has not been done yet. We came up with all sorts of interesting concepts, such as the development of value-based.

Alas, the parent company decided to cover us up when we only gained momentum. But I thought about it for years. As a result, the Lambda arose. In my opinion, cool stuff.

Steeper than, say ... containers?

You do not think, actually I adore containers. A sort of invisible subsystem. But this is not a real fight. This occurs in code execution environments, especially when it comes to functional billing.

Many, it seems, still do not recognize that serverless architecture turns the world around, and continue to argue about the meaning of the word. Are you surprised that this was delayed?

It reminds of EC2 in 2006. Sun has long been indulging in utility calculations, but few have taken EC2 seriously: “Some kind of bullshit. Who needs this? And they rested for quite some time.
In 2009 or 2010, all these management consultants said something like: "The future is private systems, AWS will not pull." With the same success, we can say: “Well, nafig, these are your cars, we’ve got better hay for horses, we’re stocking up. We all know where Amazon is now.

Will someone catch them up?

This is from the same opera as the talk that in 2008–09 major equipment makers were talking about EC2. Calculations turned into utilities, and everything else dragged on behind them. Now we call it DevOps: the rapid development of higher order systems, rapid changes, intermittent equilibrium.

And the big companies were rolling by inertia and comforted themselves that all this would not become popular and would not affect them. Understandably, they miscalculated.

In those days, major equipment manufacturers had all the heavy artillery. Bezos had an Amazon and a slingshot. And he won. It was a mistake not of engineers, but of leadership. Now they want to return to the game, but all forces on the side of Amazon.

The same thing happens with serverless architecture. Other companies, of course, could run up with Amazon, but they won’t, because they don’t believe it. And when they believe, the train will leave.

If serverless architecture is so good, why does everyone grab onto containers?

To use Lambda, you need a lot to figure out. This is a completely different environment, a big leap forward. With containers easier. Plus they are portable, and everyone is terribly happy, especially suppliers.

They just talk about it and try not to notice a shift towards the code execution environments. Containers are not forced to change the architecture and do not show that almost all of your code has already been written by someone.

Is Lambda really such a powerful tool, what is it worth the effort?

Recently, I conducted a survey on Twitter: how many times have people rewrote basic user registration functions. It turned out - a million.

... as an example. If you have been in development for at least 10 years, how many times have you rewritten the user registration feature? - Simon Wardley

It is amazing what a high level of repeatability in companies. People think that governments waste resources. The worst case of repeatability that I saw in the government was 118 systems that did almost the same thing.

In the private sector, I saw banks with a thousand identical risk management systems. And how many of them around the world? Millions and tens of millions of the same systems.

I wildly apologize, but we produce waste paper all day. And if you radically change the architecture, you can spend this time on really useful functions. But, of course, it's easier to say: “Wow, container! Enters and exits - wonderful exits! And the environment is almost like favorite slippers. ”

That's the way about the "comes and goes." Many fear that serverless architecture is "the worst case of binding to a supplier in the history of mankind ." It's true? Will we completely depend on a serverless computing provider?

Of course, it would be cool if we had different competing suppliers. But it is not as important as the benefits and functionality. Companies still compete with each other. And the chance that suppliers agree is almost zero. Everyone says: "We will differ in this and that."

The only exception is, of course, the universal love of containers. All are worn with containers, but the battlefield has shifted. You won the fight, but lost the war.

Today we talk a lot about battles. Who will win and who will lose if serverless computing will evolve according to your scenario?

Today, Amazon and Alibaba are winning, which cut the chip. There are still very smart companies, such as Netflix, that use these technologies and quickly adapt.

And, of course, companies of one or two people per billion dollars will appear out of nowhere. They will have one function. No one will know these guys, but everyone will use this feature as a service.

As for the losers ... I do not want to upset you, but among them there will be DevOps fans.

Remember, when computing was a product, we built architectural methods on the characteristics of this product. Take, for example, a high average recovery time (MTTR). We increased the scale, planned capacity, thought out disaster recovery and stuff like that.

And then the calculations became a utility, the average recovery time was reduced, and we created new methods: distributed systems, failure insurance, chaos engineering, continuous deployment. Over time, it became known as DevOps. Calculations as a product are outdated.

Now with serverless architecture, we are waiting for new changes, and DevOps will be a relic of the past. And they will begin to be forgotten.

Some have not even really had time to switch to DevOps.

Yes, there are those who are just beginning their five-year transition to DevOps. As a result, they will get there, and there is no one there. It's a shame.

What will software development look like in ten years?

We do not even know yet what methods will grow on serverless architecture. I won't say for sure, but there are a couple of guesses.

Developers will attend to financial issues. The cost of the function will be more important than ever. There will be new development models taking into account the value: one company will build a system for another, but not at a fixed price, but for a part of the profits from this system.

Of course, for this, the companies themselves must understand how much profit the system brings.

The structure of the company will also change. This is a common thing. Electricity was transformed from a product into a public service, and a host of higher order systems appeared. The same was with production, when Fordism and the American system appeared.

When this happens, new methods emerge, and the form of the organization changes. I think the serverless architecture will be the same.

That is, in your opinion, in software development there will be less losses and higher efficiency?

Let's define the terms. Do not confuse losses with expenses. These are different things.

We will see high efficiency and rapid development of higher order systems. As for IT costs, EC2 spoke about this as far back as 2007–2008. And hello Jevons paradox .

In fact, it turns out that the more efficient the piece, the more we need it. People think that they will save a lot of money with serverless computing. Have to roll your lip. We will just take more.

And the last question: what would you say to a person who cannot choose between serverless architecture and containers?

[laughs] Is he a friend to me or what?

In my opinion, we have more in common than disagreements. I'm more worried about timing. The war flares up on the serverless battlefield. And all the rhetoric should be there. Intermittent equilibrium - it is this: you think, wait another hundred years, then you look - they have arrived. - Simon Wardley

Let's say a friend.

Well then, let him choose what he wants if the project is short-term. I am not against containers.
But if the project is long, it is better not to regret time and master serverless calculations. Behind them the future.