Although the cloud has revolutionized the way we manage applications, many companies still view their systems in terms of servers — even though they no longer work with physical servers. What if you take the concept of servers out of the equation and begin to think of cloud-based applications as workflow, distributed logic, and externally managed data stores? This report examines the new Serverless approach to operations.

Like many trends in software, there’s no one clear view of what Serverless is. For starters, it encompasses two different but overlapping areas:

Serverless was first used to describe applications that significantly or fully incorporate third-party, cloud-hosted applications and services, to manage server-side logic and state. These are typically “rich client” applications — think single-page web apps, or mobile apps — that use the vast ecosystem of cloud-accessible databases (e.g., Parse, Firebase), authentication services (e.g., Auth0, AWS Cognito), and so on. These types of services have been previously described as “Backend as a Service” or “BaaS”.

Serverless can also mean applications where server-side logic is still written by the application developer, but, unlike traditional architectures, it’s run in stateless compute containers that are event-triggered, ephemeral (may only last for one invocation), and fully managed by a third party. One way to think of this is “Functions as a Service” or “FaaS”. AWS Lambda is one of the most popular implementations of a Functions-as-a-Service platform at present, but there are many others, too.

Despite the name, it does not actually involve running code without servers. The name “serverless computing” is used because the business or person that owns the system does not have to purchase, rent or provision servers or virtual machines for the back-end code to run on.

With Serverless comes the following:

No server management (no need to manage any form of the machine)

Pay-per-execution (never pay for idle)

Auto-scale (scale based on demand)

Function as a unit of application logic

Serverless pattern encourages development focus on well-defined units of business logic, without premature optimization decisions related to how this logic is deployed or scaled. As a result, development focus is on a single function or module rather than a service with a large surface area. Serverless frees the software developer from deployment concerns and allows them to focus on factoring the application following logical encapsulation lines.

A typical example is an image uploaded to a file store, this event calls a serverless function which creates a thumbnail and stores this thumbnail back into the file store as well as recording the thumbnail location in NoSQL databases. The insert into the NoSQL database could then trigger further functions. This thumbnail creation function only runs on demand and the only cost incurred is how many times the function is invoked. The function will scale out in real time if many people are uploading images and then scale to zero once they are done.

However, the downside is that system monitoring and debugging becomes difficult and is based on logging available from the service, vendor lock occurs especially when leveraging events from other services, while the serverless compute may be cheap the other services may not be, also deployment mechanisms and IDEs are not typically prepared to manage serverless functions.

Simple HTTP Endpoint Example

(From Serverless Framework Github Repo).

The Serverless Framework — Build applications comprised of microservices that run in response to events, auto-scale for you, and only charge you when they run. This lowers the total cost of maintaining your apps, enabling you to build more logic, faster.

This example demonstrates how to setup a simple HTTP GET endpoint. Once you ping it, it will reply with the current time. While the internal function is name currentTime the HTTP endpoint is exposed as ping .

Quick Start with Serverless Framework

Install via npm:

npm install -g serverless

Set-up your Provider Credentials.

Create a Service:

Use Case: Wrapping an existing internal or external endpoint/service.

We need to create handler.js and serverless.yml files to describe and deploy our serverless function.

Invoke the function locally

Go to the terminal window and paste this string:

serverless invoke local --function currentTime

Which should result in:

Deploy

In order to deploy your endpoint simply run:

serverless deploy

The expected result should be similar to:

Usage

You can now invoke the Lambda directly and even see the resulting log via

serverless invoke --function currentTime --log

or as send an HTTP request directly to the endpoint using a tool like a curl

Coming Soon

Running a GraphQL endpoint with Serverless…

Like to learn?

Follow me on twitter where I post all about the latest and greatest AI, DevOps, VR/AR, Technology, and Science! Connect with me on LinkedIn too!