Introduction

These days most of the public Cloud Providers are offering #Serverless services also known as Function as a Service (FaaS). Serverless provider trying delivers more value to the business by minimising the time and resources spend by an organization on underline infrastructure requirement. Serverless provider gives a flexibility to users to write and deploy code instead of worrying about the deployment, scalability and manageability of the underline infrastructure required to run that code. and user is charged based on their computation.

History

Serverless architecture is not new, In 2008 Google offered Google App Engine ( GAE or simply App Engine) as a PaaS platform for developing and hosting web application on Google Managed Data Centres. Google App Engine primarily supports Go, PHP, Java, Python, Node.js, .NET, and Ruby applications. However AWS accelerated mainstream use of the serverless in 2014 with the introduction of AWS Lambda the first serverless computing offering by a public cloud vendor. Today, the serverless offering is primarily available cloud providers like Google Cloud Functions by Google, Microsoft Azure Cloud Function, IBM Functions but there are great number of serverless providers today supporting various technologies at different price points. Additionally softwares like OpenFasS, Kubeless, Apache OpenWhish, Knative and many more are available for on-premises deployment for the companies that don’t want to go to cloud but want some additional flexibility. 

How Serverless is different from containers ?

Next question which may come in mind is, how serverless computing is different from containers? When both the architectures are independent of underline infrastructure and enables developers to build applications with more flexibility and less overhead in comparison to traditional servers or virtual machines, what makes them different?

Let’s understand containers first

A container contains applications and all the dependencies required to run an application properly. You can run almost any kind of application in a container no matter where it is hosted.

In simple terms we can say, containers are a way to partition a machine or server into multiple environment’s. Each environment runs only one application in its own partition and doesn’t interact with application running in another partition. Every container share’s the machine’s kernel with other container but run as if it were the only system on the machine.

Key differences

1. Allocating Server space, although both the technologies need server space to run the application but in a serverless computing it is up to the serverless vendor to provision space as needed by the application. On the other hand each container lives on one machine at a time and uses the operating system of that machine.
2. Backend Infrastructure scalability, In a serverless architecture backend automatically scales up or scales down as and when needed on the other hand in case of containers developer is required to forecast infrastructure team in advance on the number of containers needed.
3. Backend Infrastructure Cost, as serverless architecture can scale up and scale down as and when needed. Developers are only charged for server capacity that their application have actually used. On the other hand containers are constantly running and cloud providers will charge the server space even if no one is using the application at the time.
4. Backend Infrastructure Maintenance, In case of a serverless architecture there is no backend to manage and serverless architecture provider takes care of the management and software updates for the servers that run the code. On the other hand, even if containers are hosted in the cloud, cloud provider do not update or manage them. Management of containers comes under the developer’s responsibility.
5. Deployment time, Initially deployment of containers take longer to setup up as it is required to configure required system settings, libraries and other dependencies. Post configuration, deployment take only few seconds to deploy. On the other hand, serverless functions do not come bundled with system dependencies and take milliseconds to deploy.

With all the benefits like lesser deployment time, low maintenance, no upfront cost and scalability, there may be scenarios where serverless architecture might not be right fit. Few of them are

1. It is difficult to test a serverless application because the backend environment is hard to replicate locally. On the other hand, containers will remains the same no matter whether deployment on cloud or on-premise, making it simple to test a container based application before production deployment.
2. In a serverless architecture, there may be some latency involved in executing tasks because servers will sit cold until pinged by an application. Such architecture may not be an ideal solution for applications where speed is the primary requirement like e-commerce and search sites.
3. Migration of code base to another cloud service provider can be a big challenge because of lack of interoperability and ability to communicate between implementations in multi-cloud deployments. You might have to make major changes to your code which can take a lot of time and money. Moving to serverless may not be the right choice if vendor lock-in is the primary concern.
4. As serverless functions have time limits before they get terminated, serverless computing might not be the best choice for long-running apps like online games and apps that keep performing analysis on large datasets.
5. In a serverless architecture, you don’t have much control over the server. If you select an amount of memory your function should get but CSP assigns a small amount of disk storage and decides the rest of the specifications for you. This can be a hindrance if you need something like a GPU to process large image or video files.

When should you use each?

Both serverless and containers can serve specific use cases. Serverless architecture is best for the use cases where development speed, cost optimization, manageability and scalability is primary requirements. Serverless is best suited for the apps that need not be always running but should be ready to perform tasks.

On the other hand, Containers are best for complex, long-running applications where you need a high level of control over your environment and you have the resources to set up and maintain the application. Containers are also very useful if you are planning to migrate monolithic legacy applications to the cloud. You can split up these apps into containerized microservices and orchestrate them using a tool like Kubernetes or Docker Swarm.