The Serverless Conundrum, Part I of II: The Business Side of Things

You cannot escape any talk or article that deals with cloud computing in one way or another without coming across the term "serverless".

And there are very good reasons to that.

I will walk you through what these reasons are and what serverless in a nutshell means. Means to you and how you operate.

In part one of this mini series, we'll look at it from a business and in part two from a functional perspective. I will give you some advise along the way on how to take advantage of it - and be clear about pitfalls.

What's serverless?

You could call it a "software as a service" (SAAS) flavor for developers. Developers who want to run code, store data, integrate applications or technical process flows without ever having to go through what AWS would call "undifferentiated heavy lifting". For example setting up your infrastructure and architecting it for security and reliability - again and again and again. It's fair enough to say serverless compute, storage, message queuing aims at making all of these tech capabilities as low-friction as possible for developers.

What's in it from a business perspective?

Let's take a look at the value it provides as "pros", against costs and risks as main "con" dimensions. The main advantage of serverless services, further just called "serverless", is of course time to market. Since it frees up developers from doing a lot of groundwork they can get to implement business logic, store data with confidence and run integrated workflows very quickly. Or in short, put up software for business purposes faster than with any other hosting paradigm. Since there is no (explicit) tie to infrastructure, re-doing an application is much easier if you bank on the serverless paradigm - adding business agility.

The main advantage of serverless services, further just called "serverless", is of course time to market.

As a third "pro", it's worth noting that serverless empowers developers to extend their depth of creation and not only do more with less resources but as well cover wider areas of the software lifecycle. Think of "frontend developers" now doing "backend developer" work as they go along. Resulting in less developers needed to achieve similar (business) outcomes! Efficiency gain therefore another tick in the box for serverless.

Usually, cost is sold as another big "pro" when you ask cloud service providers - the rationale behind being that you only pay as you go / pay for what you really need. Since the IT reality since the dawn of computing has always been IT systems sitting idle and adding nothing to your topline for most of their lifetime whilst incurring implicit and explicit cost.

Costs + Risks

And for most use cases and contexts, cost will be a "pro" of serverless. Do note however it can swap into the "con" section of the equation quickly by the time you hit certain demand metrics. Very easily put, making operations like those of Netflix economically sustainable only using serverless IT building blocks will never be possible - at some point of scale you are really better off investing into bespoke architecture.

Scalability is the ability to keep up with growing demand and often called out as a "pro" of serverless as well. Taking away the risk of letting your customers down or fail to operate an otherwise crucial operation. For most serverless services I am aware of there are either ways to scale with serverless or these services are built for scale from the ground up and a de-facto property of the service. And yet, don't assume that every serverless service will auto-scale (well). Architecture work does not go away with serverless and I will elaborate on that in the second part of this series. From a business point of view this pro is a mixed bag therefore and you should always be prepared to do some validation with your architecture comrades.

Never forget: The reason you gain efficiency with serverless is the fact IT resources are highly commoditized and standardized to be offered to you in a highly abstracted way as pay-per-use utilities. Think of electricity delivered to your house.

Like with your electricity provider, your serverless provider is restrictive in terms of what you can influence "under the hood". With restriction comes liberation. The liberty to focus only on what matters to you, to your clients. The liberty to focus on value.

With restriction comes liberation. The liberty to focus only on what matters to you, to your clients.

That liberty can turn against you, however. Talking about focus on value: If your main value proposition is an IT service you need to tweak and tune into its very properties, maybe your reliance on serverless will hinder you more than help. The well intended abstractions become a problem, in that scenario.

Why? Well, imagine for example your business model comprises offering Internet of Things (IOT) API services. The way these APIs work deep to their core and performance properties like latency would be very important to be fully in control of. After all, directly impact User Experience.

The most important "con" often recited by serverless nay sayers from a business point of view is the fact that serverless is usually highly specific to a certain cloud platform and cannot be as-is shipped somewhere else. Meaning there is a risk getting "locked in" into a certain ecosystem and making a move towards a competitor platform hard and expensive. Keeping this in mind and weighing this into architecture choices can mitigate the risk quite a lot though.

And realistically lock-in comes in various forms and fashions and is by no means limited to Cloud or serverless. In fact, think about crucial applications of yours running today.

You might already be locked-in into a certain architecture baseline which your experts might thoroughly understand - maybe that's not even the case though and you would only find out by the time you tried to replicate the entire architecture, for example. This is just to say that lock-in is always a concern but avoiding it all cost is not worth the effort either.

Talking about things worth your while. Let me point out that serverless in general bears no inherent business value. Technology in general doesn't, for that matter.

The business value of technology is generated by the way you operate that technology.

The business value of technology is generated by the way you operate that technology.

Sounds fairly obvious, right? It's an important reminder nevertheless. Just take effective constraints imposed by your organization e.g. on how code is deployed or infrastructure governed. These constraints may easily outweigh the benefits of serverless. Instead of accepting that status quo I want to encourage you to take a look outside-in: Are these constraints really useful or only remnants of a former time with very different possibilities than today?

My experience is exactly that and often old habits just don't die. (Read my take on Change Management.)

To find a better way to support your business with IT, rely on your Architects to break down what and if there is any value gained in your individual context and business realm. They will hopefully guide you as well on your transformation path you might be on or about to embark and help to pave the way for overcoming inherited obstacles and a truly value centered IT organization.

You see that I am not mentioning any improvement figures nor case studies. Of course there are plenty of case studies from all the known cloud platforms. If you need some numeric promises to get some ideas sold in your org, sure - go ahead and collect what I would not call evidence but at least discussion bait. Just take it all with a grain of salt. And be realistic about it: A case study will never replace an end-to-end value creation chain analysis rooted in your specific org, business context.

In the next part of this series I will look at the nitty-gritty of the tech side of serverless. We'll discover that the lines between PAAS and serverless sometimes get blurry and complexity is sticky. Have a good time and happy building!

Go to part II of this series.