Is Serverless Computing Really Serverless?
Everyone seems to be climbing onto the ‘serverless’ bandwagon in the tech world, from our favourite entertainment provider Netflix, to fashion retail companies like Nordstorm, not only for their testing environment but in production. With such tech giants embracing serverless, it’s safe to say that it is here to stay.
But, is serverless really serverless? Where will your code run if not on a server?
Serverless does not mean your code is not running on a server, instead, your cloud provider runs the server. It is a cloud-computing execution model in which the cloud provider runs the server, and dynamically manages the allocation of machine resources. The beauty of this is that your infrastructure is managed by your cloud provider and you do not have to worry about your server going down. Commonly called a Function as a Service (FAAS), AWS was the first to introduce this with its AWS Lambda Service, Google followed suit by introducing its Google Cloud Function. This blog series will focus on how to get on board the serverless train using AWS Lambda. The Lambda function manages both the execution of your function along with the resources that need to be provisioned, hence you can focus on the code and business logic and not get fretted by the infrastructure.
What is the architecture behind the serverless model?
Here, you can see that the two outer layers, ie, Compute Substrate and Execution Environment are being taken care of by AWS Lambda, you choose the lambda and deploy your function. Internally, your code runs in containers on AWS VMs. The first time your Lambda function is invoked, the code is downloaded, a new container is started, the environment is bootstrapped and your code is executed.
"There's no servers to manage or provision at all. This includes nothing that
would be bare metal, nothing that's virtual, nothing that's a container --
anything that involves you managing a host, patching a host, or dealing with
anything on an operating system level, is not something you should have to do
in the serverless world."
Chris Munns, senior developer advocate for serverless at AWS, at re:Invent 2017 conference.
How does it work internally? Is your container secure? Is your container running only your code?
When a Lambda function is created an execution environment is created for it and the function code runs in it. The execution function is present for the lifetime of the function and is then destroyed. Each execution environment hosts one concurrent invocation but is reused in place across multiple serial invocations of the same function. Execution environments run on a micro VM that is dedicated to an AWS account but can be reused by execution environments across functions within an account. MicroVMs are packed onto an AWS owned and managed hardware platform (Lambda Workers). Execution environments are never shared across functions, and microVMs are never shared across AWS accounts.
In short, your container can have all your lambda functions respective execution environments, for example, if you have a function A with Python 3.6 as the environment and another function B with python 3.7, both the environments can run in the same container, within the same AWS account, but even if functions A and B both have the same execution environment say python 3.7 they would not be sharing an environment, instead two different ones would be created.
How much does it cost?
Lambda counts a request each time it starts executing in response to an event notification or invokes call, including test invokes from the console. You are charged $0.0000002 per request for the total number of requests across all your functions.
Duration is calculated from the time your code begins executing until it returns or otherwise terminates, rounded up to the nearest 100ms. The price depends on the amount of memory you allocate to your function.
In the AWS Lambda resource model, you choose the amount of memory you want for your function and are allocated proportional CPU power and other resources.
An increase in memory size triggers an equivalent increase in CPU available to your function.
The Lambda free tier includes 1M free requests per month and 400,000 GB-seconds of compute time per month.
AWS Lambda has various use-cases and if used correctly and effectively can save you a lot of time and money. A key factor that leads to skyrocketing Lambda bills is not knowing the actual amount of memory and time to be allocated for your functions depending on the use case. To get a more hands-on feel do read our blog on how to get started off with AWS Lambda.