Concepts such as “serverless” databases or APIs fall into this category and fit the aforementioned model – the details for scaling capacity up or down are abstracted away, and you can run your database or API in the cloud happily without managing instances. Backups, downtime, and other concepts are of no concern. Of course, you still have the opportunity to configure specifics of the instance type, such as database parameters or what HTTP verbs your API receives.
Another major advantage is the reduction of cost. With a serverless API, such as AWS Lambda or Azure Functions, the only responsibility you now have is making sure your code runs. In a pre-serverless world, provisioning your instances, databases, and load balancers can run the risk of being costly, especially if not designed correctly. With Lamba or Functions, however, the cost is free for the first million requests, and 20 cents for every additional million requests!
It should be no surprise, then, that adoption for such technology has recently soared. According to The New Stack, “70 percent of enterprises have migrated a significant number of workloads to the public cloud. Among this group, 39% use serverless, 40% use containers, and 34% use container orchestration”(source: https://thenewstack.io/week-numbers-serverless-adoption-par-containers/)
This number will likely increase, as it is still a new technology and there are many additional features that will come.
Example of Usage
If you’re a bit unsure about the usage of it, I wanted to provide an example of how this could work in the world of AWS by way of Lambda.
Let’s say you want to allow users to embed custom watermarks on an image. This would be done via a webpage, where they type in text, upload an image, pick the style of watermark they want, and then hit the process button. The response should be their modified image.
To achieve this in a serverless capacity, we take advantage of the following services:
- S3 bucket to host static webpages – here we will put an html page that makes an XHR request out to API Gateway (note that you can also execute Lamba functions directly after uploading – see below)
- API Gateway – This will be our API that will route requests and responses. It will also be used to trigger our Lambda function
- Lambda – this will contain our code that processes an image and appends a watermark and text to it (and then writes to the S3 bucket)
- Route 53 – This will host our imaginary website and resolve to the S3 bucket, where we have our index.html
This API receives the request and payload, and then triggers the Lambda function, where the data is received. Lamba then executes its code and writes the modified image back to the S3 bucket, overwriting the original image (if you wanted to upload it directly to the S3 bucket originally).
The response then works its way backwards, where the S3 bucket writes the text “Your image is finished processing!” and renders the image back from the S3 bucket.
The Advantage of Serverless
A simple flow like above, with even as many as a million requests a month, would be still under ~$20 to host, assuming you perform some regular housekeeping on the S3 buckets (so you don’t have years of data sitting in there) To achieve a similar flow under a more traditional setup, the cost could be more than quadruple.
You also have many exciting ways to trigger these functions. Again taking the AWS example, it does not only have to fire from an API: it could happen when a user uploads an image directly to an S3 bucket, when something is inserted into a DynamoDB table, or even something wild and crazy, like using an Amazon IoT Button so that when you press your button, it automatically triggers a Lambda function to do something (like interact with your smart home and turn the lights on)!
The important thing to remember is that while there are many ways to achieve the above, the sheer lack of cost is so attractive and game-changing.
To see the full list of ways to trigger Lamba, check out https://docs.aws.amazon.com/lambda/latest/dg/invoking-lambda-function.html#supported-event-source-api-gateway
To see the Azure Functions equivalent: https://docs.microsoft.com/en-us/azure/azure-functions/functions-triggers-bindings
Downsides of Serverless
Nothing is perfect. While the cost savings and convenience are massive, there are still some downsides that are being worked on. The first is the number of programming languages supported. AWS takes the lead with C#, Python, Node, and Java, while at the moment Azure only offers support for C# and Node. There is no doubt that as this technology continues to develop, so too will the number of supported languages.
Additionally, right now things are in a state where it is difficult to debug. Let’s say your function executes, and it fails somewhere. When Lambda first came out, it was extremely difficult to pinpoint the problem, often resulting in the need to write out log files or output to the screen. It is improving, however, and services such as AWS X-Ray and Azure Application Insights offer you the capabilities of viewing, filtering, and gaining insight into data to identify issues and optimize your application.
In conclusion, we see that services such as Lambda and Functions offer some great new ways to deal with business needs at a fraction of the traditional cost. In time, as this emerging serverless technology becomes more adopted, there will no doubt be many amazing changes that take place, making it an even more attractive and powerful in the cloud space.
Interesting in learning more?