Developing and deploying an application often involves cumbersome development processes, heavy application servers, and slow test cycles. The ideal scenario is that backend developers only have to worry about implementing the domain-oriented building blocks and can concentrate on programming applications without having to worry about servers at the same time.
With Serverless, also called Serverless Computing, Serverless Architecture and Serverless Infrastructure, this ideal becomes reality. Serverless enables developers to create and run cloud applications and services without being responsible for servers and their management. True to the motto: “Run code, not Server”.
Since the release of Amazon AWS Lambda 2014, serverless has established itself and other cloud providers are now also providing serverless services. After IaaS, PaaS, BaaS and SaaS, FaaS (Function as a Service) is another significant step in cloud history.
Serverless is an execution model in which the cloud provider operates the server, is responsible for code execution and dynamically manages the allocation of resources. The costs are based on the actual resource consumption of the execution, so customers do not pay for unused resources, but for the actual computing and storage resources used.
Serverless computing allows developers to run applications or services in the cloud without worrying about provisioning, scalability, capacity planning and security patching, or server maintenance.
Serverless vendors include, among others:
Microsoft with Azure Functions
Amazon Web Services with AWS Lambda
Google with the Cloud Functions or IBM Cloud Functions (OpenWhisk)
Basically, web apps are developed in such a way that the developer controls the http requests made to the server. The app runs on this server, so developers are responsible for provisioning, maintaining, and managing the resources. This involves a lot of effort and distracts from the actual work: building apps.
Costs are incurred even if the server does not fulfill any requests
Developers are responsible for the availability and maintenance of the server
Servers must have the latest security updates
Servers must be scaled or downscaled In larger organizations, these tasks are handled by an infrastructure team, not by individual developers. Nevertheless, these processes slow down development times. The solution to this problem is Serverless.
With serverless computing, applications must be designed in the form of functions, which is the biggest change for developers. Individual applications that were previously deployed as rails or express monolith apps must be integrated into Serverless as a microservice based architecture.
Functions are typically executed in stateless containers that are triggered by events such as http requests, queue services, and file uploads, when an event needs to be responded to. This results in a delay, also called cold start. The duration of the delay depends on the runtime used, the size of the function and the cloud provider. However, there are numerous tricks to keep a function that is executed regularly “warm”.
Since the code is executed as individual functions, it is also referred to as Function as a Service (FaaS). FaaS-provided products are short-lived runtime environments that are dynamically assigned and scaled by the provider.
A special feature of serverless infrastructures is that the developer not only loads a code into the cloud, but also defines, defines and uploads functions to react to certain events. The functions are executed when predefined events occur. This is referred to as “event-driven computing”.
In serverless computing, the server layer is completely abstracted, but of course there is still a server physically present, but the developer never comes into contact with it. One example is Platform as a Service (PaaS): the developer does not need to interact with the platform’s API and does not care how servers are set up, deployed and scaled. Instead, the service provider ensures that sufficient resources are always available for the application.
Unlimited resources such as computing power and memory, which are only provided when they are needed
Customers pay only for the resources consumed to run the functions
simplified operations: developers can focus on their core competencies
automatic scaling and fault tolerance
rapid provisioning of resources
automatic capacity management
flexible resource management
concentration on the core of the source code
Not suitable for all use cases, because it is sometimes more efficient and cheaper to set up a server yourself
Restrictions on Monitoring and Debugging
Possible loss of control and platform dependency
Worse performance due to delayed reactions due to start duration of the runtime environment
Not necessarily more secure, but just as vulnerable as traditional processes
Users can’t protect cloud workloads with traditional security products
Danger of vendor lock-in as soon as you commit to manufacturer-specific interfaces
Examples for serverless applications
Automatic video editing: Automatically convert to different formats when uploading a video file.
Automatic image processing: When uploading an image file, different image formats/sizes are created automatically.
Monitoring und Debugging: Notification or functions in response to specific triggers, such as changes to data or system status.