Serverless Architecture

Serverless architecture, often referred to as “serverless computing” isn’t completely serverless as its name implies. Serverless is a usage-based cloud service in which the provider manages the servers. This is far easier and efficient for most users of cloud computing.

Also known as Function as a Service (FaaS), serverless executes application logic without storing data. A developer taking advantage of FaaS still writes the server-side logic, but it runs in ephemeral stateless containers. Rich client applications, including mobile apps, take advantage of cloud-based infrastructure known as Backend as a Service (BaaS).

Use of the term, “serverless” dates back to 2012 by some accounts. However, AWS accelerated mainstream use of the term in 2014 when it introduced Lambda, the first serverless computing offering by a public cloud vendor. In 2016, Google Cloud introduced Google Cloud Functions, Microsoft Azure introduced Azure Functions, IBM Cloud introduced IBM Functions, and OpenWhisk open source project made its debut.

Serverless is sometimes confused with cloud computing generally or Platform as a Service (PaaS). BaaS and FaaS are both service options provided by cloud providers but FaaS differs from PaaS in a couple of important ways. For example, FaaS automatically scales, but PaaS doesn’t. Also, FaaS can bring entire applications up and down, which PaaS was not designed to do.

Serverless architecture uses a great deal of application granularity; it is suited to today’s world of microservices rather than the earlier era of monolithic architecture.

Serverless Examples

• A photo app user chooses a photo for automatic resizing. The photo is sent to an Amazon S3 bucket which uses serverless to trigger the appropriate Lambda function. The output is a photo in the size(s) the user selected.

• An in-app game developer wants to enable in-app purchases that are less cumbersome because app reviews have suffered. Players can now hover over a product that they wish to purchase for their avatar. Player A hovers over “Neo sunglasses,” which triggers virtual product and purchase functions via an API gateway. Each of the serverless functions uses a database. Within seconds, the avatar appears wearing the sunglasses, which may be removed or put on again at will since the avatar now “owns” the sunglasses.

Serverless Use Cases

• Web applications.

• Asynchronous messaging processing. For example, where the application’s UI response time and the recording of an accurate transaction history are both important.

• Chatbots that need autoscaling capabilities.

• High-scale stream processing.

• Mobile app back ends.

• Batch jobs.

• Multimedia processing.

• Data processing.

• Chatbots and virtual assistants.

• IT automation.

Severless Benefits

• Overhead reduction. Applications can run without servers using FaaS, so there are no servers to provision or manage.

• Autoscaling. FaaS scales automatically, upward and downward, so customers do not pay for idle capacity.

• High availability. Application availability is a non-issue since FaaS and BaaS availability is a non-issue.

• Choice. FaaS allows developers to use popular languages, and libraries (see service or project specifications for details).

• Cost. Like PaaS and IaaS, with serverless the cloud provider owns the hardware and software elements. Server management costs are also outsourced.

• Simplicity. Deploying a FaaS function is as easy as uploading code; deploying a server involves scripts and resource-oriented decisions.

• Speed. Since serverless takes servers and their administration out of the picture, it saves precious IT time. It also accelerates experimentation and prototyping.

Serverless Drawbacks

• Stateless versus state. The stateless nature of FaaS can be an issue for an application architecture that uses state-oriented functions.

• Timeouts. FaaS function timeouts can impact application architecture if the application includes tasks that exceed the timeout limit.

• Startup latency. FaaS startup latency may preclude extremely time-sensitive use cases such as algorithmic trading.

• SLAs. A lack of SLAs has been an issue. In October 2018, AWS announced a monthly uptime for Lambda of 99.95%.

• Function configurations. The ability to configure FaaS functions may be limited.

• Concurrency limits. The number of allowable concurrent FaaS functions is limited. If that number is exceeded as the result of simultaneous testing and production, shared enterprise accounts, accounts that span multiple cloud services, or more likely, a confluence of factors, production application performance could suffer.

• FaaS monitoring. The two issues here are how much data the vendor provides and the general difficulty monitoring ephemeral containers.

• Vendor lock-in. Cloud providers want to make it difficult to move to another provider. Two ways are to make the tools specific to the platform and design functions differently.

• Control. The vendor has complete control of the infrastructure, pricing and features.

• Cost. Serverless isn’t always cheaper than other options, so it’s wise to understand the cost/benefit tradeoffs versus other options. With FaaS, functions cost nothing until they’re invoked.

Serverless Security

• Expanded attack surface. Any new element in an ecosystem adds potential opportunities for breaches. Also, serverless applications have more components than applications using traditional architectures. Each component is a unique entry point into the application.

• Function permission. Sometimes broad privileges may be applied to a range of functions when narrower permissions would be wiser.

• Multitenancy. Other customers shouldn’t be able to see your data, but it may be possible. This is a general cloud issue which the major providers have addressed proactively.

• Third-party software dependencies. Functions may be dependent on third-party software that has been compromised.

Getting Started with Serverless Architecture

The best way to get started with serverless architecture is to fully understand everything in this article: what it is, what it isn’t, its benefits and drawbacks so appropriate use cases can be defined.

Specifically, if you’re going to add serverless to an existing application or build a new serverless application, consider the following:

• Understand what serverless is and is not.

• Understand the tradeoffs between serverless applications and applications using traditional architectures.

• Decide whether you’re going to build a serverless application or modify an existing application to take advantage of BaaS, FaaS, or both.

• Choose a provider (likely one with which you’re already working).

Assuming you’ve chosen AWS Lambda, a particularly popular Serverless solution:

• Set up a Lambda function (memory and storage requirements, triggers, access).

• Set up the Amazon API gateway.

• To adapt an existing application, use AWS Step Functions for workflow management.

• Set up access and security with Amazon Identity Access Management and the Cognito service.

• For logging and monitoring use AWS Cloudwatch and X-Ray.

• If local application testing is desired, use the AWS Serverless Application Model.

• Address compliance requirements.

• Compare the serverless architecture pattern against common patterns for the same type of application.

How to Manage Serverless Architecture

As the name suggests, IT does not manage the servers in the case of a serverless cloud service. For on-premises FaaS implementations such as those enabled by Apache OpenWhisk, Kubeless, and OpenFaaS, the servers are managed in-house.

While the usage-based cloud benefit does not apply in an on-premises FaaS implementation, it is possible to achieve greater server utilization and developers still benefit from the abstractions serverless provides.

However, there are still operational issues to consider, such as permissions, security, dependencies, and other issues, depending on the application’s design, that don’t go away.

And the key question: do you have the in-house expertise you need to manage serverless? As of 2019, severless remains an emerging technology, so don’t assume your in-house cloud experts or developers are already experts.

The Future of Serverless Computing

As serverless options become increasingly popular, the following will likely unfold:

• More and better tooling. This is a market maturity issue, and it’s also a function of popularity versus other options. The more popular serverless becomes, the more tools and open source projects will emerge.

• Best practices. Since serverless is a relatively new concept, there aren’t a lot of best practices yet, but serverless architecture patterns are available for many of the use cases noted above.

• Serverless-first applications. Instead of modifying applications to take advantage of serverless options, more serverless applications will likely emerge for some use cases.

• Frameworks. Additional frameworks will emerge that make it easier to work with one rather than another vendor. Current examples are the Fn Project, which is a container native open source framework; and Serverless Framework, a free and open source framework that enables serverless application deployment to multiple FaaS providers.

• Private FaaS. FaaS already can be implemented on-premise. How popular that is versus a cloud service or hybrid cloud implementation only time will tell.