Serverless functions are a single-purpose, programmatic feature of serverless computing and they offer many benefits to teams and organizations that use them well.
In this article, we’ll look at how serverless functions work, how they can be used and how they can help your organization. We’ll also show you how to get started with serverless functions and how to get the most out of them.
Introduction to "serverless" computing, architecture & frameworks
First up, some context and background.
Also known simply as “serverless”, serverless computing is a cloud computing model where the cloud provider provisions computing resources on demand for its customers, managing all architectures, including cloud infrastructure. Despite its name, serverless computing still relies on cloud and physical servers to execute code. What's the difference? "Serverless" just means that your developers and operators aren't dealing with the servers, operating systems and other infrastructure — those servers are elsewhere, they're not just "gone".
Serverless architecture, or serverless frameworks, refer to a model where an organization’s software applications are hosted by a third-party cloud service provider. Serverless architecture features event-driven architecture, which eliminates the need for developers to manage hardware and software infrastructure and avoids vendor lock-in.
In the past, hosting an app on the internet required an organization to manage its own physical or virtual server, as well as its operating system, networking and other infrastructure components required for the application to run. The emergence of cloud services like AWS and Microsoft Azure removed the need for physical hardware, but these solutions still require the customer to manage the virtual servers’ operating systems and web server software processes.
With a serverless architecture, the provider manages the hardware, the virtual machine (VM) operating system and the web-server software. That leaves developers free to focus on their application code.
Serverless architecture encompasses Function-as-a-Service (FaaS), which allows you to construct your application from individual, independent functions. The FaaS provider hosts each function, which can be automatically scaled to meet traffic demands.
And this is where serverless functions enter the picture.
How serverless functions work
A serverless function is essentially a piece of business logic that is both stateless (does not maintain data) and ephemeral (is used and destroyed). A serverless function potentially lasts only for seconds and is designed to be triggered by a specific condition. These actions could all activate a serverless function:
- Placing an e-commerce order.
- Uploading a text file.
- Signing up for a newsletter.
There’s really no limit to what can be built as a serverless function so long as it can be triggered by an API call. To understand, it helps to look at how applications are structured.
Brief: Web application structures
Application architecture generally consists of two parts: the front end and the backend:
- The front end is the part of the app users interact with, such as a web interface.
- The backend includes everything users don’t see, including the server hosting the application's files and the database, among other things.
When a shopper goes to a retailer’s website, for example, they’re seeing the front end of that website, which includes text, images and form fields such as a search bar. When they search for a product, it triggers a request to the website’s backend, where code is executed to check a database to see if that product exists, how many are available, and how much it costs. The backend sends that data back to the front end, which displays the results in a user-friendly format for the shopper.
Serverless functions in app backends
An app’s backend can be composed of many functions. Serverless computing allows developers to create this backend functionality as single-purpose modules of code that are executed independently. Functions are written in Java, Python, PowerShell, Ruby and other common programming languages. Serverless platforms continue to support additional languages, too.
The only strict rule for functions is that they cannot depend on any outside software or code to operate. This self-containment allows them to be activated, start running and then shut down quickly.
To use serverless functions, all a developer has to do is write the function code and deploy it to a managed environment. A typical serverless function process would look like this:
- Writing a function. The developer writes a function that fulfills a specific purpose in the application code, such as a form mailer.
- Defining an event. The developer defines an event that will trigger the cloud-native service provider to execute the function. An HTTP request is a common example.
- Triggering an event. A user triggers the event with the click of a button or some similar action.
- Deploying and executing a function. The cloud service provider starts a new instance of the function if one isn’t already running.
- Passing the result to the client. The result of the executed function within the application is displayed to the user.
Standard serverless function process
In addition to executing the function, the cloud service provider also manages resource allocations. If, for example, the service gets 200 concurrent requests, the cloud platform makes 200 or more instances available. If the demand drops to 50 simultaneous requests, the platform scales down accordingly. In this way, the customer pays only for the actual resources its functions use.
Use cases for serverless functions: when & how to use them
Serverless frameworks are extremely flexible and can be used to address a range of application issues. Some common use cases include:
- Web applications: Serverless functions are ideal for building websites and web apps, allowing developers to focus on the core product without having to set up or maintain infrastructure.
- Image processing: Serverless functions can be coupled with machine learning to sort, categorize, resize and reformat images.
- Multi-language applications: Rather than being limited to a single programming language, the developer can connect serverless functions to execute tasks in multiple languages, allowing polyglot development teams to work with the languages they know best.
- Internet of Things (IoT): Serverless functions can be used to automatically filter, log and respond to IoT sensors, device data and other tactical endpoints.
- Data manipulation tasks: Serverless functions can be used to perform extract, transform and load tasks at a fraction of the cost of dedicated ETL software. They can also move data from one application to another as well as streamline processing.
- Scheduled task automation: Serverless functions can automate any task or workflow that has to be performed at a specific time or interval, and in some cases replace what used to be cron jobs.
This is far from a complete list of what serverless functions can do, but it illustrates the range of use cases. Serverless is also very extensible, so functions can be designed for virtually any use case that emerges.
Serverless functions can be used to automatically filter, log and respond to IoT sensors
Benefits of serverless functions
The use of serverless functions offers several significant benefits! It frees developers to focus on application development and better-quality application code. That's because infrastructure concerns, such as redundant code deployments and autoscaling, are handled by the serverless provider. The organization also saves money by only paying for the computing resources it uses instead of overprovisioning physical hardware or renting cloud instances that go unused.
Here's many more benefits to consider...
No infrastructure to manage. With the bulk of hardware and software concerns offloaded to the serverless provider, developers have more time to write code, resulting in better applications.
Polyglot environment. Developing an app normally requires settling on a single programming language, one that some developers may not know or understand. Serverless functions let developers code in any language or framework with which they're comfortable.
Simpler backend code. Serverless removes a lot of coding complexity for developers, allowing them to create simple, self-contained functions that independently perform one purpose.
Lower costs. Serverless platforms charge customers per request, meaning they're cost-effective because customers only pay for the resources that are used when the function is executed. There is no charge for idle CPU time or unused space, resulting in overall greater cost savings.
Easier scaling. Because serverless autoscales the functions up or down based on demand, there’s little effort required to manage capacity. And thanks to usage-based pricing, customers don’t have to worry about over- or under-provisioning costs, or being stuck with associated costs due to vendor lock-in.
Less code. Serverless allows developers to dedicate themselves to writing code but also reduces the amount of code that they oversee.
No web app framework to learn. With serverless functions, developers don’t have to spend time managing servers, learning a new architecture, remembering naming conventions, or configuring request pipelines — they can simply run code.
Faster time to market. Serverless architecture simplifies the deployment process, allowing developers to add and modify code piecemeal. This translates to faster rollouts of bug fixes and new features for applications.
Troubleshooting serverless functions
Troubleshooting serverless functions require a third-party serverless monitoring solution. While each serverless platform offers its own monitoring solution, such as CloudWatch for AWS Lambda, they typically don’t gather the metrics required to troubleshoot a function when it starts having problems.
A serverless monitoring solution or observability tooling can collect important function-level metrics around...
- How fast or slow your functions are performing
- How often they’re accessed
- How well they’re responding
- Tracing a function to isolate services that are causing latency or otherwise compromising application performance
How monitoring serverless functions works
All applications produce metrics that developers have to monitor to ensure optimum performance. That’s true of serverless functions, too!
A problem with an individual function can compromise the entire app, leading to slow performance or downtime, making it critical to monitor for errors and failures in your serverless functions. Those challenges are compounded by the fact that an instance of a function could vanish by the time you need to troubleshoot it, making full-fidelity essential.
But monitoring serverless applications presents different issues than monitoring traditional apps. Serverless functions transfer much of the control from the application owner to the serverless provider, creating additional obstacles when troubleshooting issues. Tracking and identifying errors are also difficult because servers are only spun up when a function is executed. This ephemeral characteristic also makes it difficult to track resource usage.
Traditional monitoring tools weren’t designed for the intricacies of serverless applications. Fortunately, there are serverless monitoring solutions available that are tailored to capturing key metrics in stateless environments.
Monitoring requirements will vary according to business needs and the platform being used. Metrics to monitor in AWS Lambda and Microsoft Azure, for example, would include the following:
Whenever a function is invoked in Lambda, AWS spins up a container to run your function. But if the function hasn’t been invoked in a while, there may not be an idle container available to run your code. This adds latency — from a few hundred milliseconds to several seconds — and makes the application performance appear slow.
Thus, tracking these “cold starts” is important to gain better visibility into your functions and identify ways you can improve performance.
Invocations and invocation errors
Serverless monitoring tools should let you track two important values:
- The number of successful and failed invocations (the number of times a function is executed in response to an event or API call).
- The number of invocations that failed due to errors associated with the function.
Functions only run from the moment they’re triggered by an event until they fulfill their purpose, which creates challenges when trying to predict and understand resource usage. Tracking when your function code starts executing in response to an invocation until it stops can help you stay on top of your provider costs.
Your custom metrics
It’s also important to measure any metrics that reveal how well your functions are supporting your business and customer experience, including the total number of user requests, revenue per location and other relevant information.
Serverless function best practices
You’ll get the most out of your serverless architecture if you follow a few best practices, including:
- Stick to small tasks. If your function has multiple dependencies, it will take longer to instantiate, increasing latency. Sticking to small tasks and short execution times will increase app performance and keep your usage costs down as functions scale.
- Design with auto-scaling in mind. Selecting tasks with few interdependencies will allow them to more easily execute in parallel, translating to better performance and lower costs.
- Use third-party services. Serverless functions communicate via API calls, which makes them a great fit with third-party services. Rather than building every bit of functionality themselves, developers can connect functions with third-party services to outsource common tasks, reducing the amount of custom code they have to write while accelerating time to market.
- Secure your functions. Serverless follows the shared responsibility model for securing apps. And while that significantly reduces the number of attack vectors, developers are still responsible for the security of the applications themselves, including authentication, encryption and other measures.
How do you get started implementing serverless functions in your environment?
To get started implementing serverless functions in your environment, the first step is to sign up for an account with a serverless platform provider. AWS Lambda, Google Cloud Functions and Microsoft Azure Serverless Computing/Azure Functions Serverless Compute are the most popular, but there are many others. Choosing the right one for your business depends on many factors, starting with the type of software you’re building and your goals. You’ll have different options if you’re starting out with legacy applications than if you’re already deeply embedded in the cloud.
From there you’ll need to consider technical issues, such as language support and deployment, dependencies management, persistent storage resources, and types of triggers, to name just a few. These will be handled differently from platform to platform and are worth familiarizing yourself with to inform your decision.
Once you sign up with a platform, implementing your first function should be easy as long as you know what you want to build. All the big vendors offer tutorials to get you acquainted with serverless environments and the specifics of their respective platforms.
If you’re not ready to wed yourself to a vendor straight away, there are ways to run serverless code on your local hardware. AWS Serverless Application Model (AWS SAM), for example, has a feature that lets you test Lambda code offline.
Serverless functions can save you time and money
Serverless functions remove the burden of infrastructure management so developers can focus solely on what they do best — building great apps. It benefits businesses as well, reducing complexity, lowering costs and increasing agility. Implementing serverless functions also brings new challenges, but the right platform combined with a good serverless monitoring tool will let you take advantage of everything this transformative technology has to offer.
What is Splunk?
This posting does not necessarily represent Splunk's position, strategies or opinion.