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)?
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
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.
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.
Read more about Twistlock Serverless Security here.
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
Beyond App Security: Securing Applications No Matter Where They LiveRead the Blog
Surveying the Container Orchestration LandscapeRead the Blog
Building the Right Toolbox for a Successful DevSecOps CareerRead the Blog
BOD 19-02: DHS Vulnerability Remediation RequirementsRead the Blog
How Cloud Native Security is Adapting to New Hybrid Reality for EnterprisesRead the Blog