How to Decide When to Use Serverless
Serverless computing is the new way to build apps in the cloud. The question isn’t whether you should leverage serverless computing, but when you should start.
Well, OK — Serverless computing isn’t the right fit for every app. But in many cases, it can improve performance, as well as cost efficiency.
This article explains what serverless computing is and which factors to consider when deciding whether serverless can help you to deploy your app.
What Is Serverless (and Why Should I Care)?
Serverless architecture is rapidly gaining traction in the industry, with all major cloud providers offering a solution, along with on-premises options for private cloud installations. Serverless computing is a way to deploy single functions which are activated only when a specific trigger is called. Serverless apps can also handle both asynchronous or synchronous interactions. The serverless platform you are using will dictate the input/output options and language you can write the app in. JavaScript seems to be the only universal language across all platforms.
There are plenty of articles on the business value and other benefits of serverless. This article focuses on when serverless makes technical sense.
Is Serverless a Viable Option for This App?
A few questions to consider when deciding if serverless is the best methodology for the piece of functionality you are about to build and deploy are:
- Is the app a small, usable building block, or can it be broken into small blocks?
- Do all the building blocks have well-defined inputs and outputs?
- Can I use existing development and build tools?
- Does the serverless platform support:
- Receiving connections from my client?
- Interacting with the target datastore?
- A language I know?
Serverless Building Blocks
An important dimension of serverless computing to keep in mind is that it revolves around discrete chunks of code (or functions, if you prefer that term). These are the building blocks of a serverless architecture.
As part of defining your function, you explicitly set one and only one input trigger, and a limited number of targets where you can write your output. The way you test your code is by uploading a text block (usually JSON), which is used as an input and it simply tests if it can accept the input and execute successfully. Basic logs are visible and can be exported to in-cloud log aggregation solutions like CloudWatch.
Given the fact that there is a single input mechanism per function, the code is highly streamlined as compared to traditional apps, which need to handle multiple types of input variations. The most complicated type of function is one that responds to a web or API request, and even it requires a separate function for each method if you want a different dataset input, or to leverage a different datastore.
Serverless Languages and Development Tools
If you have a specific language you want or need to write your code in, then the serverless platforms you can use might be limited. Unless you are running a multi-cloud environment, this may mean you can’t even use the serverless options on the cloud you are deployed on. The closest thing to a universal language across all serverless platforms is JavaScript. One example of a limitation would be if you code in .NET—then, Azure is your only real option. Or if you want to write your code in Swift, then IBM Cloud Functions (aka OpenWhisk) is your target platform.
Serverless can almost always be built using the same tools and CI/CD pipelines that you already have in place. If you are currently supporting container development, then your CI/CD tools are ready.
Serverless Platform Integration Points
Integration points are broken down into two categories: incoming (often called triggers), and outgoing (which can be called targets).
Triggers on a cloud platform are always specific to the platform, and often asynchronous, like an S3 bucket being written to, or a Cosmos DB getting updated or an SNS topic receiving a message. While the main piece of code in the function could be cross-platform and generic, if you are using a specific cloud, why bloat the code when you don’t have to? Processing data points sent in randomly by IoT devices and storing them in a database is the perfect example of where serverless is the absolutely best option.
The one synchronous type of call is from either an API manager or a web frontend. In this case, they actively wait for a response from the function. If response time really matters, then serverless is not the fastest way to build these apps. It’s not that serverless is slow. It’s just slower than other options (except in the most high-volume situations) because it has to be completely initialized and executed every time.
Serverless platforms always have a “custom” option for a target or trigger. Before going down that route, what you need to consider is that the more you code in a custom framework, the more you have to support in a proprietary framework. At a certain point, using a microservice in a container will make more sense than trying to force what you are working on to be serverless.
Summary
Dogmatism with any single application development framework can be as bad as having no standards and using every application development framework available. Serverless architecture has its place, and where it fits, it works wonderfully. Through years of working with development teams of many sizes, I’ve found that the most sustainable approach is to have a couple go-to development and deployment models which can be leveraged. Different models exist for a reason. To use an analogy, The Honda Civic is a great car but won’t do much good to a family with more than two kids. Serverless, or Function-as-a-Service, is here to stay. As its popularity and usage grows, use it where it makes the most sense.
