Serverless architecture FAQ: Serverless computing simply explained

Serverless computing is a method of delivering backend services based on actual usage. A serverless provider gives developers the ability to write and deploy code without worrying about the underlying infrastructure. Physical servers are used, but do not have to be managed by the developers. Serverless code is only executed when necessary and the serverless architecture automatically adapts to demand.

A serverless architecture divides the application backend into functions. Each individual function performs a different task within the application. This type of architecture is also known as Function-as-a-Service (FaaS).

One of the most important features of a serverless architecture is the automatic scalability. Serverless applications automatically adapt to the number of users or usage requirements. If a function has to be executed on several instances, these are started, executed and ended by the servers of the serverless provider as required. If a function is not used, it will not be executed.

• Serverless vs. Platform-as-a-Service (PaaS): At PaaS, a cloud provider provides tools, servers and resources for application development over the Internet. Serverless computing is much more scalable than PaaS in terms of cost and computing power. Serverless applications adapt immediately, automatically and as required, without the need for further manual configurations by the developer or provider. In contrast, developers have to plan the scaling in advance for applications with PaaS.

• Serverless vs. Backend-as-a-Service (BaaS): In addition to cloud storage or cloud hosting, BaaS providers offer software that has already been written for activities on servers, e.g. B. for user authentication or database management. BaaS providers offer backend services, but the backend cannot be scaled as needed. A serverless backend is divided into smaller functions that start and stop in response to events.

• Serverless vs. Containers: Containerized microservices are always executed while serverless functions are triggered by events. There is a fixed price for the execution of containers and they cannot be scaled automatically. In contrast, developers with a serverless backend only pay for the computing power that their functions actually use.

• 1. Integration in the data center
     In order to be fully effective, it must be possible to embed containers in the company’s existing IT infrastructure with their services – be it security, authentication or network services, for example.
  2. VM management instead of chaos
     IT managers have to find a way to clearly manage their virtual machines (VM) and still provide customers with the services they need in parallel.
  3. Scalability
     Today’s highly dynamic corporate IT makes it necessary for companies to be able to programmatically scale their container technology and the capacities for provision to the users.
  4. Orchestration
     Companies have to combine multiple containers, combine containers with other applications and enable communication between containers and other IT resources. To achieve all of this, the containers must also be developed in an environment that reflects this mix of technologies and computing capacities.
  5. Note legacy systems
     Containers not only have to harmonize with the latest applications and systems in the company, but also take into account the old systems.

A serverless architecture offers improved scalability, more flexibility and faster release creation.

With serverless computing, developers don’t have to worry about buying, deploying, and managing back-end servers. Developers can write code and deploy it almost instantly. You can update applications piece by piece, i.e. functionally, instead of having to redeploy the entire application package with every update. In addition, as with older backend models, companies no longer have to pay for unused server storage space if deployed servers are not running at maximum capacity.

With serverless computing, the back-end costs are sometimes less predictable because they rise and fall with usage. Serverless architectures are not designed for long-running applications. And since serverless providers take into account the time code is executed, it can be more expensive to run an application with long-running processes in a serverless infrastructure. In addition, debugging is more complicated because developers don’t have full visibility into the backend processes and the applications are divided into separate, smaller functions.

Nowadays we see two important areas where serverless computing is used. In the first, serverless functions are used as a way to transmit events or data between different services. For example, parsing webhooks from third-party providers (e.g. payment processing platforms), changing uploaded images or editing elements in a queue service.

The second area is building an API with a single purpose or a smaller service. Organizations can quickly launch these self-contained APIs or services without worrying about scaling or long-term usage costs. Recently, companies have been using serverless computing to build bigger and bigger applications by pooling many of these smaller use cases.

You might also be interested in the subject of serverless computing:

An excursion into the world of serverless architectures

How serverless concepts automate IT

Applications with a serverless architecture are dependent to a certain extent on the provider ensuring security. Serverless providers have gone to great lengths to ensure adequate sandboxing of application code similar to that in a traditional cloud environment. However, it is extremely important to ensure that applications are deployed with appropriate processes and permissions to ensure the maximum level of security. (hal)