Fully managed or Serverless – that is the question

One of the first thing that comes to mind when we think about fully managed is AWS Elastic Beanstalk. If you swear by Azure, then you will think about Azure App Service. Both of these can be classified as Platform as a Service (PaaS). In this model we do not have to think about underlying servers or infrastructure. You will only be deploying the application, set some parameters and you will be able to get the following:

• Variable slices of computing resource with CPU and memory
• Disk storage to host your applications and then some additional
• Load balancer that can span multiple zones for redundancy
• Option to create a web server and exposing to public network
• Access to DB/ other resources using internal network
• Auto scaling based on setup parameters
• Public and private networking layers
• Access to logging and monitoring of the service
• Additional runtime configuration if required

That is a lot of features available for very less effort. So, what does the serverless give us?

What’s up with Serverless?

Serverless platform, classified as Function as a Service (FaaS), is where you do not care about underlying hardware but only care about a program running. The infrastructure in this case also is entirely managed by the cloud provider. Here the hardware, operating system, web server, networking etc. are all managed for you. On AWS you can use Lambda for serverless. For Azure you can build on top of Cloud Functions.

So why do we need serverless? From managed services perspective, we have the choice of hardware, number of servers we want to run… so why serverless? One of the greatest advantage of serverless is that it will only consume resources when being used. When there is no load, serverless will tend to spin down. This is also a problem. Let’s imagine a request sent when the application is spun down. As soon as the request comes, cloud provider spins up an instance of the service. However it will always take a finite amount of time for this. So, the first call after waking up is always slow. However, understand that when the application is spun down, there is no billing. Also most server less process does not allow long running processes. So, you cannot deploy any long running batch processes on serverless.

How do we select?

So that we want to join the server less bandwagon (who doesn’t like pay as you go?), how do we determine what application is suitable for serverless? Let’s go over some points that will help us make the decision.

Type of application

Is the application doing lots of data crunching and taking a long processing time? Then serverless is the wrong tool for the job. Do you have strict performance requirements for your APIs? Serverless may not the way to go. The best fit applications for serverless are probably the ones that you can fit in an event driven architecture. Example, an image is uploaded to S3 bucket, we want to create a grayscale version of it and store it in a different bucket. Finally, we send an SQS message with the image location and key. This is an ideal scenario for deploying to serverless applications.

Latency

How much latency can the application sustain? Since serverless will auto unload and go to sleep if not called for sometimes, there will be instances when it has to be cold started. Any application that is cold started takes the boot up time. So, if latency is a problem, this is not the route. Many applications tends to have a timed job to keep on hitting the service – this keeps it warm and available. However, in this case you are losing one of the key benefits for serverless viz. savings when the service is unused.

Availability/ Call volume

Most serverless platforms allow a specific number of requests every second. Any requests beyond it will be silently denied. So, if we have a requirement where we have to push a large number of requests every second, we should try to avoid serverless as we may be blocked by vendor on the assumption of DoS.

Visibility/ Control of underlying hardware

Do you need control of the hardware where you deploy? Or is the infrastructure being a black box does not cause any issues? Do you have concerns on amount of resource that is being assigned to your application? If you answered Yes to any of the questions, move away from serverless. With serverless, you will not have a clear visibility of the underlying infrastructure and each process will be bound by fairly stringent limits. Most of the time vendor will not be flexible enough to change the limits.

Conclusion

I think knowing what your end product is, and how you want to architect it, makes it very easy to decide if you want to go serverless route. There is of course one more flexible route similar to fully managed. A lot of different organizations now tend to go for Kubernetes clusters to deploy their application. This ensures very little vendor lock-in and you have the flexibility to take the application and deploy it anywhere you please. All vendors are now providing fully managed K8s clusters. That can be a discussion for a later time. Ciao for now!