Serverless Architectures Review, Future Trend and the Solutions to Open Problems

Lately, the popularity and adoption of serverless computing or Function-as-a-Service have been grown substantially, and it emerges as a better way to manage cost, reliability, availability, and scalability. This paper presents a detail of serverless offerings from leading cloud providers such as AWS, Azure, Google Cloud Platform and some open source. It compares them side by side in the relevant category like compute, storage, database, messaging, API management, and tooling. Also provides comparative analysis on available serverless architectures for the most common use cases within cloud provider's environment. It will also emphasize on benefits, open problems, possible solutions, and the future of the technology.


Introduction
Serverless computing is an evolutionary technology that enables the developer to build and run code without worrying about servers. In these type of implementation, no need to own any infrastructure. In case of three-tier architecture, presentation tier turns in thin client-side code placed in object storage delivered as Storage as a service (SaaS), domain logic can run as Function as a service (FaaS), and data storage tier is replaced with Backend as a Service or (BaaS). In the serverless architectures, major portion of the application run in ephemeral stateless containers provided by cloud providers. These containers trigger on events and terminate after execution. So, this type of cloud computing is otherwise called Function as a Service (FaaS). Over 10 years prior journey began with virtualization then Platform-as-a-Service (PaaS), and now Function-as-a-Service. This evolution is well drafted in this timeline Figure 1. FaaS enables code to run without provisioning or managing servers. Some characteristics are as follows.
1. Any type of backend code in any popular programming language 2. Just worry about uploading code, nothing else. No administration required. 3. Auto Scale 4. High availability 5. Code can be triggered by most of the cloud services as well as APIs In serverless applications, all the components which form the architecture don't require provisioning, maintenance, and administration of the servers. Depending on the use case these components may include compute, storage, databases, machine learning, stream processing, message queueing, streaming, etc.

Serverless Solutions
Serverless is a combination of 'Function as a Service' and 'Backend as a Service' [2]. At high level 'Platform as a Service' looks similar to serverless approach, however, it is not. As per Adrian Cockcroft, "If your PaaS can efficiently start instances in 20ms that run for half a second, then call it serverless.". PaaS platform is not scalable as FaaS does. [2]. I would say, Serverless is like a public transport. Use it and pay just for the use. It can scale as well.

Serverless Solutions from Leading Providers
Serverless technology provides an abstraction to servers, infrastructures and operating systems. In recent years almost, all the major cloud provides extended their cloud serverless offerings. Following Table 1 is listing down all the serverless offering from top providers.

AWS
Amazon Web Services (AWS) [3] is the market leader in cloud space they have the most advanced set of serverless products. These fully managed services enable developers to build and run serverless applications. Recently AWS launched Serverless Application Repository which provides starting point for serverless projects. This repository has several publicly available serverless applications which can be searched, deployed and published in few clicks as shown in Figure 2. Developer can search multiple serverless applications deploy and modify them as per their requirement and even integrate them.

Serverless Application Use cases
Web applications and backends: For example, we can consider serverless News application. In this case, we can host website code in S3, Lambda can be used to perform data processing unit. It will get News data from DynamoDB and expose it through API gateway. Figure 3 is demonstrating this architecture.
Following Figure 4 is demonstrating serverless backend for mobile apps.

Data processing
The real-time data processing system can be build using AWS Lambda, Amazon Kinesis, S3, and DynamoDB. Figure 5 is suggesting sample serverless architecture for photo thumbnail creation.
Following Figure 6 demonstrates real-time data processing. Cloud Endpoints: build, deploy, secure and manage APIs on any Google Cloud backend. Apigee: A cross-cloud API platform which enables control and visibility into the APIs.

Analytics
Amazon Kinesis is a streaming data platform to analyze real-time data. Amazon Athena enables SQL querying for data in S3.
Azure Stream Analytics: Real-time streaming data and SQL like language querying Event Hubs: to process, route, and store IOT devices data.
Cloud Dataflow: managed service for transforming and processing real-time data stream or in batch.

Intelligence
Amazon Machine Learning: service to perform predictions in real-time at scale. SageMaker: managed platform to build, train, and deploy ML models at scale. Amazon Rekognition Image: image and video analysis. Amazon Polly is a Text-to-Speech (TTS), Amazon Lex is a service to build conversational interfaces (bot).

Scheduled Tasks, Automated Backups, and log analysis
Lambda is great for scheduling tasks, log and build scheduling. Figure 7 shows log collection process and log analytics process using kinesis and Elasticsearch.
As a complete serverless web application, developer can envision something like as in Figure 8. In this application website code is hosted at S3. When a browser makes a call for webpage, Web page code checks for authentication token in case of new login call redirects to Amazon Cognito for authentication. Once web page gets token it makes a call to Lambda using API Gateway. Lambda gets data from DynamoDB and returns back to browser through API Gateway.

