Serverless – times it makes sense and times it doesn’t

Serverless is a concept in computing that promises to simplify coding workflow by eliminating all infrastructure considerations. You simply upload your business function to a vendor/host that then takes care of all provisioning, running, and infrastructure considerations. And even better you only pay for the time your serverless apps are working!

All that sounds fine and dandy. Before we dig deeper, let’s see a few use cases for which it makes sense:

•  Serverless is both cheaper and faster than building a brand new datacenter. This is important if your app is likely to go viral/big, and you might need to quickly scale up. 
• If you want to just add developers to an organization without an existing highly skilled sysadmin/programming/IT department(s). You want to just focus on building an app without having to build the whole internal ecosystem and infrastructure.
• You’re a startup that pivots a lot and current services won’t matter in a month or two. Or this way you don’t have to think about changing development platforms.
• You go big in funding and long term pricing is less important than deployment velocity. 
• You call an asynchronous action through API many many times, but you don’t want to deal with the performance and parallelization of the underlying web app.
• As part of your product stack, you are collecting cool-sounding buzzwords for conference, shareholder, marketing, or funding purposes.
• You are using buzzwords to cover for lack of capability, effort, or progress in a project (circumstances might not necessarily be your fault). 

What is serverless

All of the cases above leverage their unique value from the way serverless offerings work. The closest equivalent to a serverless function is ether Function as a Service (FaaS) or Backend as a Service (BaaS). 

FaaS can be any function, for example adding a few numbers or resizing an image. As long as it gets consumed/deployed as a web API accessed service. The classical example of a BaaS backend is a login service or a DB service. In both cases, your serverless workload is exposed through an API behind which is ether a stateless function that processes and returns or processes and pushes forward. Databases cannot be stateless (Duh!), but in this case, the “working” part is stateless and only the final state of transaction data ends up in the stateful storage. 

Terms commonly mistaken for serverless

• NO OPS – It’s the trend to completely remove operations/sysadmins from the organization. Not the same, because you still have to set up and manage the serverless functions with one of the vendors. 
• PaaS – Platform as a Service is similar but more commonly it refers to runing continuous services on a vendor-provided platform. FaaS serverless functions commonly start quickly, run their workload, and stop. Sometimes in only a few seconds!
• Containers – with containers you put something in a container, then you run the container. With serverless, you just upload it to the management URL, completely avoiding the need to deal with managing where your containers run.
• Cloud – most serverless applications are implemented on top of a cloud. While technically not wrong it’s calling serverless “cloud” is useless unless further specified. Similar to the statement: “Cure the patient with medicine”. Which is equally useless unless you specify which medicine and how it should be administered. 

When serverless makes sense

Serverless is acceptable in cases where you have a finite operation, such as modifying an image and returning it. Cases in which you are likely to be bottlenecked by a user’s internet connection, so creating a standalone instance for each job makes sense. Like for instance for managing a single user’s session in a recommendation system. Or cases where high performance is less important than being able to automatically react to a sudden spike in demand. The added complexity of implementing autoscaling on your own can likely outweigh the high cost of serverless computing. With serverless, you avoid detailing with provisioning or stopping instances, and you (should) get some cost savings from the vendor’s economy of scale. 

When Serverless makes less sense

All of this works in cases where you have a stateless modular standalone API-based app (gotta Byzz them all). Despite the buzz on the internet and tech conferences, most developers don’t have experience with developing that kind of apps. It is quite common for developers to prefer more granular control over the app than what most serverless platforms provide. Also due to the way serverless functions run, you may have to adapt your problem to the capabilities of the serverless platform. This might end up providing reducing the business value if the final solution.

While there are potential benefits to using a serverless platform as a basis of your app, there are also some drawbacks. Here is a shortlist of major tradeoffs you have to make if you go serverless.

Tradeoff considerations of going serverless:

• Vendor lock-in – deploying, running, scaling, and interacting with is done over a proprietary vendor API. This means that you may have to do a major rewrite if you want to move your app to another vendor. If all you do is serverless with vendor X, you might end up with a lot of organizational friction if you try to move. 
• Security – public clouds are big juicy targets because exploits are applicable to many organizations that run on such a cloud. Each new vendor provides new avenues for attack for a potential attacker. 
• Performance – by definition performance of a serverless function is slower than a similar bare-metal or VM/container solution. Also, they can suffer from cold-start latency in cases when the instance needs to boot up before it can serve the request. 
• Added infrastructure complexity – unless you’re going completely serverless, it becomes just another thing for your team to manage. 
• Debugging – getting insights into serverless functions running on the vendor’s system is very limited. Reproducing the circumstances in which an issue appears might prove impossible with serverless funcitons.
• Scaling costs – while is cheap to start, and cheap/fast to massively scale (compared to building and managing datacenters). But due to their lower performance for most organizations they might prove too costly to run especially if you fall as something in betean. Also, you’re paying for that ability to scale, if you don’t need it, you shouldn’t pay for it. 

The Silver Bullets

As with most state-of-the-art hype trains, it promises many things. More specifically people who like writing about new popular things they never used in production like praising it. In general, all gains concerning deployment speed, app velocity, and scaling make sense if your app can operate in a serverless environment. It may well be the case that you need need a way to fully describe your infrastructure and deploy changes based on such a description.

Further, those words make sense only if you specified and identified them as improvement points before starting to think of using serverless. In case you didn’t, step back and reflect. You may be looking for solutions without knowing what problem you are trying to solve. 

Serverless will reduce your lead time and costs

In some cases, serverless can reduce time and costs. You need to review the details of your development and operations process and find if and where it can reduce the time. As for the costs, do the math. Often you might find the costs to be prohibitively high for most use cases. 

Serverless will reduce your infrastructure complexity 

If you just add it to your existing stack it will increase your infrastructure’s complexity. If the teams working on serverless will stay in a separate bubble, it will simplify their workflow. But if they also have to work with the rest of the company, it might end up doing the opposite of what it promises. 

Further reading: