Serverless Computing: Deploy Applications Without Fiddling With Servers

What is Serverless Computing?

Serverless Computing mainly started as a buzzword to describe Functions as a Service (FaaS). In this paradigm, you as an application developer don’t have to worry about managing servers or containers, or think about capacity planning and scaling your infrastructure. You just write code and deploy it to the cloud service of your choice. The cloud service takes care of spinning up required containers, deploying your code to the containers, and executing it.

Conceptual Model

In a typical serverless model, you write a function and specify an event which will trigger your function. The event can be of any type: an HTTP request, a new file uploaded in S3, a message published on AWS SNS (Simple Notification Service) Topic, Scheduled events (Similar to cron), or many of the AWS services support AWS Lambda Triggers. When the trigger event happens, your function will execute automatically.

Major FaaS Providers

1. AWS Lambda: It is one of the most mature FaaS, supports code written in Node.js (JavaScript), Python, Java (Java 8 compatible), C# (.NET Core), and Go. AWS was the pioneer in the FaaS.
2. Azure Functions: It supports code written in C# and JavaScript. Also, there is preview/experimental support for Java and Python.
3. Google Cloud Functions: As of now, it supports Javascript only.

How Does FaaS Work?

On a high level, when a trigger event happens, the FaaS provider checks if a container is already deployed, if not, it creates a new container of the selected runtime, deploys your code, and executes it. This execution has a time limit. On AWS Lambda, maximum execution time your function can have is 5 minutes.

Once the execution is completed, the cloud provider keeps the container around for a few minutes to check whether any other event for the same function comes along. If yes, the same container is reused. Otherwise, the container is terminated to release the resources associated with it.

How Does Faas Billing Work?

FaaS is aimed at Pay-per-Use model. You don’t have to pay any fixed monthly billing. If your functions are executed then only you are charged. Basically, you will be charged for the number of requests and the time for which your code is executing. AWS has a concept of GB-Seconds. For example, you specified that your function needs 1GB of RAM and it runs for 1 second. Then you will be charged for 1GB-Second.

Typically, you can allocate RAM for your function in multiples of 128MB. On AWS, minimum starts at 128MB and maximum allowed RAM is 3008MB. If you allocate more RAM, more CPU and better Network bandwidth will be allocated to your function. In addition to that, time is measured in the slices of 100ms. To calculate cost, you can also use the nice utility called Serverless Cost Calculator.

Deploy Web App as Faas

If you are wondering whether you can deploy your web-app as FaaS, the answer is YES.

Though FaaS was aimed at running small functions in response to events, you can still deploy whole web apps as FaaS using some tricks.

• Since a full Linux container is running, you can deploy pretty much anything that runs on Linux.

• There is a project called Zappa which allows any WSGI-compatible web app on AWS Lambda. Usually, this works for most of the simple apps.

• If you want to take the full advantage of serverless infrastructure, most likely you will need to architect your application with FaaS in mind from the ground up.

• Lastly, there are frameworks like Serverless which make it easier to write web-apps, aimed at Serverless deployments.

Advantages of Serverless Deployments

1. Unlimited Scalability
   Since the containers are deployed on demand, you don’t have to worry about scalability. It will scale as long as you are ready to pay for it.
2. Instant Scalability
   In addition to unlimited scalability, AWS Lambda can spin up containers very fast. So if you have very spiky workloads, AWS Lambda can scale up in seconds. Whereas something like AWS AutoScaling can take a few minutes to deploy a new server.
3. No Server Management
   There is no need to look after servers or keep track of update patches and security fixes.
4. More Secure by Default
   Since there aren’t any permanent servers, an entire class of vulnerabilities disappears. For example, rootkits and botnets, where hackers gain unauthorized access to your server and install permanent programs to keep exploiting your deployment.
5. Cost-effective
   Costwise serverless deployment is cheaper if you have services that aren’t used very frequently. However, with AWS Lambda, most of the times you need to use AWS API gateway to serve HTTP traffic. AWS API gateway is relatively expensive. So, for high usage apps, something like AWS-Beanstalk can be a better option when cost is the main consideration.

Drawbacks of Serverless Deployments

1. Hard to Test and Debug
   Though with some plugins, you can test your serverless functions locally, it’s only an approximation. Like a regular server, you can’t log in and check process stats and memory dumps.
2. Increased Latency
   If the application doesn’t have regular traffic, the cloud provider will terminate your containers often. So when a new request comes, there can a few seconds of latency before the response is received by the client.

   Even for busy apps, containers are not kept in service after some minutes (observed around 45 minutes in AWS lambda). So some low percentile of your requests are still going to see the latency of a few seconds while new containers are spinned up.

3. Limited Execution Time
   Lambda functions can execute only for a few minutes. So you can’t use them for long running tasks, long video processing, and sustained connections like WebSockets.
4. Need Centralized Logging
   You need centralized logging service from the start, as you can not access the log files in FaaS deployments. Anyway, this is a better development practice.
5. Less Exposure To Developers
   Since serverless development is relatively new, not many developers are aware of operational gotchas that one may face from time to time.
6. Cloud Lock-In
   You will need to re-architect at least some portion of your application if you need to deploy it outside the datacenter of the cloud provider it was designed for.

   Also, cloud native deployments like AWS Lambda also tend to use other cloud-native services like DynamoDB which makes moving out of the cloud even harder.

Wrapping Up!!

Setting up, maintaining, and managing the physical and software components of traditional models can be expensive and time-consuming. The serverless computing approach promises to change all that. By using a serverless infrastructure service such as AWS Lambda, there is no need to maintain physical infrastructure. You also get higher scalability, higher performance, and cost benefits of the pay as you use model.

All the major cloud service providers have robust FaaS offerings and developers and organizations should try the one of their choice to experience the advantages serverless computing can provide over the traditional models.

We hope that this blog post has given you an idea to conceptually get started with serverless computing and FaaS.

Author's Bio:

Pritam Barhate