This article is based on reporting originally published on Datamation.com (2017). Quotes from industry practitioners are preserved as originally reported.
What “Serverless” Actually Means
Despite its name, serverless computing does not eliminate servers. Servers are still very much involved — you just stop managing them. The term refers to a model in which a cloud provider dynamically allocates compute resources to run discrete units of code called functions, and you are billed only for the time those functions are actually executing.
Understanding how we arrived here requires a quick look at the progression of cloud infrastructure models.
The Road from On-Premises to Serverless
The first major shift was moving workloads out of on-premises data centers and into Platform-as-a-Service (PaaS) environments like Amazon Web Services (AWS) and Microsoft Azure. The promise was compelling: developers could provision a virtual machine with a defined set of CPU cores, memory, and storage in minutes rather than waiting weeks to order and rack physical hardware.
That shift accelerated development cycles and reduced pressure on IT operations teams. However, developers still had to configure virtual machines correctly — a task that requires infrastructure knowledge many application developers do not have, and one that frequently results in over-provisioning.
Serverless computing, sometimes categorized under the label function Platform-as-a-Service (fPaaS), is the next step. Instead of allocating virtual machines and deploying application code to them, a development team uploads discrete functions and the cloud provider handles deployment, scaling, and availability automatically.
Core Benefits of the Serverless Model
Jim Sherhart, product marketing manager for AWS at Amazon, summarized four fundamental benefits of going serverless:
- No server provisioning or management. Developers bring their code; the platform handles the rest.
- Automatic scaling. Services like AWS Lambda scale by executing code in response to each individual trigger event, with no manual intervention required.
- Built-in high availability. Availability is managed by the platform, not the development team.
- Pay-per-use billing. You are charged only when your code is actually running. Idle time costs nothing.
Torsten Volk, managing research director at Enterprise Management Associates, framed the developer experience clearly: “Coders don’t have to worry about scalability and high availability, you only pay for the time your code runs, instead of reserving EC2 resources for an ongoing time period, and setup is almost instant. Create code and give it a try.”
Eliminating Over-Provisioning
Peter Horadan, CTO and executive vice president of engineering at tax software firm Avalara, highlighted a particularly significant economic benefit: the elimination of resource over-provisioning.
“People overprovision for machinery on AWS. In serverless, that’s 100% gone. You don’t preallocate any resources to run your function. You upload it and say when this event happens, run my function. If it happens once a day, it runs it once a day and that’s all you pay for,” he said.
Horadan reported that fully eliminating resource pre-allocation produced cost savings ranging from ten-fold to 100-fold in Avalara’s experience. He also pointed to the cognitive savings: developers no longer need to reason about capacity planning or design their own auto-scaling logic.
Serverless as a Natural Evolution of PaaS
Yochay Kiriaty, principal program manager for Azure Functions at Microsoft, positioned serverless as a logical continuation of the PaaS model: “Serverless offers a fully managed platform that frees developers from the need to worry about servers and allows developers to focus on the application and not the machines running it. Serverless enables developers to build applications quicker and easier as well as takes care of a lot of the operational and management work.”
Downsides and Current Limitations
Serverless computing is not a universal solution. Several genuine constraints affect where and how it can be applied effectively.
Suited to Small, Discrete Tasks
Horadan was direct about scope: “For today, it’s for simple tasks only. It really works well with small tasks. A large program with lots of functions linked together is more difficult to use, but those are problems people are figuring out with tooling.”
The model works well for event-driven workloads — processing an image upload, responding to a webhook, transforming a data record — but composing many functions into a complex application requires careful orchestration that, at the time of writing, was still maturing.
Tooling and Debugging Gaps
Volk identified three specific limitations: a different coding paradigm that requires adjustment, limited runtime support on some platforms, and immature debugging tooling. Linking independently deployed functions together — managing versions, wiring calls, and tracing execution — remains more difficult than in a traditional monolithic or even microservices application where a compiler or orchestration framework handles those relationships.
Security Considerations
Security also deserves evaluation when adopting serverless architectures. Each function represents a potential attack surface, and the reduced visibility into underlying infrastructure can make threat modeling more complex. Organizations need to apply the principle of least privilege to function permissions and audit event triggers carefully.
Analyst Perspective: Still Nascent
Craig Lowery, research director at Gartner, characterized fPaaS at the time as “still nascent and lacking in complete tooling and best practices for streamlined, repeatable and successful software development activities.” He noted, however, that the value of the model had been clearly demonstrated and that it maps naturally to microservice software architecture.
Platform Support and Language Coverage
Both AWS and Microsoft have emphasized broad language support to lower the barrier to adoption. Kiriaty noted that Azure Functions was designed to support a wide range of developer languages, including F#, PowerShell, PHP, Python, Bash, CMD, and BAT scripts, with the intent that serverless should be accessible to any developer rather than a specialist subset.
Sherhart echoed that breadth of applicability from the AWS side: “Serverless architectures are suitable for a range of applications. There is no single use case or industry where customers would not see the benefits it offers.”
The Path Forward: Better Tooling
The consensus among practitioners at the time of this reporting was that tooling improvements represent the most important near-term opportunity for serverless computing. Horadan described the problem concisely: “Today you can only upload small pieces of functionality. If one calls another you have to wire them together. In a traditional program, the compiler would do it. And there’s also the issue of which versions of the function are being called. So it’s really tooling, and it’s a solvable problem. I expect to see a lot of these problems get solved over time.”
Gartner’s analysis suggested that organizations making the most effective use of public cloud IaaS would ultimately combine virtual machines, containers, and fPaaS rather than treating any single model as a complete replacement for the others.
Key Takeaways
- Serverless computing abstracts server management away from developers, not the servers themselves.
- The billing model — pay only for execution time — can eliminate the cost of idle or over-provisioned resources.
- Current implementations are best suited to discrete, event-driven functions rather than complex, stateful applications.
- Debugging, orchestration, and security tooling were still maturing at the time of this reporting; assess the current state of your chosen platform before adopting serverless for critical workloads.
- Serverless, containers, and virtual machines are complementary rather than mutually exclusive; most organizations will use a mix.