The Serverless Architecture

Serverless architectures refer to applications that significantly depend on third-party services (knows as Backend as a Service or “BaaS”) or on custom code that’s run in ephemeral containers (Function as a Service or “FaaS”). The term is misleading as 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.

Serverless is a new way to approach cloud computing. It is an approach that has been pioneered by Amazon with the AWS Lambda serverless compute platform. Serverless computing is based on an event-driven architecture and has functions as the unit of development.

This has been an evolution from the early days of computing when the concept of delivering computing capabilities over a global network was the goal. With the internet the web technologies started maturing and it created a need for hosting these websites. The Internet Service Providers (ISP)s came up and filled this need by providing the infrastructure and renting shared resources to meet the need. Global data-centers came up and traditional data-centers abstracted the hosting environment with limited elasticity and resource pooling. Scaling was achieved by adding more hardware. During this stage the consumers managed the application stack, OS, data, storage, networking and the hardware.

The next step in evolution with cloud technologies starting to mature was the emergence of Infrastructure-as-a-Service (IaaS) platforms like Amazon Web Services (AWS) and Google Compute Engine (GCE). These abstracted away infrastructure components into self-service models for accessing and managing compute (VMs or bare-metal), object storage, block storage, and networking services via APIs, and billed based on consumption. These virtualized data-centers abstracted the underlying infrastructure. Scaling was achieved by allocating more compute (VMs) and other infrastructure resources. Now consumers managed the application stack, data, and OS, while the IaaS provider managed the virtualization, servers, hard drives, storage, and networking.

The next big step was the emergence of Platform-as-a-Service (PaaS), which now added another layer of abstraction on top of the IaaS components, by providing a unified computing platform with a self-service portal to deploy applications. PaaS platforms like IBM Bluemix, Microsoft Azure, Heroku, Force.com and Google App Engine have become popular examples. PaaS abstracted the management of infrastructure services, with scalability, high-availability, and multi-tenancy as it’s core tenets. Now the consumers manage the application stack and data, while the PaaS provider managed the OS, virtualization, servers, storage, and networking.

In the last few years, AWS Lambda made another round of abstraction and brought the concept of serverless computing to the consumers. The Functions-as-a-service (FaaS) paradigm promotes self-contained, stateless chunks of code packaged into ‘functions’, that can be run or triggered, in ephemeral containers. All this is done without managing the underlying infrastructure or the language runtime needed by the code. The unit of deployment is functions. Serverless computing abstracted the language runtime. Consumers manage the application code in units of functions, while the serverless cloud provider manages the execution environment and everything else under it.

So what Is Serverless?

Sometime in late 2014, Amazon launched AWS Lambda which was a serverless computing platform that allowed you to have a microservices architecture in which it wasn’t necessary to manage the underlying infrastructure. The provider would auto-scale your application in response to load. Serverless architecture is a FaaS (Functions-as-a-Service). Serverless architectures have changed how applications are built and deployed at scale allowing teams to interact with increased autonomy and higher productivity. As microservices can now be decomposed into functions, decoupling can be done at a finely-grained level which provides the flexibility to map functions to events that can originate from different sources.

Serverless architectures does not mean that there are no servers. They will still have servers somewhere. What makes something serverless is, that as a developer you don’t have to worry or think about those servers. You can just focus on code. You also don’t have to worry about the administration.  When you’re ready to deploy code, you don’t have to provision anything beforehand, or manage anything afterward. There is no concept of an operating system. Everything runs in the cloud and the provider manages scaling for you. Even when the code is deployed you only pay for resources that you use.

Some of the providers today that provide their own serverless computing platforms are IBM OpenWhisk, AWS Lambda, Microsoft Azure Functions and Google Cloud Functions.

Let us consider a couple of use cases to understand how this concept works.

The first one involves the IBM OpenWhisk platform, which is is IBM’s serverless compute offering. OpenWhisk is an event-driven compute platform that executes application logic in response to events or through direct invocations–from web/mobile apps or other endpoints. OpenWhisk works through rules that bind events and triggers to actions. Web and mobile applications often invoke OpenWhisk actions directly through API calls via the mobile SDK. More commonly, Watson or other Bluemix services invoke OpenWhisk actions by generating events to which OpenWhisk actions respond. When an event or an API call invokes an action, OpenWhisk creates a container to run the action in a runtime appropriate to the programming language used. It supports the languages Node.js, Python and Swift. OpenWhisk also can run custom-coded actions packaged in a Docker container. IBM’s API Gateway provides security. To stop unwanted usage of the data you supply, you can ensure that only users with the correct authentication can access your APIs. Methods being supported include API key, API secret, and OAuth validation.

Use Case 1:

The first use case considered is Skylink, which is an application that uses IBM Bluemix OpenWhisk with the Cloudant, Alchemy, and Watson services to analyze and tag in realtime images captured by a drone.

A diagrammatic representation is shown below.



Shown is the IBM Bluemix platform that provides the Cloudant, OpenWhisk and the Watson services. The following steps are shown in the diagram.

1. User sends video for processing.
2. An action is triggered by the db write in cloudant to break the video into separate images. The actions are running in containers of the OpenWhisk platform.
3. The Watson Visual Recognition service then analyses each image and writes the results to the db.
4. The db write then triggers actions to send the Watson data to the user device.
5. The user clicks the tag in a thumbnail to see the object at the time-stamp in the video.

The following video shows the use-case.





Use Case 2:

Another use case is using Amazon AWS Lambda and Amazon Kinesis. Amazon Kinesis is a service which allows you to ingest realtime data such as application logs, website clickstreams, IoT telemetry data, and more into your databases, data lakes and data warehouses, or build your own real-time applications using this data.

The use case is illustrated in the diagram shown below:



The components involved in this use case are Amazon Kinesis, AWS Lambda, Amazon DynamoDB, Amazon S3 and Amazon CloudWatch.



1. Real-time event data is sent to Amazon Kinesis, which provides large-scale durable storage of the events for 24 hours and allows multiple AWS Lambda functions to process the same events.
2. In AWS Lambda, Lambda Function 1 processes the incoming events and stores the event data in a table in the db.
3. The Lambda function also sends the values to the monitoring of aggregated metrics.
4. Another AWS Lambda function, Lambda Function 2, stores the incoming events in the Amazon S3 storage for downstream processing and analytics.

In conclusion we can say that that Serverless is a new way to approach cloud computing which is based on an event-driven architecture and has functions as the unit of development. It is not meant to replace other computing platforms, rather it will augment them. It removes the need for the traditional 'always on' server system sitting behind an application thereby significantly reducing operational cost. It allows for more options on how applications can be built. It can be considered as a disruptive technology that will change how developers will code in the future.



Leave a Reply