Definition

For sure, a term ‘Serverless’ is a quite hot topic nowadays and as usually for trends, there is no ultimate clear view of what it means. My modest attempt to provide the definition for a concept of Serverless architecture is presented below.

Serverless architecture is an architectural approach (or style) of building an application without the usual server processes, but instead solely on a combination of third-party cloud-based Services, client-side logic, and on custom code that’s run in ephemeral containers (Function as a Service or “FaaS”). ¹

The core problem Serverless architecture tries to solve

The main problem is cost and effort:

• operational cost of owning servers (even virtual ones) usually doesn’t match to an average hardware utilization percentage. According to researches only about 10% of all resources is typically utilized by enterprise data centers. The reason are not only in redundancy for high availability but also due to significant reserved capacity for quick scaling in case of spike in load or reserved capacity for expected grow.
• development and support effort. The smart business always focuses first on what makes their profit and then tries reasonably to outsource everything else. This helps to increase revenue and save money. Serverless can be considered as a combination of using out-the-shelf solutions and infrastructure support.

Prerequisites for the Serverless emergence

Based on my vision following we can highlight following prerequisites of the emergence:

1. JavaScript and browser capabilities put to life an idea of single-page application using no external software platform. This gave us rich browser-based clients with business logic running locally.
2. A wide use of RESTful web services and stateless approach. REST paradigm as a simplified version of traditional SOAP web services gave a boost to a number of services available and provided through the Internet.
3. Significant evolution and a new level and variety of cloud-based services provided ability to fully replace a big chunk of traditional functionality like authentication/authorization (Auth0) or even DB (Firebase real time DB or Amazon DynamoDB)
4. Emergence of a new _aaS concept. This time, it was a continuation of containerization and cloud computing: Function as a Service (FaaS) which is about running back end code without managing your own server systems or your own server applications. The most well known FaaS platform is AWS Lambda

Major elements of Serverless architecture

An author of the book Serverless Architectures on AWS: With Examples Using AWS Lambda proposes five principles of serverless architectures:

• Use a compute service to execute code on demand (no servers).
• Write single-purpose stateless functions.
• Design push-based, event-driven pipelines.
• Create thicker, more powerful front ends.
• Embrace third-party services.

Similarities with other architecture styles

Service-oriented architecture (SOA): Idea of autonomous functions in Serverless is similar to the core concept of autonomous services in SOA. Other crucial ideas of SOA found their place in Serverless: service reusability and autonomy, composability, granularity.

Microservices: Serverless architecture embodies many principles from microservices too. For example, every compute function could be considered to be its own standalone service. Ideally, microservices should be easy to replace, with each service eventually written in an appropriate framework and language. This fully is supported in FaaS where you can easily replace one function with another one even it could be written in a different language.

Containers as a service (CaaS) CaaS is considered usually a special version of Platform as a Service (PaaS) which provides containerization capabilities in cloud. Clients are also capable to deploy their code (containers) without worry about required resource provisioning and necessary scaling. However Serverless/FaaS provides scaling capabilities which is measured milliseconds to start instead of minutes for CaaS.

Known use cases

1. Application back end - the back-end is build using solely BaaS or FaaS, or even mixture of them. Success examples are:
   • An online education platform A Cloud Guru²
   • A search platform for commercial property Commercial Search³
   • A platform to create tour books for property X Spaceful (before called Property Tour Pro) ³
   • A platform to add personalization capabilities to web sites Unless⁴
2. Data processing and manipulation - all logic is presented in FaaS functions and they are invoked by events or on chunks of a data stream. An success example:
   • Real-time Data Processing using AWS Lambda on Thomson Reuters⁵
3. Infrastructure automation - because FaaS functions may be invoked in reaction to an event in infrastructure they could be used to perform actions there. For example in the course on CloudAcademy there was presented an approach how to achieve multi-site, multi-master for Amazon DynamoDB using AWS Lambda.

Pros

• High cost efficiency in case of occasional requests or inconsistent traffic (short unpredictable spikes).
• No need of investment in infrastructure upfront.
• Operational cost known upfront and can be predicted based on number of customers
• No need in infrastructure operational team (but DevOps are highly required)
• Easy to start, short time to market for new ideas
• Significant effort reduction to achieve scalability and scalability in milliseconds.
• Quite good availability and durability metrics out-the-box.
• Reduced packaging and deployment complexity.
• Code optimization may lead to explicit operation cost reduction.

Cons

• There is a minimum delay between request and triggering FaaS depending on the size of the function from 200ms up to seconds for any FaaS providers. That said if it is required a low-latency trading application then Serverless is not a choice, no matter what language or vendor is chosen.
• Decentralization by Serverless nature leads to increasingly difficult integration testing.
• No option to retain state at all.
• No available discovery capabilities in contrast to micro services/SOA.
• No local environment as results no option to run, test and debug locally.

Major risks and pitfalls

• Immaturity. The oldest AWS Lambda is a bit more than 2 years old. The result is in immature tools for deployment / application bundling, configuration, monitoring / logging, and debugging.
• Vendor lock. Without use of special open source frameworks like Serverless Framework the migration to switch between vendors could be quite high.
• Due to multi-tenancy and cloud nature, security quality attribute should be addressed with additional attention. For example, only a few vendors currently offer complains with such regulation like HIPAA, PCI DSS etc for their FaaS platforms.
• If the traffic is uniform and would consistently make good utilization of a running server then there is no cost benefit or even more spending more using FaaS.
• There is almost no control what FaaS/PaaS/BaaS vendor will do with their platform (unexpected updates, outages, deprecations etc.)
• The highly inefficient implementation may cause a quite high cost of operation.
• Because each Function is autonomous and includes all code dependencies a potential big code duplication or dependency hell may appear for a project consisted of hundreds of Functions.
• An external state storage must be used and it will be always slower than a local memory storage. It has direct an impact on performance and response metrics and should be considered.