This article is based on reporting originally published by Wired.com.
The Gap Between Cloud Computing’s Promise and Reality
The appeal of cloud computing has always been straightforward: instead of filling a warehouse with physical servers and hiring people to manage them, a company pays a cloud provider for computing resources on demand and is billed only for what it actually consumes.
That promise attracted organizations of every size — from early-stage startups to large enterprises and government agencies — to platforms offered by Amazon, Google, Microsoft, and others. But conventional cloud Infrastructure-as-a-Service (IaaS) offerings don’t fully deliver on the pay-for-what-you-use ideal.
Services like Amazon EC2 still require customers to select — and pay for — a specific allocation of compute resources: CPU, memory, and network capacity. Those allocations can be scaled up or down, but a sudden, unanticipated traffic spike can still leave an application under-resourced and unresponsive. As a result, many cloud customers routinely over-provision, paying for headroom they rarely need.
Beyond cost, virtual servers still demand significant operational effort. Donald F. Ferguson, co-founder and CTO of video-streaming company Seeka TV and a professor of computer science at Columbia University, notes that customers must install security patches, test them for regressions, and perform ongoing maintenance. Ferguson, whose career included software architecture roles at Dell and Microsoft and who helped create IBM’s WebSphere application server, estimates that his teams spent roughly 20 percent of their time managing cloud environments on traditional IaaS.
What Serverless Computing Actually Means
Serverless computing addresses these problems with a deceptively simple idea: developers upload the code they want to run (or the data they want to store), and the cloud provider handles all server provisioning, scaling, patching, and management invisibly. Billing is based on actual resource consumption — compute time, memory used, requests served — rather than a pre-allocated instance size.
The name is paradoxical because servers still exist; they’re just completely abstracted away from the developer. From the developer’s perspective, the server is practically invisible.
Ferguson reports that approximately 99 percent of Seeka TV’s code runs on serverless platforms, reducing the time spent on cloud environment management to near zero.
A Brief History: From Managed Storage to Function as a Service
Serverless computing has existed in some form for years. The first generation of serverless services were designed to handle specific, well-defined tasks and helped developers outsource pieces of functionality they didn’t want to maintain servers for:
- Amazon S3 — object storage where you upload data without worrying about the underlying server fleet, paying only for storage used.
- Twilio — a messaging infrastructure service that lets developers send SMS without configuring their own servers.
- Auth0 — a managed service for identity tasks like password verification and authentication flows.
These early serverless services were popular, but developers still needed traditional servers for custom application logic. That changed with the emergence of Function as a Service (FaaS) platforms. Hook.io and, most notably, AWS Lambda — launched in 2014 — allowed developers to upload small, discrete chunks of custom code and pay only for the compute resources consumed during execution. FaaS made it feasible to build entire applications on serverless infrastructure, not just offload isolated tasks.
Real-World Adoption
Serverless adoption is no longer confined to startups. Motorola Solutions uses serverless computing for work with law enforcement and public safety customers. Andrew Sinclair, an executive at Motorola Solutions, notes that serverless functions allow the company to focus more engineering time on building new features and less on provisioning and managing servers.
Cloud management company Cloudability reported a nearly seven-fold increase in serverless usage among its customers in the last quarter of 2017 compared with the previous quarter, according to a report released by the company. Craig Lowery, research director at Gartner, observed at the time that awareness of serverless had become nearly universal, with organizations broadly evaluating where it fits in their architectures.
The Real Challenges of Going Serverless
Serverless computing introduces trade-offs that teams must understand before committing to the model.
1. Architectural Constraints
FaaS platforms require developers to write software differently than they would for a traditional server or even a standard cloud instance. Applications must be decomposed into small, stateless, independently executable functions. Platforms including AWS Lambda impose limits on code package size, which means large, monolithic applications must be refactored into modular pieces before they can benefit from serverless deployment. This makes serverless a better fit for greenfield projects than for migrating existing applications.
2. Cold Start Latency
A traditional server-based application runs continuously, ready to respond to any incoming request. FaaS platforms like Lambda stop executing code that hasn’t been invoked recently, then reload it into memory when a new request arrives. This initialization delay — commonly called a cold start — can slow response times noticeably. Additional latency accumulates as serverless functions communicate with one another over the network. Motorola Solutions, for instance, avoids serverless for applications that require fast responses after long idle periods for this reason.
3. Observability and Security
Monitoring and securing serverless workloads requires different tooling than traditional infrastructure. Motorola Solutions uses Twistlock to monitor the security of its serverless code — an example of the emerging ecosystem of tools being built specifically to address serverless operational challenges.
Serverless Is the Future — But Not for Everything
Robin Vasan, founder of Mango Capital and an investor in both serverless companies (including Netlify) and tools for managing conventional cloud services, summarizes the current landscape well: “I think serverless is the future, but it’s not the future for everything. Not every function should live in a serverless framework.”
Ferguson agrees that serverless isn’t universally appropriate, but notes that the performance concerns cited by others are rarely an issue for Seeka TV in practice. Because the platform’s functions are invoked frequently enough, AWS Lambda rarely cold-starts them, eliminating that latency in their specific workload.
Conventional cloud IaaS will retain a significant market for latency-sensitive, continuously running, or computationally intensive workloads. Serverless and traditional cloud computing are complementary tools, not mutually exclusive ones.
Key Takeaways for DevOps Teams
- Serverless reduces operational overhead dramatically — patching, provisioning, and scaling are all handled by the provider.
- FaaS enables true pay-per-use billing — you’re charged for actual invocations and execution time, not reserved capacity.
- Cold starts are a real concern — evaluate your latency requirements carefully before moving latency-sensitive workloads to FaaS.
- Greenfield applications benefit most — refactoring large monoliths for serverless is costly; design modularity in from the start.
- Security tooling must evolve — traditional agent-based security tools don’t translate directly to ephemeral serverless environments; purpose-built solutions are needed.
- Hybrid approaches are common — most organizations blend serverless and traditional cloud services based on workload characteristics.