What is serverless?

Serverless is a cloud-native development model that allows developers to build and run applications without having to manage servers.

There are still servers in serverless, but they are abstracted away from app development. A cloud provider handles the routine work of provisioning, maintaining, and scaling the server infrastructure. Developers can simply package their code in containers for deployment.

Once deployed, serverless apps respond to demand and automatically scale up and down as needed. Serverless offerings from public cloud providers are usually metered on-demand through an event-driven execution model. As a result, when a serverless function is sitting idle, it doesn’t cost anything.

Serverless differs from other cloud computing models in that the cloud provider is responsible for managing both the cloud infrastructure and the scaling of apps. Serverless apps are deployed in containers that automatically launch on demand when called.

Under a standard Infrastructure-as-a-Service (IaaS) cloud computing model, users prepurchase units of capacity, meaning you pay a public cloud provider for always-on server components to run your apps. It’s the user’s responsibility to scale up server capacity during times of high demand and to scale down when that capacity is no longer needed. The cloud infrastructure necessary to run an app is active even when the app isn’t being used.

With serverless architecture, by contrast, apps are launched only as needed. When an event triggers app code to run, the public cloud provider dynamically allocates resources for that code. The user stops paying when the code finishes executing. In addition to the cost and efficiency benefits, serverless frees developers from routine and menial tasks associated with app scaling and server provisioning.

With serverless, routine tasks such as managing the operating system and file system, security patches, load balancing, capacity management, scaling, logging, and monitoring are all offloaded to a cloud services provider.

It’s possible to build an entirely serverless app, or an app composed of partially serverless and partially traditional microservices components.

Under a serverless model, a cloud provider runs physical servers and dynamically allocates their resources on behalf of users who can deploy code straight into production.

Serverless computing offerings typically fall into two groups, Backend-as-a-Service (BaaS) and Function-as-a-Service (FaaS).  

BaaS gives developers access to a variety of third-party services and apps. For instance, a cloud-provider may offer authentication services, extra encryption, cloud-accessible databases, and high-fidelity usage data. With BaaS, serverless functions are usually called through application programming interfaces (APIs).

More commonly, when developers refer to serverless, they’re talking about a FaaS model. Under FaaS, developers still write custom server-side logic, but it’s run in containers fully managed by a cloud services provider. 

The major public cloud providers all have one or more FaaS offerings. They include Amazon Web Services with AWS Lambda, Microsoft Azure with Azure Functions, Google Cloud with multiple offerings, and IBM Cloud with IBM Cloud Functions, among others. 

Some organizations choose to operate their own FaaS environments using open source serverless platforms, including Red Hat® OpenShift® Serverless, which is built on the Knative project for Kubernetes.

Function-as-a-Service (FaaS) is an event-driven computing execution model where developers write logic that is deployed in containers fully managed by a platform, then executed on demand.

In contrast to BaaS, FaaS affords a greater degree of control to the developers, who create custom apps rather than relying on a library of prewritten services. 

Code is deployed into containers that are managed by a cloud provider. Specifically, these containers are:

• Stateless, making data integration simpler.
• Ephemeral, allowing them to be run for a very short time.
• Event-triggered, so they can run automatically when needed.
• Fully managed by a cloud provider, so that you only pay for what is needed, not always-on apps and servers.

Using FaaS, developers can call serverless apps through APIs which the FaaS provider handles through an API gateway.

Serverless architecture is ideal for asynchronous, stateless apps that can be started instantaneously. Likewise, serverless is a good fit for use cases that see infrequent, unpredictable surges in demand.

Think of a task like batch processing of incoming image files, which might run infrequently but also must be ready when a large batch of images arrives all at once. Or a task like watching for incoming changes to a database and then applying a series of functions, such as checking the changes against quality standards, or automatically translating them.

Serverless apps are also a good fit for use cases that involve incoming data streams, chat bots, scheduled tasks, or business logic.

Some other common serverless use cases are back-end APIs and web apps, business process automation, severless websites, and integration across multiple systems.

As a way to run containerized apps on automated infrastructure, it’s no surprise that the Kubernetes container orchestration platform is a popular choice for running serverless environments. But Kubernetes by itself doesn’t come ready to natively run serverless apps.

Knative is an open source community project which adds components for deploying, running, and managing serverless apps on Kubernetes.

The Knative serverless environment lets you deploy code to a Kubernetes platform, like Red Hat OpenShift. With Knative, you create a service by packaging your code as a container image and handing it to the system. Your code only runs when it needs to, with Knative starting and stopping instances automatically.

Knative consists of 3 primary components:

• Build - A flexible approach to building source code into containers.
• Serving - Enables rapid deployment and automatic scaling of containers through a request-driven model for serving workloads based on demand.
• Eventing - An infrastructure for consuming and producing events to stimulate apps. Apps can be triggered by a variety of sources, such as events from your own apps, cloud services from multiple providers, Software-as-a-Service (SaaS) systems, and streams for Apache Kafka. 

Unlike earlier serverless frameworks, Knative was designed to deploy any modern app workload—everything from monolithic apps to microservices and tiny functions.

As an alternative to a FaaS solution controlled by a single service provider, Knative can run in any cloud platform that runs Kubernetes. This can include running in an on-premise data center. This gives organizations more agility and flexibility in running their serverless workloads.

Pros

• Serverless computing can increase developer productivity and reduce operational costs. By offloading the routine tasks of provisioning and managing servers, developers have more time to focus on their apps. 
• Serverless helps enable DevOps adoption by reducing the need for developers to explicitly describe the infrastructure they need operations to provision for them.  
• It’s possible to streamline app development even further by incorporating entire components from third-party BaaS offerings.
• Operational costs are reduced in a serverless model because you can pay for cloud-based compute time as it’s needed, as opposed to running and managing your own servers all the time.

Cons

• Not running your own server or controlling your own server-side logic can have drawbacks.
• Cloud providers may have strict constraints on how their components can be interacted with, in turn affecting how flexible and customized your own systems can be. In the case of BaaS environments, developers may be beholden to services whose code is outside their control.
• Ceding control of these aspects of your IT stack also opens you up to vendor lock-in. Deciding to change providers will also likely come with the cost of upgrading your systems to adhere to the new vendor’s specifications.

The concepts of serverless architecture and FaaS have grown hand-in-hand with the popularity of containers and on-demand cloud offerings. A 451 Research report, done in cooperation with Red Hat, traced the evolution of serverless into 3 phases.

The "1.0" phase of serverless came with limitations that made it less than ideal for general computing. Serverless 1.0 is characterized by:

• HTTP and few other sources
• Functions only
• Limited execution time (5-10 minutes)
• No orchestration
• Limited local development experience

The advent of Kubernetes ushered in the "Serverless 1.5" era where many serverless frameworks started to auto-scale containers. Serverless 1.5 is characterized by:

• Knative
• Kubernetes-based auto-scaling
• Microservices and functions
• Easy to debug and test locally
• Polyglot and portable

Today, the "Serverless 2.0" era is emerging with the addition of integration and state. Providers have started adding the missing parts to make serverless suitable for general-purpose business workloads. Serverless 2.0 is characterized by:

• Basic state handling
• Use of enterprise integration patterns
• Advanced messaging capabilities
• Blended with the enterprise PaaS
• Enterprise-ready event sources
• State and integration