Azure
Microsoft Azure [4] holds second position in the cloud market share. They provide a good set of toolsets in serverless space. Azure can be the best choice if respective organization is already using a significant number of Microsoft software.
Some of the following use cases and architectures recommended by Azure.

Web Application Architecture
Azure Functions are FaaS offering from Azure and can be exposed using WebHook URL in order to work as a microservices. This is good architecture to perform CRUD operations of a single web page. Figure 9 demonstrates targeted advertising app as per the user preferences.

IoT backend
Azure Stream Analytics receives messages from the Internet of Things (IoT) devices then it calls an Azure function to process, transform and insert in Azure CosmoDB as describes in Figure 10.

SaaS integration
Functions support triggers based on activity in a Software as a service (SaaS)-based application. Following Figure 11 demonstrates an example to save a file in OneDrive, which invokes an Azure function. In the function, we can modify excel and can create analytical charts using Microsoft Graph API.

Mobile backend
Azure Functions support HTTP triggers and output bindings. These HTTP triggers can be customized to respond to WebHooks and work like APIs. These APIs work as a backend to mobile apps. Figure 12 demonstrates an example, a mobile phone app captures the image and calls the Azure function to get authorization token to upload to blob storage. Another Azure function resizes image and uploads to blob storage.

Google
Google [5] is a third major player in the cloud market share. It also has a wide variety of serverless offerings.
Over the years, Google Cloud Platform (GCP) has launched several serverless products covering application development and analytics. Figure 13 gives high level evolution of serverless in GCP.
We can summarize Google serverless applications in three most used use cases.
 Web Backend: Browser  App Engine  Datastore  Microservice: Microservice Cloud Function  Datastore  ETL: File  Cloud Dataflow  BigQuery Following Table 2 shows common use cases with Google serverless technology. Following Figure 14 shows serverless architecture using Firebase and Google Cloud Function.
In this example python program is reading sensor data and inserting in the Firebase database using HTTPs call. Firebase updates all the devices in real-time. Firebase update trigger notifies cloud function. In case of critical values of sensor data, it notifies the user using Firebase Cloud Messaging (FCM).

Open Source
IBM's OpenWhisk [8] is event-driven compute service (FaaS) which enables the developer to create actions without worrying about server provisioning in IBM Bluemix. IBM Bluemix (now is IBM Cloud) is the place for developers to create, deploy and manage application in the cloud. IBM Bluemix provides startup kit for most of the application components with easy integration. It is the place for rapid development and deployment of the applications. Following Figure 15 shows IBM Cloud Functions (based on Apache OpenWhisk) Serverless Architecture for a web application.
'Serverless Framework' [9] is open source toolkit to develop and build web, mobile and IoT applications using AWS Lambda, Azure Functions, Google Cloud Functions and IBM OpenWhisk. It is very useful for rapid development, testing, and deployment in a single environment to supported cloud providers. No need to worry about infrastructure provisioning and scaling. Following Figure 16 shows quick hello-world FAAS deployment.   [9] There is an open source project name 'APEX' [10] enables developers in managing AWS Lambda. It empowers developers to develop Lambda functions in any language even that is not supported by AWS. APEX project contains project.json configuration file, that has the definition of Lambda functions. Deployment can be performed by just running simple command '$ apex deploy'. It also provides tooling for testing, rollback, tailing logs, etc. Another related project 'APEX Up' is very useful if requirement is to develop a web application, API or static website. Basically, it provides an abstraction to Lambda.
Cloud Functions for Firebase allow developers to invoke backend code on Firebase feature events or HTTPS requests. The code is put away in Google's cloud and keeps running in an oversaw situation as FaaS.
For Google Cloud Platform developers, Cloud Functions serve as a connective layer allowing the developer to weave logic between Google Cloud Platform (GCP) services by listening for and responding to events.
For Firebase developers, Cloud Functions for Firebase provides a way to extend the behavior of Firebase and integrate Firebase features through the addition of serverside code.

Benefits and Open Problems
Serverless technology is evolving so fast, many of the drawbacks of today will not be applicable after some time. There are several reasons to bat for serverless technology. Serverless can be the best fit for seasonal apps like tax filing, games, and chat apps.
Pros  Scalability: Imagine game Pokémon GO, Is it possible without cloud. With serverless scaling is no limit. Provisioning infrastructure is high risk.
Applications should scale or shrink as per demand. Which leaves vulnerabilities open also it provides hacker wide attack surface due to highly distributed nature. "According to the audit of more than 1,000 serverless apps by Israeli security firm PureSec, a fifth of them have critical security flaws. Most of these vulnerabilities were caused by copying and pasting insecure sample code into real-world projects, poor development practices, and lack of serverless education. The vendor has published a paper describing common errors to avoid. -NETWORK WORLD" [11].
 Vendor lock-in: This is the main concern and impediment in even cloud adoption. Serverless components are directly written in the provider's environment. It is really complex to move these applications from one provider to another.  No local data storage: FaaS is a stateless approach which does not retain any local data, so developers need to store data in the database only.  No control to the underlying platform: Developer does not have access to the underlying environment in case they need to interact with the operating system.  Execution Limit: There is an execution limit for programs to run. AWS Lambda has the hard limit of 5 minutes.

