2022 Gartner® Magic Quadrant™ SIEM
Get the reportMore
Serverless computing is a cloud-based application architecture where the application’s infrastructure and support services layer is completely abstracted from the software layer.
Any computer program needs hardware to run on, so serverless applications are not really “serverless” - they do run on servers - it’s just that the servers are not exposed as physical or virtual machines to the developer running the code. In a truly serverless paradigm, program code runs on infrastructure hosted and managed by a third party - typically a cloud service - which not only takes care of provisioning, scaling, load balancing and securing the infrastructure, but also installs and manages operating systems, patches, code libraries and all necessary support services. As far as the user is concerned, a serverless back-end would scale and load-balance automatically as the application load increases or decreases, all the while keeping the application online. The user would only need to pay for the resources consumed by a running application.
Theoretically at least, this has the promise of drastically reduced development cycles and low operational costs. And that’s why serverless is a hot buzzword in today’s IT world.
Serverless applications can be made up of two types of components:
Of these, serverless functions are hosted and managed by a type of service known as “Function as a Service” or FaaS. FaaS is the primary platform for running serverless program code. With FaaS, developers write independent code scripts known as “functions” and upload those functions to the FaaS. The code can be then triggered by some event or run on a schedule. Popular examples of FaaS are Amazon Lambda, Azure Functions or Google Cloud Functions.
Serverless backends on the other hand, refers to managed services which serverless functions can make use of. These services are typically used for storage, database, messaging, notifications, orchestration or security. Like FaaS, users don’t need to provision and manage any infrastructure when using a serverless backend.
Another feature of serverless backends is that they are not coupled with FaaS only. This means non-serverless applications can also make use of serverless backends.
An example of serverless backend is Simple Queue Service (SQS) which provides a managed message queuing service from Amazon. Similarly, Amazon Aurora Serverless is a serverless database service. This is distinctly different from Amazon RDS or Aurora which - although being a managed service - requires users to provision and manage database instances.
The following table lists some serverless services from three major cloud vendors.
Amazon Web Service
Simple Storage Service (S3), Elastic File Systems (EFS) for object storage
DynamoDB, DocumentDB, Aurora Serverless for data store
Simple Notification Service (SNS) for notifications
Simple Queue Service (SQS), for asynchronous messaging
Kinesis for streaming data
Azure storage for object storage
Azure CosmosDB, for data store
Azure Active Directory for user authentication
Azure Event Grid for event routing, Service Bus for messaging
Azure Kubernetes Service for orchestrating serverless containers
Google Cloud Platform
Google Cloud Functions
Cloud Storage for object storage
Cloud FireStore for NoSQL database
BigQuery for data warehouse
Cloud Pub/Sub for messaging
Cloud Dataflow for streaming or batch data
In this article, we will primarily focus on serverless functions.
Businesses realize a number of benefits when they start using the serverless model. These benefits are also its well-known features:
Here are some applications of serverless architecture:
Some of the most common use cases of serverless also include: performing authentication, serving static web content, running ETL jobs and database queries, processing IoT and streaming data as well as real time file processing.
The image below shows a simplified application architecture that makes use of some serverless functions and services:
Here, a user is accessing a web application from a mobile device. The user’s HTTP request is routed by a DNS server. The static content of the site is served up by a content delivery network (CDN) that interfaces with an object storage medium. The dynamic content is served by a web server which sends its requests to an API gateway. The gateway routes application requests to different serverless functions. One function is used for authentication, another one takes care of reading from and writing to a backend database while a third one saves session states in a key-value NoSQL database.
Serverless functions are “stateless”, which means they cannot save and share session states between two different runs of the same function or different functions. There is no way for serverless functions to save data or files in the underlying disk subsystem. Similarly, a serverless function will often call other serverless functions as part of an application stack. Finally, a function may need to communicate with other functions using asynchronous messaging.
Developers can make use of serverless backend services to overcome these challenges. For example:
The serverless model may not be the answer in certain cases.
Another hot topic in today’s computing world is containers.
A container is a stand-alone, scaled-down unit of computing environment that can run executable code. It’s a lightweight version of a virtual machine that has everything installed for running programs: an operating system, runtime libraries, system tools, mapping to persistent storage and an “entry point”.
Containers also run on servers, but the program running inside the container is not aware of the underlying hardware. Behind the scene, serverless functions also run on containers. Serverless goes one step further by abstracting this compute layer from the user.
The table below shows general differences between containers and serverless functions
User is responsible for writing a container definition file that installs operating system, software and necessary run times, map storage and configure networking.
The user then creates an image from the file, uploads the image to a registry and instantiates the container from that image.
The entire process is abstracted from the user. A user only needs to write program code supported by the serverless platform and upload it. The service provider takes care of provisioning the computing environment.
Once started, a container will keep running unless explicitly shut down or destroyed.
The underlying computing environment of a serverless function is destroyed when it completes running.
Even when no program is executing, a running container will need a server to be available. This results in operational expense.
Serverless functions are charged only for the computing resources they consume when running.
Code running in a container is not restricted by any timeout.
Serverless functions are usually constrained by timeouts.
Containers can run in a cluster of machines.
Any underlying hardware is transparent to users.
A container can save data to its ephemeral storage or a mapped storage volume.
There is no option for saving data to ephemeral storage from a serverless function. Data is usually saved in object storage medium.
Containers can host complex applications or simple microservices.
Serverless functions are best suited for microservices.
User can choose language or runtime for an application running in a container.
Choice of language for serverless functions is limited to what the service provider supports.
There are two aspects of serverless application monitoring: monitoring application logs and measuring performance.
Any well-designed application should generate run-time logs. Log messages are invaluable for troubleshooting application failures or slow performance. Most languages used for writing serverless apps have dedicated logging frameworks. Using these frameworks, developers can embed log messages in their code which are emitted during run time.
Since serverless functions cannot save any data in local storage, the log messages are routed to a different location - typically, another managed service. For example:
Log messages from these sources can be sent to third-party log management solutions.
FaaS providers also expose metrics which can help monitor a serverless function’s performance. The table below shows some typical metrics
What it means
Number of times a function was run in the last sample period, categorized by its status (ok, timeout or error).
Number of times a function failed in last sample period due to internal errors like timeouts, out-of-memory, insufficient privileges or unhandled exceptions.
Ideally, this value should be zero. A consistent non-zero trend requires troubleshooting.
Number of times a function was stopped from running in the last sample period because the rate at which it was being called exceeded its allowed limit of concurrent runs.
Duration or Execution times
The time in milliseconds or nanoseconds a function was running.
Maximum amount of memory used by the function during execution
Note how there are no disk or CPU related metrics here. This is expected because the underlying storage or computing resources are abstracted.
Sumo Logic is a cloud-native, Software-as-a-Service (SaaS) platform for machine data analytics. It’s used for storing, analyzing and creating insights from machine-generated data and logs. It’s also a powerful SIEM (Security Information and Event Management) tool.
Users can easily subscribe to Sumo Logic and start sending logs and performance data from their on-premise or cloud-hosted assets. The ingested data can be then meaningfully interpreted with Sumo Logic “apps”.
Apps are pre-configured searches and dashboards for different types of data sources. Sumo Logic comes with a number of out-of-the-box apps. These apps help quickly turn raw data into critical insights.
For serverless, the following Sumo Logic apps are available:
Build, run, and secure modern applications and cloud infrastructures.Start free trial