Which Serverless should I choose?

FaaS (Function as a Service) or Containers?

Photo by Paula Vermeulen on Unsplash

Krish is a bachelor and his food needs are simple. When he feels like eating, he checks into the nearest fast food joint & grabs something fast. He is aware that the choices are limited and he may have to wait longer occasionally, but this option works for him, given the money and the time he wants to spend on food.

Ram is a family man. He loves treating his family with gourmet meals. He plans the choice of the restaurant carefully & books the table in advance. He is spoilt for choices when it comes to the type of food & he exploits this well. He knows he has to plan meticulously, but he must do everything to ensure that his family savours the meal.

Wait a minute… Why am I talking about food preferences in a technology article?


FaaS (Function as a Service) offerings are like Fast Food.
You can deploy them fast.
You can tweak some deployment parameters (such as memory etc.) but overall have limited choices when it comes to controlling the deployment environment.
They can turn out to be very cheap, provided you can compromise on certain factors (such as cold start lags, overall time limit for the function to complete etc.)
Container offerings (Kubernetes in particular) are like gourmet meal.
You can tweak the deployment parameters in-depth but you have to spend time in doing so.
You may still be concerned about cost, but scalability & availability are what you are most concerned with.

When you have to make an architecture choice like the above, how do you do it?

You can employ the following strategy:

  • Choose the parameters that must be satisfied no matter what. These are your satisficing metrics.
  • Choose the parameters that are good to have. These are your optimizing metrics
  1. Evaluate the architecture choice(s) first against your must-have (satisficing) metrics and pick the choices that adhere.
  2. Once you have identified the first set, you may apply your good-to-have (optimizing) metrics and finalize your choice.

Let us look some scenarios & see which serverless choice is suitable for each of these scenarios.

Scenario 1:

My service is a background job that creates a thumbnail out of an image which DOES NOT require sub-milliseconds response time; and it is NOT heavy on database. But I must get charged only when it runs.

Recommendation:

The satisficing metric in this scenario is the total cost. There are no stringent requirements on the response time.

So, FaaS is the recommended choice here.

Scenario 2:

My service is a critical API service that provides clearing calendar functions. It is used by more than 10 other microservices synchronously and hence response time is of utmost importance to me.

Recommendation:

The satisficing metric in this scenario is the response time. There are no stringent requirements on the cost.

So, Containers (Kubernetes) is the recommended choice here.

Scenario 3:

My service is a lightweight background service but must connect to a VPN tunnel & get some data from another service through sockets.

Recommendation:

The satisficing metric in this scenario is the deployment flexibility.

So, Containers (Kubernetes) is the recommended choice here. You can bake in the VPN install & the connect into the container blueprint to solve this requirement.

Scenario 4:

My service is a critical long running Day End job that crunches numbers and is super heavy on the database.

Recommendation:

The satisficing metric in this scenario is the processing capability and overall timing requirements.

So, Containers (Kubernetes) is the recommended choice here. You may want to employ parallelism & spin multiple containers to finish the overall batch fast (i.e. divide and conquer).

Conclusion:

FaaS vs. Containers is NOT a zero-sum game. Each of these architecture have a niche & solve specific use cases.
As a thumb-rule, if you are deploying something small & light-weight, and are sure that your function completes before the maximum timeout, you can happily choose FaaS. Pickup your fast food and consume!
If you have specific stringent requirements, be it on the deployment side, or on the scalability & availability, go for Containers. Be sure that you understand the ingredients before you cook your gourmet meal!

Hope you enjoyed this article! Please do leave your thoughts or comments!

UPDATE (11th Apr 2019):

Ever since I published this post, there has been a lot of interesting developments on the container side. Significantly, Google has released a new product Google Cloud Run. As per Google’s documentation,

“Cloud Run is a managed compute platform that enables you to run stateless containers that are invocable via HTTP requests. Cloud Run is serverless: it abstracts away all infrastructure management, so you can focus on what matters most — building great applications. It is built from Knative, letting you choose to run your containers either fully managed with Cloud Run, or in your Google Kubernetes Engine cluster with Cloud Run on GKE.”

So, it looks like you can finally have the cake and eat it too!