Serverless vs Servers

The traditional way of doing computing was, and still is, is by “spinning up a server -> loading the code -> executing the code” still works quite well. But what took the developers and system administrators by surprise was that you can go through these steps quite quickly based on demand.

Let me explain this idea.
For server-based deployment, you have to run a VM, configure a VM, load the application on the VM, and scale it up, down or horizontally based on usage. But, with serverless, you just hand your code, specify Memory configuration and you are good to go. Each invocation of the application code will be scaled and managed by the service provider. So, what you need to focus on based on both technologies is

For server-based approach:

Size of VM/VMs [CPU, RAM, NETWORK, STORAGE]
OS
OS configurations
Application package installation
Application code

For serverless approach:

Size of Function [Memory, Timeout]
Application Code

You can see the difference in design choice. As the saying goes “With great power comes great responsibility”. What is implicit in the statement is that you have chosen to pick up ‘great responsibility’. My idea would be to at least check, based on some metrics, whether you want the ‘great power’ or not. Else, it would ‘great waste’ of time and resources.

Let's write some metrics:
Do you expect your task to be completed under a timeout? [ AWS Lambda: 15 mins, GCP Cloud Functions: 9 mins, Azure Functions: 10 mins]

If Yes: 1 point
If No: Can you decouple your application to a queue-based event driven system?
If Yes: 0.25 point
No: 0 point

Does your application memory requirement is under the service provider’s max limit? [ AWS Lambda:15 GB, AZURE Functions: 1.5 GB, GCP Cloud Functions: 8 GB]

If Yes: 1 point
If No: Can you split your job in a way you can run another function and it will pick up the job where the previous function left it?
If Yes: 0.25 point
If No: 0 point

Is your application stateless?

If Yes: 1 point
If No: Can you rewrite session-based part to a session-less JWT solution?
If Yes: 0.25 point
If No: Can you opt-in to store session data on a network file system or on a database?
If Yes: 0.25 point
If No: 0 point

Does your application require another software appliance to operate (DB, SPARK, Compute Nodes etc.) ?

If No: 1 point
If Yes: Can you opt-in for a cloud-based solution that provides the similar capability (DynamoDB, EMR, AWS BATCH)?
If Yes: 0.25 point
If No: 0 point

Results:
If you manage to get all three points. You can go and architect a serverless solution and start coding. No need to manage fleets of servers. But, if your architecture requirements have blocked you from reaching a perfect 4, you can still opt-in for a mix solution. The decimals at the points to the fact that you have to put extra effort to bind a solution that can still leverage a serverless solution with all its benefits. But how hard it is to architect completely serverless solution is based on how far are you from 4. If you fall in the range between 3+ to 4, you might need some extra effort to architect and develop your solution. You might need to bind some other cloud provided services to your application code, design queues workflow that can push and pull jobs etc. There is a little bit of learning curve to learn about binding the relevant cloud service that is equivalent or better than your earlier defined software appliance. If you fall in the range of 3 or below, you can definitely opt in for mix strategy.

In the end, manage what can be decoupled on the serverless technology and provision the rest on servers. That’s is very handy and cost saving. Tasks with unpredictable workload and tasks with predictable workload can be divided quite easily and you save a lot in terms of cost for compute resources provisioned as the serverless fleet will only cost as long as you have customers using it. The rest of the provisioned infrastructure can be scaled based on how many serverless functions are in execution or how many messages are in a queue to be processed.