WHAT IS SERVERLESS COMPUTING

Alpacked

TABLE OF CONTENTS

01.Function as a Service and Serverless definition and difference

02.How does serverless computing work?

03.TOP-3 serverless providers

04.Serverless VS containers

05.Benefits of the serverless architecture

06.Limitations of serverless computing to take into consideration

07.Best practices to use serverless architecture

08.Bookshelf

Discover our full guide into serverless technology. In this article we will consider main terms, operational principles, TOP vendors, advantages and disadvantages, best practices and cases to use serverless technologies.

+ BONUS - a selection of the best books to dive deeper into Serverless. After reading our guide you will have a full understanding of this cutting edge technology.

Function as a Service and Serverless definition and difference

You have probably also met a term of FaaS (Function as a Service), which sometimes is used interchangeably with "serverless", and they are actually the same.

So, Serverless is a cloud-computing code execution model, where a certain cloud provider takes over the responsibility for servers running along with computing resources management. In simple words, there are no physical or virtual servers to manage, because they are automatically deployed in the cloud by the third-party vendors.

Meanwhile, Function as a Service is literally a platform providing serverless architecture deployment, orchestration and management - AWS Lambda, Google Functions, Azure Functions etc.

The main difference between the traditional and serverless architecture can be schematically drawn:

alpacked

How does serverless computing work?

Does serverless mean no servers?
Any program on the computer runs on the hardware, as well as serverless applications are run on the servers, but this part is not exposed to the developers and is self-managed by the vendors.
Components of the serverless application:

Serverless functions
Usually, serverless functions are single-purpose functions that imply your business and application logic. In simple words, it is just a code of your application which execute certain actions. Ideally, One function = one option execution, but sometimes developers use one function for several options.

Serverless backends
a term also known as a backend as a service. This unit allows dev teams shifting backend regular functions (data storage, authentication, messaging, etc.) to the cloud. Just integrate all needed backend services and options that are already provisioned by the cloud provider and set up its execution.

Deployment of the serverless applications seems easy. A developer creates a code - i.e. module/function, that executes a certain action. This function is provided to the cloud provider in a compressed or executable format. If any update is required, the only thing the developer has to do is to upload a new version and initiate the update. Along with this, the developer integrates pre-ready backend services with his serverless architecture. For example, data storage, notifications, analytics tools etc.

alpacked

Even though serverless is one of the most growing approaches on building software architectures, it comes with some drawbacks:

Higher latency compared to other architectures because of cold starts
Debugging and observing is more difficult
Deeper dependency on the FaaS vendor

Thus, a simple and basic serverless application would look like the figure below:

alpacked

TOP-3 serverless providers

alpacked

Serverless VS containers

Containers as well as serverless computing allow building modern and flexible applications. They both are usually cloud-based, and both reduce the burden of infrastructure management and maintenance. But the main common thread is the architecture design principle - applications are broken and deployed as small units.

But what's the difference between serverless functions and containers? There is a list of 6 differences:

User's functions

Containers: a user creates a container definition file that specifies OS, software, configurations. The container is initiated from that image, created by the user.

Functions: the process is hidden from the user. The user creates a program code , specifies needed dependencies and uploads it. The provider then provisions the computing environment.

Uptime

Containers: as soon as the container got started working, it would keep running until something goes wrong / it finishes required job or is simply destroyed.

Functions: the serverless function is destroyed each time when it stops running after a timeout.

Payment for the resources

Containers: a running container always needs a server to be available, even if no background job is being executed in application.

Functions: the function is consuming the computing resources only when it is called and running.

Timeout

Containers: no restrictions.

Functions: Limited in time. e.g. Lambda Function timeout limit can be set to max 15 min (900 sec).

Hosting specificity

Containers: can host almost any type of complex apps and microservices.

Functions: better suited for microservices.

Programming languages support

Containers: a user can choose the language for an app running in a container.

Functions: there is a limitation in the choice of the programming languages and their versions.

Benefits of the serverless architecture

1. Automatic scaling
Cloud and FaaS providers have horizontal autoscaling, thus, sudden and unexpected spikes in traffic will be handled effortlessly.

2. 100% availability
Following from the advantage bellow, serverless technology allows building sustainable architecture with high fault resistance. Most of the unexpected infrastructure problems are handled automatically within a few seconds.

3. Strong testability of the app logic and performance
You can run preliminary tests of a newly designed / updated architecture and see how changes would affect your current operation.

4. Reduced cost of running a server and TCO (total cost of ownership)
As it was mentioned above, serverless architecture helps organizations reduce operational spends on the IT segment. Paying only for the code execution time (which is counted in milliseconds), and amount of memory allocated average total benefit is estimated in at least 30% decrease in a monthly bill.

5. Quick deployment
It becomes easier to introduce new features faster and decrease time-to-market cycle. An updated code is just uploaded and the changes are initiated through calling API - no need anymore to deploy an entire server.

6. Focus on the core product, not on its maintenance
The modularity of the architectures allows developers and Ops engineers forget about the server management and concentrate their force on product enhancement.

7. BaaS - special services for easy integration
FaaS providers allow special services, known as backends, performing different tasks. Thus, an application made up of independent modules allows integration with backend services. For example, you can use AWS Cognito for client requests authorization and along with it pay only per active users within a month, not subsequent sessions or inactive accounts.

Limitations of serverless computing to take into consideration

Truly speaking, almost all possible disadvantages are related to the quality of the source code. If the source code is initially not optimal, almost all advantages are seriously undermined, especially the cost may occur even higher.

1. Functions timeouts
Some specific long-running operations like database backups or data scraping may fail due to this timeout.

Timeouts can be caused by several main reasons:
- big amount of data that needs to be processed
- application requires connection to 3rd party apis/endpoints, that can be unavailable or reply with long interval.

2. Minimal timelag
For some projects like online streaming platforms even sub-millisecond latency may be catastrophic. This happens because a vendor's system provisions a container for the program to start running a serverless function. But for most of businesses this time lag is obscure.

3. Migration to the serverless architecture is costly and time-consuming
Some legacy architectures would need a full reorganization and new code, new functions may need to be managed and orchestrated. Besides, testing and debugging is the running in the live mode, so you pay additionally for this.

4. Vendor lock-in
Choosing a vendor, take into consideration the fact, that interoperation between different third-parties may occur a serious headache. Moreover, changing a FaaS provider needs a forced changes in the code, which results in point 3 - it is costly and time-consuming.

5. Privacy
Serverless architectures are allocated on the public cloud environments. Thus, some privacy implications have to be considered before making a decision on using FaaS.