kentoh - Fotolia

Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Don't overestimate the benefits of serverless computing

It's natural to be curious about new technologies, but the hype around serverless computing far outweighs its practical advantages.

This article can also be found in the Premium Editorial Download: Modern Stack: Will the Kubernetes sidecar deliver container happiness?

Interest in serverless computing is sky high, but developers and IT pros should recalibrate their expectations.

It's common for new technologies to follow a similar path when it comes to awareness and excitement. Gartner calls this phenomenon a hype cycle and even charts technology trends as they move from the "peak of inflated expectations" through the "trough of disillusionment" and ultimately onto the "plateau of productivity." Gartner's 2017 Hype Cycle for Emerging Technologies put serverless PaaS on an upward trend, still not quite at peak hype. Judging by the buzz at recent conferences, it's hard to imagine any technology as overhyped as serverless computing is right now.

Serverless-related sessions at May's Red Hat Summit in San Francisco were packed. Rich Sharples, senior director of product management at Red Hat, fielded questions about the benefits of serverless, including as a strategy to modernize mainframe applications. Several of these questions exemplified inflated expectations, but also a misunderstanding of the benefits of serverless computing.

For starters, we'd be better off if we ditched the serverless name. The term originates from the idea that customers don't have to provision, manage or even worry about the underlying infrastructure on which their code runs. But, of course, there's a server there somewhere. The trouble with the term is not just that the language is technically inaccurate; it also obfuscates some of the real challenges to using the service.

Serverless providers still require customers to select the amount of RAM to allocate to their function. Of course, RAM alone can't execute a function, so providers also serve up a matching CPU complement and network bandwidth. Yet, without visibility into the number of CPU cores or the clock speed, it's impossible to determine whether the service is executing your code efficiently. Many developers are willing to accept this tradeoff and free themselves of provisioning's complexity, but there's a cost to this convenience. There are benefits to serverless, but the services are expensive -- at least when you evaluate what you actually get for the money.

Providers make serverless platforms appealing in part by offering vast free tiers. These freebies and a price tag that starts with the tiniest fraction of a penny lead to the misconception that serverless is cheap. Prospective customers often cite price as a primary draw to serverless, yet those who've tested it at scale come to realize that it's more expensive than they anticipated. Compared to a physical server or even a modest cloud instance, serverless can't compete on price.

Another misconception that's led to inflated expectations is that serverless will solve your vendor lock-in problems. One of the perceived benefits of serverless is that it's inherently agnostic. After all, the code you execute isn't tied to a particular server or platform -- though it's worth mentioning that different serverless providers support different languages. The problem lies in what that code does. Much of the appeal of serverless platforms lies in the integration with other available cloud provider services. For example, pairing serverless with Amazon Kinesis enables developers to build robust, scalable apps that process and respond to events in real time. But if a function relies on other proprietary cloud services, it cannot be easily migrated to another serverless provider.

Most important of all, serverless has limited uses. What percentage of your organization's software portfolio comprises stateless, event-driven applications? Of those, how many have wildly unpredictable demand swings that make it impractical to host on a pay-per-hour cloud instance? Serverless is not for traditional applications. Unlike IaaS, serverless can't replace your infrastructure for existing applications -- and it certainly won't replace your server or mainframe.

Most, but not all, of the serverless hype is misplaced. Serverless will certainly have a place in tomorrow's IT stack, but it will remain a relatively small component. You're not going to move all of your company's applications to a serverless architecture -- though many businesses will use a serverless framework to help scale a service with unpredictable demand.

Resist the hype, and don't expect to squeeze your existing applications into a serverless model. Instead, serverless should be one tool in a larger toolbox of cloud services that developers can use to build and support microservices-based cloud applications.

This was last published in June 2018

Dig Deeper on AWS Lambda

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

I have not read all of this article but the paragraph that starts with "Most important of all, serverless has limited uses." seems as if the author does not understand the technology. We just wrote 154 lines of code in lambda that can process the entire Internet (100's of petabytes) in 7 minutes yielding a cost of approximately $150. As a 30+ year veteran "writing code" using Computer Science I have not seen a problem yet that cannot be solved extremely well using Function as a Service technology.
Thanks for the comment. Perhaps that sentence didn't provide the context I was aiming for. There's no doubt that you can write code to do anything, and that any code can run as FaaS (assuming the provider supports the language). The limited use I was referring to is twofold: You obviously can't always shoehorn existing apps into a FaaS model. But, more importantly the cost of today's FaaS offerings make it of limited use because in many cases it's cheaper to run that code within a VM (cloud or on-prem). Just because you CAN use FaaS for everything doesn't mean it's smart or cost effective. For more on the cost angle, check out some of the calculations in my sidebar on this article:

I'd love to talk more, if you're interested. Feel free to reach out:
It's also worth mentioning that your 7-minute function would timeout on AWS Lambda, because the service's current execution duration is capped at 5 minutes.