Future of Serverless and Solutions to Problems
Serverless systems are still in their infancy. Common standards such as platform independent function skeleton, the structure of passing event parameters, constant declaration, permission declaration, secret key management, and other configuration declaration are missing. In coming years, we will see more standardization around this. We can expect some solutions to the common pain points. Let's talk about these pain points and solutions.

Serverless Application Development, Configuration, Debugging, Logging, Monitoring, and Deployment
Building, configuring, debugging, logging, monitoring, and deployment is the most critical problem in the serverless technology adoption. In coming years some standards will be set across cloud platforms as all the top cloud providers are pitching for it. These efforts should result in some kind of platform agnostic serverless platform. All cloud providers should support open source IDE for debugging, deployment and configuration. API Gateway configuration should be streamlined and should be configured through the simple configuration file. If developer deploys from IDE, it should create Lambda and API gateway. Good to see AWS has taken initiative in this direction and started building support tooling for its Lambda-based serverless infrastructure. At Serverless Conf in Brooklyn 2016, Tim Wagner, general manager of AWS Serverless Compute (AWS Lambda, and Amazon API Gateway) announced "Flourish, a new open source project to create a full serverless runtime application environment" [12]. Hope, these things eliminate major hurdles in tooling. In the next 2-3 years, we can see the wide adoption of serverless.

Execution Duration, Startup Latency, and Session Management
First solution for this problem can be allowing Lambda to be instantiated on first application call with tentative active lifespan. Whenever any application starts and expected to call Lambda should activate the Lambda ahead of time for the tentative time span. Each client should pass unique globally unique identifier (GUID) in each call to identify Lambda instance and can be used for session management. If Lambda instance with GUID is not found or on first call its blank, new Lambda instance should be created and new GUID should be returned so that client can use for subsequent calls. If multiple Lambda instances are required multiple Lambdas with different GUIDs can be used. I agree in some cases client call will not find Lambda instance alive. That type of case can also happen in non-serverless environment. Figure 17 is demonstrating this logic.
Another solution can come at premium cost which can allow certain connections to be kept alive all the time and can be set as sticky endpoint.
Execution duration is usually enforced by cloud providers. Long running tasks can be broken down into reasonable chunks and can be run parallel in multiple lambdas.

Vendor lock-In
A common open source platform to develop and deploy on multiple cloud environments can eliminate vendor lock-in problem.

New Technology and Security
Over the time serverless technology will get mature and people will get more awareness. The developer will follow new evolved security guidelines in order to avoid vulnerabilities.

Local Data Storage and Platform Access
These are not that critical. These requirements can be solved using the workarounds like storing in the database and for some special cases where platform access is required, containers can be used.

Conclusion
This paper provides a guide to technical audiences on how to best fit various serverless cloud component for the different kind of use cases and the serverless offerings from leading cloud providers. As we saw all cloud providers provide almost all kind of serverless components, but still AWS is leading the way. Google is good in Artificial Intelligence and mobile app use cases. Azure is well suited for companies who are already having a good establishment of Microsoft products.
After reviewing all these offerings in detail, it's very clear that AWS is much mature and have a variety of product line compared to others. AWS Lambda has several triggering points which provides more flexibility to architects. Lambda@Edge is really handy if it is required to run at edge location. GCF is not having this capability yet other hand Azure is limited to IoT only. Database and storage prospect all the three providers have the almost same capabilities. But still as per usability prospect, I liked GCP Firebase and it is quite famous in the mobile world. In messaging segment all three providers have good platforms. Workflow is the area where all the three need to go long way. I used AWS Step Functions which is quite promising but complex to work with. Till this time it is not allowing to modify workflow when deployed, developers need to recreate every time. This behavior is not developer friendly. There is K2 Workflow product which is having good workflow capabilities much advance than others. It is worth considering in workflow use cases. Azure is having the edge on SaaS add-on capabilities. In terms of AI and machine learning, Google is having a long history. It has some of the well-known services in Deep learning, TensorFlow, Virtual reality, and Augmented Reality. Everyone is looking for when open source platforms will come into existence that will allow developers and architects to choose appropriate serverless component disregard of the cloud provider. Other hand Microservices are especially suited for serverless in terms of cost and performance. I will cover that area in next paper.