Going Serverless

Let’s imagine you have been assigned a task to write a service which takes an input data, let’s say it’s date, and reformats it into a format that you desire and returns the output. Now let’s also imagine that you don’t exactly know how much you need to scale it as it is dependent on some customer action. But you have an idea of the peak demand.

Now you can either go with setting up your deployment infrastructure, running an appropriate server for your code, and pay for handling the peak case, set up monitoring services and so on. But is it really necessary to go through all this hassle for a service like the one mentioned above? Or you can go the serverless route where you’ll get following advantages:-

Server Management not required

You don’t have to worry about servers as they are managed by vendors. It also saves time and resources that would have been utilized in deploying that service.

Pay for what you use

You get only charged for what you use. Making this option, much more economically viable. Traditionally you would need to project how much server capacity you would need.

It’s inherently scalable

If the user base for your service has a sudden spike, the serverless infrastructure will simply fire up more instances to handle the spike and it will turn them off when they are not needed anymore. This is extremely efficient.

Updates are quick

You can update the code one function at a time or the whole code. You won’t have to upload the whole code for every update.

Code runs physically closer

The serverless vendore will fire up your code to the server which is closest to the end user. This will lead to reduced latency

Now let’s look at some disadvantages of going serverless:-

Testing and debugging will be a nightmare

Serverless environment is difficult to replicate, so if something does go wrong you are back at doing hit and trial or modifying the code so it will run on your dev setup.

Security concerns

Can’t fully vet the security of vendor servers. Personal data is sensitive and vendor servers might be running code from several other users with your service, it can lead to a issue called ‘multitenancy’. Although it won’t be an issue with all the vendors, but this is something to look out for.

Not built for long running/resource intensive processes

If your service takes a lot of time to run or requires a lot of memory, serverless might charge you much more than a traditional server, or even worse your application might not even run as serverless generally comes with strict memory limitations.

Warm start and Cold start

Since the vendor won’t keep your code always running, if it gets used less often, the server will need to ‘boot up’ and it might affect performance, or do a cold start. If your service is used quite often then the vendor will keep the server running which will lead to a ‘warm start’ when it gets a request. It might lead to performance issues.

Vendor dependency

If something goes wrong in the server, you are completely dependent on the vendor to fix it, because serverless code is not that migratable you can’t simply switch to a different platform easily. Although there are tools available which allow you to write vendor independent code, but it will be quite a hassle for a larger codebase.

So should you go serverless?

Well, it’s yes and no. For a lightweight service like the one that we assumed you have been assigned to make, serverless infrastructure seems pretty good. It is more cost effective and quick for updates. But if you plan to move a very large code base to serverless infrastructure, you might face a lot of issues pertaining to testing and debugging, privacy concerns and all the other disadvantages mentioned above. So you should go serverless, but do it responsibly.

So those were my two cents on going serverless. But at the end it boils down to your specific use case. What to do you think about serverless architecture? Will you ever go serverless?