Cloud 2.0: Code is no longer King — Serverless has dethroned it

In recent months I’ve stopped blogging about serverless quite so much. There have been many reasons for this, but a lot of it has been down to the fact that I don’t have a lot to add to the conversation. Not because I don’t have anything new to say, but because I have already said a lot of it in previous blog posts or twitter threads or recorded talks. The conversations and points aren’t new to me and after a while, it becomes really hard and a little pointless to say the same things over and over.

But what has become clear to me is that there are some fundamental areas that still need clarification both for individuals using serverless as a term, and vendors who are building services and calling them serverless.

So, let me take you on a journey to why I think Serverless is the start of Cloud 2.0.

When “Code was King”

The Open Source movement was in part a reaction to major software companies trying to control the supply of software for the internet and that led to an amazing explosion of some incredible tools and services.

In the late 1990s and early 2000s we saw some open source technologies emerge, most notably the LAMP stack, that laid the foundations for an incredible burst of innovation around internet technologies.

With a seeming inevitability, alongside virtualisation technologies, this led to cloud services and the behemoths that are the cloud vendors now who have transformed technology.

Cloud services became the norm, and even though many companies are still stuck in the era of on-prem, it is certainly becoming the de facto standard in enterprise.

And all this was predicated on the premise of being able to upload your own code to the cloud.

Code was king and Developers became the New Kingmakers — — as stephen o'grady of Redmonk has said for a very long time.

And that is how it’s been for a long time. Developers developing software, and Operations teams managing infrastructure, and while the DevOps movement has provided better ways for these teams to work together — CI/CD, process automation, improvements in understanding — the separation has still been there.

Serverless blurs the Dev and Ops lines

The key for me is that Serverless relies on the Developer to understand Ops to a much higher level than ever before. That is to say, the Developer needs to understand things like scaling behaviour, both how their uploaded logic will scale to 100 and scale to zero, and things like data access behaviours, how the impact of a spike in usage will affect data access or similar.

My definition of Serverless also is an economic one:

“A serverless application is one that costs you nothing to run when nobody is using it, excluding data storage costs.”

So this relies on a Developer understanding at least in part that they are part of a business, and not isolated from business decisions. Something that is often more a part of an Ops team’s remit when it comes to cloud.

When you take all of these elements, the Developer takes on much more responsibility in the new serverless world than under previous paradigms.

It is much easier for a Developer to not understand the impact of a change within a serverless solution, and unintended consequences to occur, having a financial impact.

The serverless shift is one that relies on their understanding of how their infrastructure works and actually less on how good or bad their code is.

Which brings us to an interesting point.

No longer is it “Code is King”, but “Infrastructure is King”

And that does make sense. Understanding what services to use and when is a key element in the building of a good serverless application.

But that is only a part of the paradigm shift with serverless. There is a second part that isn’t always so obvious.

You actually want as little code as possible.

Because code is a liability.

I’m not the only one that thinks this as can be seen from the above tweet. Others such as Joe Emison talk about LOC (Lines of Code) being kept to an absolute minimum within a serverless paradigm.

Because if you have less code, you have less complexity.

And that includes your infrastructure which should be some form of defined language that allows you to deploy your application.

Because when you’re building a serverless application, you’re creating infrastructure and business logic to connect the services, and some “code” where the code is only what you write to achieve what the services cannot.

In fact, your code is far less important than how you architect your application. It is still important, but much less so than previously.

How you utilise the cloud services becomes your application.

I’d suggest this:

The ultimate serverless applications have zero code in them at all

Cloud 2.0: “Infrastructure is King”

It’s really very simple.

Up to now, the idea of cloud native has been about building applications and deploying onto servers, instances containers.

Serverless, and “Cloud 2.0” is no longer about that.

Serverless is about aiming to reduce your code to zero and use the cloud vendors services to do as much of the work as possible.

Which is why when someone talks to me about “running FaaS on Kubernetes” as being serverless, I find that baffling. That is, to me, seriously increasing the amount of code, and decreasing the number of services being used, and so completely opposite to the idea of serverless. Yes, it uses “Functions" and if that was the only definition of what makes something serverless, then fine, but if you take a look at the above, this approach becomes ridiculous.

I started my technology career in a University Data Centre in the late 1990s, and was a systems administrator. I know what it means to run actual machines, and deal with all the problems that entails. I have spent my entire career trying to avoid all those problems.

The cloud vendors have spent over a decade building services so that you don’t have to build complex systems.

Why would you run your own Functions as a Service on top of Kubernetes or similar on a cloud provider if you can simply purchase the service from the cloud provider? It genuinely doesn’t make sense from an LOC/maintenance/time/effort point of view and unless you have to run on-prem or similar, then I don’t understand.

If you still want to, then go for it.

But you almost certainly don’t have to any more.

Who are the “New Kingmakers”?

I have a few ideas.

I think it will be those who grasp this new “Infrastructure is King” paradigm.

I think it will be those who grasp that perfect code is no longer a requirement for success.

I think it will be those who grasp that whatever code you write today is always tomorrow’s technical debt.

I think it will be those who grasp the business imperative behind their work is more important than their technical achievement.

I think it will be the Serverless Architects…

…and these will be people who understand high scaling and availability cloud services, and know how to write highly optimised and minimal code to connect them together, with a very pragmatic view of technical debt.

But we’re not there yet…

At present we’re using the tools of Cloud 1.0 to try to deliver serverless solutions.

And at present, the tech world isn’t quite ready for those new tools.

We’re not far off though.

Cloud 2.0 is Serverless

And that’s where we’re all going to end up. Of that I’m sure.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Paul Johnston

ServerlessDays CoFounder (Jeff), ex AWS Serverless Snr DA, experienced CTO/Interim, Startups, Entrepreneur, Techie, Geek and Christian