Serverless computing sounds at first like some sort of magic trick where applications have finally figured out how to work by themselves without servers. This isn’t the case at all, and servers are going to be around for quite some time. What “serverless” actually means is not having to worry about or manage the server, which is quite convenient for developers who can use the extra time to work on their applications.
How is this different from Platform as a Service (PaaS), you may ask? In both PaaS and Software as a Service (SaaS), the conventional IT approach is still the same except the network, storage, servers, virtualization, OS, middleware, and runtime are delivered as a service. This still means that your process is perpetually running on the server and waiting for HTTP requests or API calls. Most applications in use today are based on the client/server architecture where a client runs on the customer’s device like a mobile phone and the server handles requests. This is why servers are required to remain online at all times and need to be provisioned in order to handle any spikes in activity.
Backend as a Service
“Serverless” computing can basically be divided into two types, Backend as a Service (BaaS) and Function as a Service (FaaS). Let’s look at BaaS first.
BaaS implies that a developer only focuses on the client side of things, or in other words, a mobile application, and uses services like Firebase for real time DB, AWS incognito LDAP or 0Auth for authentication, and encryption protocols to keep your data safe. This not only eliminates the need to set up a resource-consuming server but also makes it possible to develop applications or services without wasting time developing individual backend resources for each.
Where in the past developers had to build APIs, BaaS allows users to use a single stack of common third-party APIs. This saves both time and money as setting up a BaaS can be done in a few minutes and does not require hiring backend developers. Conversely, developing your own backend resources could take weeks or even months and requires hiring additional employees. The big difference here is that with PaaS you still need to build a client and a server, but with BaaS you can focus on client-side applications and use a number of third-party applications to run your server.
Function as a Service
Even with a good cloud platform as a service, you still need to build APIs for your client application to communicate with. In true “serverless” computing, your client talks directly to the database through a basic authentication layer. This is Function as a Service.
As mentioned earlier, clients require a server that’s perpetually running and waiting for a request to trigger an action. While using FaaS, the developer still writes some server-side code, but this code is run in stateless compute containers that are event-triggered. What this means is that there is an event mechanism that triggers the execution of a piece of code that is referred to as a function. These event-triggered containers are completely managed by a third party, so all the developer has to focus on is the actual code itself.
These containers are also ephemeral, which means they are decommissioned as soon as the execution of the function ends. The best part is that usage is measured in units of 100ms and users are only charged for the resources consumed when the code is actually running. This beats provisioning your own servers to handle increased usage or a spike in requests that trigger functions. Unlike most PaaS systems where you still have to consider scaling, FaaS brings much-needed transparency to scaling up or down and can do so for every individual request.
AWS Lambda
The best known vendor host for FaaS is AWS Lambda, which has stepped up the game from using third-party backend resources to running event-triggered functions in containers. What AWS Lambda does is run your code on high-availability infrastructure and manages all resources, including server and OS maintenance, capacity provisioning, automatic scaling, code monitoring, and logging. All that’s left for the developer to do is write the code and you’re good to go.
AWS Lambda runs this code in response to event triggers, and it also helps you build for AWS services like AWS SDK and Amazon Dynamo DB. Apart from the zero administration cost associated with its use, AWS Lambda runs your backend code on its own AWS compute fleet, Amazon Elastic Compute Cloud (EC2). Another place Lambda distinguishes itself from other PaaS’s is by supporting securely running Linux executables by calling them out from a supported runtime like Node.JS. The free tier is another bonus where usage below a certain threshold doesn’t cost you anything and doesn’t expire until 12 months after account signup.
Microsoft Azure Functions
Amazon isn’t the only FaaS provider out there. Microsoft Azure Functions is another great solution for running functions in the cloud. Azure Functions gives you a wider choice of development languages and supports F#, C#, Node.JS, Python and PHP, batch, bash, or any executable. It uses the same pay-per-use pricing model as AWS Lambda and supports NuGet and NPS so you can use libraries that you’re already familiar with.
Azure Functions also features Integrated Security and you can protect your HTTP-triggered functions by using 0Auth providers like Azure Active Directory, Facebook, Google, Twitter, or even your Microsoft account. A number of development tools are also supported like Visual Studio Team Service and GitHub. The Azure Functions runtime is open source and available on GitHub.
Templates to get you started with key scenarios are also provided, which makes development a breeze. A few of these templates are Blob Triggers, Event Hub Triggers, Generic Webhook, GitHub Webhook, HTTP Triggers, Queue Triggers, Service Bus Topic Triggers, and Timer Triggers. Apart from supporting Triggers, Azure Functions also supports bindings, which are ways to simplify coding for input and output data. Microsoft usually likes to keep its customers boxed in, but, surprisingly, Azure Functions supports integration with a number of third-party services.
Google Cloud Functions
With all the buzz about serverless computing, you can’t expect Google to not show up to the party, and Google Cloud Functions is how they did it. Cloud Functions can be triggered asynchronously through events from Google Cloud Pub/Sub, Google Cloud Storage or even HTTP invocations. Cloud Functions is different from AWS Lambda in the sense that it explicitly creates a set of instances in the cloud so that you can always check the number of machines created and monitor the load of your cluster.
Though Cloud Functions is still in the Alpha stage and supports only JavaScript and has a limit of 20 functions per project, the expectation is that it will soon support Java and Python and remove the function limitation. Logging is supported by integration with Google Cloud Logging, and users have the added advantage of Google’s superior network.
It’s about time
Without the requirement to provision or configure servers and virtual machines, developers all around the world are going to benefit immensely by the amount of time, effort, and money this technology saves them. Added to the fact that the end users are going to have better applications that require less effort to release updates, this really does sound like a win for everyone.
