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”
For a very long time in technology, building networked applications relied on software. Software that you had to understand intimately to know what was going on, or software that you downloaded from somewhere, and deployed.
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.
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
Then along comes Serverless. While a lot of people will argue about when Serverless came along (and what it is!), I am absolutely going to pin the birth of Serverless to the launch of AWS Lambda at re:Invent in 2014 (I will not go into why I am doing that here, it’s not totally relevant). While Serverless != FaaS, FaaS is a major enabler of Serverless, and this was the breakthrough that meant it became mainstream.
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”
When you are building in a serverless way, you are often more reliant on the services provided by a cloud provider. As has often been suggested, serverless is not a good name, and “service-ful” may have been a better name.
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.
This article defines and explains how serverless is different from other application architectures and then walks…www.infoq.com
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”
Why am I calling this “Cloud 2.0” and making it a “new thing” as if it is somehow different?
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”?
Taking on stephen o'grady and the phrase from his book, I wonder who the New Kingmakers will be?
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…
This new world lacks the tools and the stories and the heroes.
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.