Debunking 7 Serverless Myths

Share this post:

Debunking the top seven serverless myths around IBM Cloud Functions

As a compute option, serverless cloud functions are growing in popularity across the development community. Serverless functions provide many benefits, including development efficiency and cost savings. Industry leaders want to execute code on demand in a scalable serverless environment via functions.

Unfortunately, there are plenty of myths associated with serverless functions that prevent many teams from adopting this technology. After hearing about a number of perceived challenges, I want to take the opportunity to address and debunk the top seven serverless myths around IBM Cloud Functions—IBM’s functions-as-a-service technology:

1. Cloud Functions are not suitable for latency-sensitive workloads
2. Cloud Functions are only for sporadic loads; otherwise, they’re more expensive than virtual machines
3. There is no SLA available for Cloud Functions
4. Cloud Functions only support a limited number of programming languages
5. Cloud Functions code size is limited to 48MB
6. To use Cloud Functions, application code must be restructured into very granular components, which could add significant complexity
7. Managing Cloud Functions is difficult because the logs are hard to analyze

Myth 1: Cloud Functions are not suitable for latency-sensitive, end-user facing workloads

Fact: Serverless functions perform at the same level as applications running on IBM Cloud Foundry (based on a response time that 95% of users experience (p95) for a sample function running on IBM Cloud Functions). With this in mind, IBM Cloud Functions is well-suited for end-user facing applications, and it’s important to be wary of this common misconception.

Myth 2: Cloud Functions are only for sporadic loads; otherwise, serverless functions are more expensive than virtual machines

Fact: Cloud Functions is the most price-competitive technology for a very large segment of workloads, including heavy workloads. Depending on your workload characteristics, there are situations where running on plain VMs doesn’t become attractive before billions of calls a day. People only compare the raw infrastructure costs vs. HA footprint and operational costs.

Myth 3: There is no SLA available for Cloud Functions

Fact: Availability for Cloud Functions is 99.95%, as documented in IBM Cloud Service Description, Section 3.2.1 Platform Services.

Based on that, when deploying IBM Cloud Functions across two regions, the resulting availability would be 99.999975%, or 1-(1-0.9995)2. For three regions, the resulting availability would be 99.9999999875%, or 1-(1-0.9995)3. In both cases, we assume that a global load balancer offering 100% availability is used (the IBM Cloud Internet Service is an example).

All of this comes at no incremental cost (excluding the GLB), which is not the case with any other runtime model. Avoiding incremental costs is possible since Cloud Functions is only charged for requests served vs. pre-allocated capacity.

In comparison, AWS Lambda serverless functions do not have a publicly available SLA, as of this writing.

Myth 4: Cloud Functions only support a limited number of programming languages

Fact: IBM Cloud Functions support any language. There is a distinction between natively supported languages and the ability to package any kind of functions code in a Docker container. This distinction is often the root cause of this myth.

The Docker container-based approach supports Go programs, any custom executables packaged as Docker containers, Rust, C, and anything else you can put into a Docker container. For details, see IBM Cloud Functions: Creating and invoking actions on IBM Cloud Docs.

Natively supported languages include Node.js, Java, Python, serverside Swift, and PHP. Native support enables developers to upload their code and provides specific performance optimizations not possible with Docker containers as the generic “catch-all” mechanism.

Myth 5: Cloud Functions code size is limited to 48MB

Fact: It is true that the actual function code uploaded by the developer has a 48MB limit. It is important to note, however, that you can package code of arbitrary sizes into Docker images and use as a basis for executing IBM Cloud Functions. This is often used when the action code itself is small, but there are large dependencies. Based on this approach, there is no limit to the code size for an action. For technical details on how to run large serverless functions, I recommend a blog by James Thomas, IBM Cloud Developer Advocate: “Large Applications on OpenWhisk.”

In comparison, AWS Lambda limits serverless function code size to 50MB (compressed), as of this writing.

Myth 6: To use Cloud Functions, application code must be restructured into very granular components, which could add significant complexity

Fact: IBM Cloud Functions doesn’t force applications into extreme levels of granularity. You need to determine whether to put all code into one action, create hundreds of actions, or a apply a mixture of the two.

The IBM Cloud Functions service provides constructs (e.g., actions, rules, triggers) that simplify the creation of fine-granular application architectures, sometimes called “nanoservices.”

Myth 7: Managing Cloud Functions is difficult because the logs are hard to analyze

Fact: The IBM Cloud Functions service integrates with IBM Cloud Log Analysis service. The Log Analysis service auto-captures Cloud Functions logs and metadata, such as execution duration, error codes, etc.

The IBM Log Analysis service enables flexible searches, graph creation, and other operations tasks.

Don’t let common myths delay adoptions

As you can see, there are many serverless myths that create misconceptions that may delay or block a team’s successful adoption of the technology. I hope this blog post demystifies serverless functions so that you can hit the ground running. Take a look at our IBM Cloud Functions page to learn more.

Additional resources

• SiteSpirit case study on IBM.com
• Large Applications on OpenWhisk by James Thomas, Notes on Software blog, August 2017
• Does Going Serverless Save You Money? by Nicole Henderson, ITPro Today, June 2017
• IBM Cloud Functions, Creating and invoking actions on IBM Cloud Docs

IBM notices

Prices are current as of August 2018 and subject to change without notice.

Results may vary depending on operating environment.

Customer experiences described herein are based upon information and opinions provided by the customer. The same results may not be obtained by every user.

The performance data contained herein was obtained in a controlled, isolated environment. Actual results that may be obtained in other operating environments may vary significantly. While IBM has reviewed each item for accuracy in a specific situation, there is no guarantee that the same or similar results will be obtained elsewhere.

The responsibility for use of this information or the implementation of any of these techniques is a customer responsibility and depends on the customer’s or user’s ability to evaluate and integrate them into their operating environment. Customers or users attempting to adapt these techniques to their own environments do so at their own risk. In no event shall IBM be liable for any damage arising from the use of this information, including but not limited to, loss of data, business interruption, loss of profit, or loss of opportunity.