Cox Communications has launched Cox Edge, a full stack edge-cloud computing service to deliver ultra-low latency compute solutions, helping customers to improve application performance and to reduce cloud transport and on-premise infrastructure costs.

The shape of the internet is evolving. Increasingly immersive digital experiences require faster application performance and response times to delight consumers. Technologies like Internet of Things (IoT) and artificial intelligence drive the need for real-time processing and decision making. These and other innovations can benefit from bringing compute power closer to the action – to where users are engaging and to where sensor data is being created.

Cox Edge, with last mile edge locations and a global network, brings compute resources closer to users and businesses. This can help reduce cloud transport costs, improve application resiliency and continuity, reduce latency to deliver near real-time application performance, and provider better overall security.

Cox Edge is a full stack edge-cloud infrastructure service deployed from last-mile edge data centers, with offerings that will include Virtual Compute, Storage, Bare Metal, Edge CDN, Distributed Database services, Serverless computing, Distributed Containers, and Enterprise Kubernetes. The services are offered through an integrated user experience, so that developers can easily augment their cloud or on-premise deployments with edge capabilities.

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.

Why Serverless Is More Than Just Hype

Customer engagement platform Braze sends more than 1.5 billion messages a day and interacts with more than 1 billion consumers a month. That scale brings an acute infrastructure challenge: demand for computing resources fluctuates dramatically depending on the volume of data Braze must transform to support personalised messaging campaigns.

“At one point we may have 100 servers running, and at another we may have 1,000,” said Sal Poliandro III, director of DevOps and security at Braze. The company used to scale its cloud infrastructure based on a set of metrics that amounted to an educated best guess. Then it migrated core scaling logic to AWS Lambda, Amazon’s serverless computing platform.

The result: scaling is now fully automated. An algorithm determines required capacity and immediately triggers infrastructure scaling through Lambda functions. “We used to scale based on peak loads,” Poliandro said. “With serverless, we don’t have to worry about that.” He estimates that for a typical development team, the process is at least ten times faster than provisioning servers manually.

Braze is one of many organisations discovering that serverless computing — and its subcategory, Function-as-a-Service (FaaS) — can eliminate infrastructure drudgery while delivering meaningful cost savings and near-infinite elasticity.

What Serverless Actually Means

Despite the name, serverless computing still runs on servers. The distinction is that developers do not provision, configure, patch or manage those servers. Instead, discrete units of code — called functions — execute automatically in response to an event, whether triggered by a user action, a scheduled timer, an API call or a message queue.

Key characteristics of the serverless model:

• Event-driven execution: Functions run only when triggered. No event, no cost.
• Stateless by design: Each function invocation starts with a clean context. No session history is carried between invocations unless explicitly passed in or retrieved from external storage.
• Pay-per-invocation billing: Customers pay only for the compute time consumed during execution, not for idle server capacity.
• Automatic horizontal scaling: The provider scales function instances up or down — including to zero — without operator intervention.
• Millisecond cold-start latency (at scale): Spinning up a function takes milliseconds rather than the hours or days that manual virtual machine provisioning can require.

In contrast, conventional application deployment requires pre-allocating CPU, memory and storage, plus a suite of platform software. Those resources remain provisioned — and billed — even during idle periods. Overprovisioning drives up costs, wastes capacity and contributes to server sprawl: cloud instances that are forgotten but still incurring charges.

Real-World Use Cases

Serverless is a natural fit for workloads that are:

• Spiky or unpredictable: News sites that see traffic surge during breaking events, or sports platforms that spike when a team enters the playoffs, benefit from paying only for the traffic they actually receive.
• Event-driven data pipelines: A user uploading an Excel file can trigger a Lambda function to convert it to JSON and write it to a data lake — without any standing server.
• Mobile back-ends: A smartphone app requesting a weather forecast or directions passes a location parameter and receives a single targeted result. The function executes and terminates immediately.
• Image and media processing: When a user updates a profile photo, a serverless function can automatically resize it and replicate it to CDN origins.
• High-performance computing: Fannie Mae (Federal National Mortgage Association) migrated Monte Carlo risk-analysis simulations from on-premises servers to AWS Lambda. In one simulation covering approximately 20 million mortgages, the serverless approach completed the job more than four times faster than the previous setup — what AWS described as a “supercomputer in the cloud.”

A Decade in the Making: The Provider Landscape

Serverless concepts are not new. Google’s App Engine introduced elements of metered billing as far back as 2008. The model gained significant momentum when Amazon launched AWS Lambda in 2014. The major cloud providers now all offer FaaS platforms:

• AWS Lambda — Amazon Web Services
• Google Cloud Functions — Google Cloud
• Azure Functions — Microsoft Azure
• IBM Cloud Functions (based on Apache OpenWhisk) — IBM Cloud

Beyond the hyperscalers, a broad ecosystem of open-source frameworks and commercial tools has emerged, including options for on-premises serverless deployment. Enterprises increasingly concerned about vendor lock-in are evaluating these alternatives.

Adoption figures reported around 2017–2018 reflect how quickly the space was growing. An analysis of 1,500 organisations by Cloudability found that use of serverless platforms grew more than sevenfold in Q4 2017, albeit from a small base. RightScale reported that serverless was the fastest-growing extended cloud service in 2017 among nearly 1,000 IT professionals surveyed, with adoption growing from 12 to 21 percent.

Enterprise adoption has also moved faster than many expected. Tim Wagner, general manager of AWS Lambda, noted at the time that large enterprises including Capital One, Hearst Corp. and the Financial Industry Regulatory Authority (FINRA) were among the fastest-growing Lambda users.

The Two Core Characteristics: Stateless and Event-Driven

Understanding serverless’s strengths and limitations requires understanding two defining properties.

Statelessness

A serverless function has no persistent memory of previous invocations. It receives its inputs, executes, returns a result and terminates. “It’s like a blank slate each time, but it’s highly efficient because you’re not managing a lot of thick application logic,” said James Kobielus, an analyst at Wikibon.

This is powerful for discrete queries — a weather lookup, a file format conversion, a database write — but problematic for workflows that require context across multiple steps, such as a multi-step e-commerce checkout or a billing system that must reconcile prior state.

Event-Driven Execution

Functions run in response to defined events: an HTTP request, a file upload, a database record change, a message on a queue, a scheduled cron trigger. This means zero resource consumption when no events are occurring.

“You can set it up so if one event comes in, then one function runs. If a million come in, you fire off a million,” said Craig Lowery, a research director at Gartner. Horizontal scaling is automatic, elastic and managed entirely by the provider.

Where Serverless Falls Short

Serverless is not a universal compute model. Current limitations include:

• Stateful workflows: Applications that require complex, ordered transactions — shopping carts, billing systems, financial reconciliation — are poor fits for a purely stateless model without additional orchestration layers.
• Long-running processes: Most FaaS platforms impose maximum execution time limits per invocation, making them unsuitable for workloads that run for extended periods without architectural adaptation.
• Debugging and observability complexity: Distributed, ephemeral functions are harder to trace and debug than monolithic or container-based applications. Tooling is maturing but still catching up.
• Vendor lock-in: Functions written for Lambda may not be portable to Azure Functions or Google Cloud Functions without modification. Open-source frameworks such as OpenWhisk and the Serverless Framework attempt to mitigate this.
• Cold-start latency: Functions that have not been invoked recently may incur a startup delay before execution, which can affect latency-sensitive applications.

“Serverless architectures move complexity out of the application and into the connectivity,” said Lee Atchison, senior director of strategic architecture at New Relic. “It’s not a solution to everything. It creates its own problems as well as solves them.”

Rich Sharples, senior director of product management at Red Hat, predicted that few companies would go all-in on serverless: “Your general IT shop will have a mix.”

Bridging the Gap: Containers, Orchestration and Stateful Extensions

Platform vendors are actively working to extend serverless beyond its current boundaries.

Microsoft introduced Virtual Kubelets (announced December 2017) to enable containers to run either functions or full applications while retaining serverless billing granularity and automated infrastructure provisioning. Microsoft also offers Durable Functions, a programming model that adds stateful orchestration on top of Azure Functions by persisting state externally between invocations.

AWS introduced Fargate (announced late November 2017) to allow containers to run without managing servers or clusters, blending the operational simplicity of serverless with the flexibility of containers.

Kobielus of Wikibon has even suggested that blockchain’s immutable ledger could theoretically compensate for statelessness in database-intensive scenarios by providing a complete auditable narrative of function calls across a distributed fabric — though this remains speculative.

What Serverless Means for Developers

Serverless has an advantage that doesn’t show up in ROI spreadsheets: developers genuinely like it. Removing infrastructure provisioning from the development loop lets engineers focus on writing and shipping code.

“It enables our applications and operational engineers to think about their responsibilities in a way that’s more meaningful to them,” said Braze’s Poliandro. “They can deploy faster because they don’t have to worry about the infrastructure around it.”

However, adopting serverless requires a significant mental shift. Developers must:

• Design for statelessness and idempotency from the start.
• Embrace event-driven, asynchronous programming patterns.
• Understand how to chain functions and manage state externally (for example, using DynamoDB, Redis or a durable orchestrator).
• Rethink monitoring and observability strategies for ephemeral, distributed execution.

“To go to Lambda is a substantial code rewrite,” conceded Mark Ryland, director of AWS’ Office of the CISO. Gartner’s Lowery found through a study of five organisations moving up the serverless learning curve that all became advocates once they stopped applying traditional application-development norms. “Once they kicked those old expectations, they were able to realise the benefits,” he said.

A Practical Migration Strategy

Organisations do not need to rewrite existing applications from scratch to benefit from serverless. A phased approach reduces risk:

1. Identify discrete, event-driven functions within existing applications — image processing, file conversion, notification dispatch, data validation — that can be extracted and deployed as standalone functions.
2. Implement new features as serverless functions rather than adding to existing monoliths or microservices.
3. Split user interface components from business logic and data access layers, converting appropriate microservices into functions over time.
4. Experiment in low-risk environments before committing to serverless for mission-critical workloads.
5. Invest in observability tooling early: distributed tracing, structured logging and alerting are essential in a functions-based architecture.

Rohit Akiwatkar, a technology consultant at Simform, summarised the outcome: “Over time, the number of functions will grow, and the agility and velocity of your development team will increase.”

The Strategic Imperative for Engineering Leaders

AWS CEO Andy Jassy said in 2017 that if Amazon were being built today, it would be built on a serverless platform. Microsoft CEO Satya Nadella stated at Microsoft Build that “serverless computation is going to fundamentally change not only the economics of what is back-end computing, but it’s going to be the core of the future of distributed computing.”

For engineering leaders, the practical advice from analysts is straightforward:

• Serverless is not a passing trend — the major cloud providers have committed enormous engineering resources to it.
• Start building internal expertise now. The learning curve is real, and the talent market increasingly expects serverless skills.
• Adopt incrementally. Identify the highest-ROI, lowest-risk workloads and gain experience before attempting large-scale migrations.
• Do not attempt a direct “lift and shift” of existing applications. Serverless requires architectural rethinking, not just re-hosting.

“You have to have a plan to adopt this technology for the long term or you will not have access to the talent you need,” Gartner’s Lowery warned. “Developers will expect it.”

Between containers, microservices and serverless computing, the past decade has introduced more innovation in how applications are built and deployed than the preceding two decades combined. For teams still absorbing DevOps, cloud-native architecture and container orchestration, serverless may feel like yet another wave to survive. But the economics — pay only for what you use, scale to zero, deploy in milliseconds — make it a compelling model for an expanding share of modern workloads.

The Headline Finding: Containers Are Moving Faster Than DevOps

A survey of 601 IT decision-makers, conducted by ClearPath Strategies on behalf of the Cloud Foundry Foundation, revealed a notable shift in enterprise technology adoption priorities: container adoption is on pace to overtake DevOps adoption within two years.

At the time of the survey, 32 percent of respondents had already adopted both containers and DevOps processes. Looking forward 12 months, 25 percent planned to adopt or evaluate containers, compared to only 17 percent planning the same for DevOps. Projected out to a two-year horizon, 72 percent of respondents said they already use or expect to use containers, versus 66 percent who said the same about DevOps.

What remains less clear from the data is whether widespread container adoption will push organizations toward DevOps as a cultural and operational practice — or whether the two trends will continue to evolve independently.

Where Container Adoption Actually Stands

The survey breaks container adoption into three tiers:

• 18 percent have broadly adopted containers across their organization.
• 40 percent have deployed containers on a limited basis.
• 40 percent are still in the early stages of evaluation or pilot.

This distribution is a useful reminder that headline adoption figures often mask significant variation in deployment maturity. An organization running containers in a single team’s CI pipeline is counted alongside one running Kubernetes clusters in production at scale.

Platform Pluralism: PaaS, Containers, and Serverless Together

One of the more telling findings is that IT organizations are no longer picking a single application delivery model. Instead, many are running multiple paradigms in parallel:

• 64 percent report using both PaaS and containers.
• 43 percent report using both PaaS and serverless.
• 42 percent report using both containers and serverless.
• 39 percent report using all three: PaaS, containers, and serverless simultaneously.

For engineering teams, this platform pluralism has real operational implications. Infrastructure and platform teams must now support toolchains, security policies, networking models, and observability pipelines that span fundamentally different runtime environments. Standardizing on a common control plane — whether that is Kubernetes, a managed cloud platform, or a PaaS layer — becomes critical as the number of runtime models grows.

Serverless: Evaluations Outpace Production Use

Serverless computing shows a striking gap between interest and production deployment. Only 11 percent of respondents were actively using serverless frameworks at the time of the survey, yet 35 percent were evaluating at least one. This mirrors the early trajectory of containers themselves — broad curiosity, limited production footprint.

For DevOps practitioners, this signals that serverless will increasingly appear in team backlogs and architecture discussions even if production usage remains concentrated in early adopters. Understanding the operational tradeoffs of serverless — cold starts, vendor lock-in, observability gaps, per-invocation cost modeling — is becoming baseline knowledge rather than specialist knowledge.

Cloud-Native Is the Direction, Not Just the Destination

CFF CTO Chip Childers, commenting on the survey results, drew a distinction that matters for how engineering leaders frame their modernization strategies: the benefits of cloud technologies are only fully realized when applications are either purpose-built for or genuinely modernized for cloud platforms. A simple lift-and-shift — moving an existing application to a VM in the cloud without architectural changes — captures very little of the operational or economic value.

The survey data supports this framing. More than half of IT decision-makers (57 percent) reported that their organizations are both building new cloud-native applications and refactoring existing ones. Only 13 percent are relying on refactoring alone.

PaaS vs. CaaS: A Division That Is Already Blurring

One question the survey raises but does not definitively answer is how the market will divide between Platform-as-a-Service (PaaS) environments and Container-as-a-Service (CaaS) environments. At the time this data was published, PaaS platforms were already absorbing container orchestration technologies — Kubernetes in particular.

Childers noted that SUSE had already released a distribution allowing Cloud Foundry to run on top of Kubernetes, and that work was underway to allow organizations to replace the CFF’s own container orchestration engine with Kubernetes. This points toward a broader industry dynamic: Kubernetes is becoming the common substrate beneath multiple higher-level platform abstractions rather than a competing alternative to them.

For engineering teams evaluating their platform strategy, the practical implication is that a bet on Kubernetes as a foundational layer does not preclude using a PaaS abstraction on top of it — and may in fact enable one.

Key Takeaways for DevOps Teams

• Container adoption breadth does not equal container adoption depth. Plan your platform engineering and support capacity for the 40 percent in early stages, not just the 18 percent who have broadly deployed.
• Expect to support multiple runtime models simultaneously. Platform teams that assume a single delivery model will cause friction as serverless and PaaS usage expands alongside containers.
• DevOps practices and container adoption are correlated but not automatically linked. Organizations adopting containers without investing in corresponding cultural and process changes risk compounding operational complexity rather than reducing it.
• Kubernetes is becoming infrastructure, not a differentiator. Evaluate which higher-level abstractions your teams need on top of it, rather than treating Kubernetes itself as the end goal.
• Serverless is worth evaluating now. With 35 percent of organizations actively evaluating serverless frameworks, waiting until it is mainstream risks falling behind on tooling and operational patterns.

Survey conducted by ClearPath Strategies on behalf of the Cloud Foundry Foundation; sample size of 601 IT decision-makers. Original reporting via containerjournal.com, published 2018.

Serverless Is Maturing — and Creating New Opportunities

Serverless computing is not a new concept, but it has reached an inflection point. As more developers recognise the practical value of event-driven, infrastructure-free architectures, a new layer of the software industry is beginning to take shape around it — one that could generate significant startup activity in tooling, security, monitoring, and developer experience.

The term “serverless” is a slight misnomer: servers still exist, but the developer no longer has to provision, configure, patch, or scale them. The cloud provider allocates exactly the compute, memory, and storage needed to execute a function in response to a defined event trigger. The developer writes the logic; the platform handles everything else.

Building Layers of Abstraction: From Physical Servers to Serverless

To appreciate why serverless matters, it helps to trace the evolution of how developers have related to infrastructure over the past few decades:

• Physical servers: Dedicated hardware with significant unused capacity and high operational overhead.
• Virtual machines: A single physical host divided into multiple isolated VMs, pioneered at scale by companies such as VMware. This breakthrough enabled more efficient use of hardware and laid the groundwork for cloud computing.
• Containers: Popularised by Docker and orchestrated at scale by Kubernetes, containers allowed developers to decompose monolithic applications into discrete, portable services that run consistently across environments.
• Serverless / event-driven computing: The infrastructure abstraction is taken a step further. Developers define functions and the events that trigger them. The cloud provider handles provisioning, scaling, and teardown automatically.

All major cloud vendors now offer serverless platforms: AWS Lambda, Google Cloud Functions, and Microsoft Azure Functions each follow this event-driven model. The long-term potential goes beyond convenience — serverless could fundamentally shift how developers think about the relationship between code and infrastructure.

Removing Another Barrier to Entry for Developers

Tim Wagner, then General Manager for AWS Lambda, summarised the core value proposition clearly: serverless removes provisioning, deployment, patching, and monitoring from the developer’s plate. “All those details at the server and operating system level go away,” he explained. The programmer defines the function; the platform figures out the infrastructure required to execute it — sometimes from a single line of code.

Sarah Guo, a partner at Greylock Partners who invests in early-stage companies, frames serverless as the next logical step in the cloud’s value proposition: “If you look at one of the amazing things cloud computing platforms have done, it has just taken a lot of the expertise and cost that you need to build a scalable service and shifted it to [the cloud provider].” Serverless extends that shift further, allowing developers to concentrate entirely on user needs rather than operational concerns.

This reduction in complexity has a direct bearing on startup formation. Lower infrastructure overhead means smaller founding teams can build and operate production services, compressing both time-to-market and initial capital requirements.

What Developers Actually Think: Survey Data

DigitalOcean surveyed more than 4,800 IT professionals, of whom approximately 55 percent identified as developers. Key findings relevant to serverless adoption included:

• Nearly half of respondents said they did not fully understand the serverless concept.
• 81 percent reported plans to research serverless further within the year — a strong signal of interest even where understanding was incomplete.
• About two-thirds had not yet deployed a serverless application in the preceding twelve months, a figure consistent across geographic regions, with slightly higher adoption reported in India.
• Among those already using serverless, AWS Lambda led with 58 percent of respondents selecting it as their primary tool, followed by Google Cloud Functions at 23 percent and Microsoft Azure Functions at 10 percent.

Critically, the survey identified a specific pain point driving reluctance to adopt: a shortage of mature tooling, particularly around monitoring and debugging. “One of the biggest challenges developers report when it comes to serverless is monitoring and debugging,” the report noted. That gap is precisely where startup opportunity lives.

How Abstraction Creates New Startup Ecosystems

Every layer of abstraction in computing history has followed the same pattern: it simplifies one set of problems while introducing a new set. Serverless is no exception.

Ping Li, General Partner at Accel, articulated the investment thesis directly: “Anytime there’s a kind of shift from a developer application perspective, there’s an opportunity to create a new set of tools or products that help you enable those platforms.” He added that the timing depends on reaching a critical mass of developers adopting serverless methodologies before the tooling market can fully materialise.

S. Somasegar, Managing Director at Madrona Venture Group, described the structural dynamic: “It is complicated because we are trying to create this abstraction layer over the underlying infrastructure and telling the developers that you don’t need to worry about it. But that means there are a lot of tools that have to exist in place — whether it is development tools, deployment tools, debugging tools or monitoring tools — that enable the developer to know certain things are happening when you’re operating in a serverless environment.”

Sarah Guo echoed this from an investor’s perspective: “I think there is a lot of promise as we improve a bunch of things around making it easier for developers to access serverless, while expanding the use cases, and concentrating on issues like visibility and security, which are all [issues] when you give more and more control of [the infrastructure] to someone else.”

Beyond Tooling: APIs, Libraries, and Platform Services

The opportunity in serverless is not limited to monitoring and debugging tools. Several additional categories are worth watching:

• Function and trigger libraries: Reusable, well-tested function packages that developers can compose rather than write from scratch.
• Security tooling: Serverless functions present a different attack surface than traditional applications. Each function is a potential entry point, and access management across thousands of functions is a non-trivial problem.
• Observability platforms: Distributed tracing, log aggregation, and anomaly detection adapted specifically for ephemeral, event-driven execution environments.
• API abstraction services: Analogous to how Twilio abstracts telephony or Stripe abstracts payments, there is room for serverless-native services that expose complex capabilities through simple, event-friendly APIs without requiring domain expertise to implement.
• Developer experience and CI/CD tooling: Deployment frameworks, local testing environments, and pipeline integrations tailored to function-based workflows.

What Needs to Happen for Serverless to Reach Its Potential

Serverless is promising but not yet fully mature. Several conditions need to develop in parallel before a full startup ecosystem can form around it:

1. Developer momentum: Tooling markets only grow when there is a substantial user base. Adoption needs to reach a tipping point for the economics of building serverless-specific products to make sense.
2. Standardisation: Currently each cloud vendor’s serverless platform has its own event model, runtime support, and integration patterns. More cross-platform consistency would lower the learning curve and encourage broader adoption.
3. Improved observability: Until developers can debug and trace serverless workloads as easily as they can traditional services, there will be a ceiling on adoption in production-critical environments.
4. Expanded use cases: Today, serverless excels at stateless, short-lived tasks. As runtimes improve and cold-start latency decreases, the range of suitable workloads will widen.

The Bottom Line for Developers and Investors

Serverless is not a silver bullet, and it is still early in its adoption curve. But the structural forces driving it — developer productivity, operational cost reduction, and the relentless move toward higher abstraction — are not going to reverse. As Sarah Guo put it: “Developers don’t love running infrastructure. It’s just been a necessity.”

For developers, the practical takeaway is to start experimenting with serverless on appropriate workloads now, while building an understanding of its constraints. For startups and investors, the tooling gaps identified today — monitoring, debugging, security, and developer experience — represent concrete product opportunities that will grow alongside adoption. The ecosystem is early, but the demand signal is already visible.

From DevOps to NoOps: What Is Changing?

DevOps has always been a pragmatic philosophy rather than a fixed toolset. Integrating development and operations teams reduces friction and accelerates delivery, but it requires sustained organizational change, new skill sets, and considerable tooling investment. Many organizations find that gap harder to close than expected.

Serverless computing introduces a complementary idea: NoOps. The premise is not that operations disappear, but that operational concerns are handled entirely by the cloud platform rather than by application teams. Developers write and deploy code without provisioning servers, configuring operating systems, or managing scaling policies. The platform absorbs that complexity.

“Serverless computing allows users to run code without provisioning or managing any underlying system or application infrastructure, and they automatically scale to support increasing or decreasing loads.”

Arun Chandrasekaran, Gartner serverless analyst

Serverless: There Are Still Servers—Just Not Yours

The word “serverless” is widely acknowledged as misleading. Servers absolutely exist; they are simply owned and operated by the cloud provider. What changes is the developer’s relationship to those servers: you provide the code, the platform provides everything else.

A useful mental model: serverless extends the abstraction trajectory that cloud has always followed.

• Physical data centres — you own and rack the hardware.
• IaaS (e.g., EC2, Compute Engine) — the cloud provider owns hardware; you manage VMs, OS patches, and scaling.
• PaaS (e.g., Heroku, App Engine) — the provider manages the runtime; you manage application configuration.
• Serverless / FaaS (e.g., AWS Lambda, Azure Functions, Google Cloud Functions) — you manage only your code and its business logic. Scaling, availability, and OS maintenance belong to the provider.

AWS brought serverless into mainstream DevOps conversation when it announced AWS Lambda at re:Invent 2014. The key pricing innovation that accompanied it — paying only for the compute time actually consumed, measured in milliseconds, rather than for reserved capacity — fundamentally changed the economics of small or intermittent workloads.

Deploying Code in a Serverless (NoOps) Environment

Serverless functions are stateless, event-driven units of code. They start on demand, execute, and terminate. Common trigger patterns include:

• HTTP requests (API Gateway → Lambda)
• Message queue events (SQS, SNS, Kafka topics)
• File upload events (S3 object creation)
• Scheduled cron-style invocations (EventBridge rules)
• Database stream events (DynamoDB Streams, Firestore triggers)

This event-driven model is a natural fit for microservices architectures. A serverless function can sit behind an API endpoint, act as a processing step in a data pipeline, or glue together loosely coupled services — all without a permanently running process consuming resources between invocations.

Resource efficiency is a direct outcome: a function that sits idle costs nothing. Traditional always-on servers accumulate cost whether requests arrive or not. For workloads with spiky or unpredictable traffic, the serverless billing model can substantially reduce infrastructure spend.

What Developers Gain (and Give Up)

Gains

• No server provisioning or patching — the provider handles OS updates, kernel patches, and hardware failures.
• Automatic horizontal scaling — the platform spins up additional instances in response to load without any configuration.
• Pay-per-use pricing — idle time does not appear on the bill.
• Faster iteration — deploying a new function version is typically seconds; no VM or container startup cycle is needed.
• Reduced operational cognitive load — developers concentrate on business logic rather than infrastructure state.

Trade-offs to Understand

• Cold starts — functions that have not been invoked recently may experience latency while the runtime initialises. This varies by runtime and provider, and can be mitigated with provisioned concurrency (where supported).
• Execution time limits — most platforms enforce maximum function durations (e.g., 15 minutes on AWS Lambda as of writing). Long-running workloads require architectural redesign.
• Observability complexity — distributed, ephemeral functions make tracing and debugging harder. Structured logging and distributed tracing tools (e.g., AWS X-Ray, OpenTelemetry) become essential.
• Vendor lock-in — function runtimes and trigger bindings are provider-specific. Portability requires deliberate abstraction layers.
• Network is not free — as Gartner analyst Andrew Lerner noted, NoOps still requires robust connectivity to cloud providers. Slow serverless functions are frequently diagnosed as network problems, not code problems. Serverless is not networkless.

Practical Strategies for Serverless Adoption

Teams moving toward a NoOps model can reduce friction with a few deliberate practices:

1. Start with event-driven workloads. Image processing, notification dispatch, ETL pipelines, and webhook handlers are natural fits. Avoid starting with latency-sensitive synchronous APIs until you understand cold start behaviour in your runtime of choice.
2. Invest in observability first. Centralised logging (e.g., CloudWatch Logs, Datadog, Grafana Loki), distributed tracing, and structured log formats pay outsized dividends when debugging distributed serverless systems.
3. Build reusable internal libraries. Shared authentication, database connection helpers, and error-handling modules reduce duplication across functions and keep individual function packages small, which reduces cold start times.
4. Define Infrastructure as Code. Tools such as AWS SAM, the Serverless Framework, or Terraform allow function definitions, triggers, and IAM permissions to be version-controlled and reviewed like application code — preserving DevOps discipline even in a NoOps deployment model.
5. Harden your connectivity. Ensure egress capacity, DNS resolution performance, and VPC configuration are reviewed before moving latency-sensitive workloads to serverless.

NoOps Does Not Mean No Discipline

The NoOps label can create a false impression that serverless eliminates engineering rigour. It does not. What it eliminates is the need for a dedicated team to manage server fleets. Security hardening, cost governance (function concurrency limits, budget alarms), dependency management, and release pipelines all remain necessary — they simply operate at a higher level of abstraction.

In mature organisations, the operations role shifts from infrastructure management to platform engineering: building and maintaining the internal platforms and tooling that let application developers self-serve their serverless deployments safely and efficiently. That is, arguably, a more valuable use of operations expertise.

Summary

Serverless computing and the NoOps model it enables represent a continued evolution of cloud abstraction — one that shifts infrastructure responsibility to providers and returns developer attention to business logic. The economics of event-driven, pay-per-invocation compute are compelling, particularly for variable or unpredictable workloads. The trade-offs — cold starts, observability complexity, execution limits, and network dependency — are real and require deliberate mitigation. Teams that adopt serverless with both eyes open, investing in tooling, observability, and internal platform practices, are best positioned to realise the productivity and cost benefits the model promises.

What Is Serverless Computing?

Serverless computing is a cloud execution model in which the hosting provider dynamically allocates compute resources on demand. Customers are not required to provision, manage, or pay for dedicated servers or reserved capacity in advance. Despite the name, servers still exist — the key difference is that infrastructure management is entirely abstracted away from the developer.

Serverless is widely considered the next phase in the evolution of Infrastructure-as-a-Service (IaaS). By virtualizing both the runtime environment and operational management, it allows teams to focus entirely on application logic. The model is frequently called Function-as-a-Service (FaaS), because the basic unit of deployment is an individual function or task rather than a long-running process or container.

Core Advantages of Serverless Architecture

Agility

Because developers are not deploying, patching, or scaling servers, organisations can eliminate a significant portion of their infrastructure administration overhead. Serverless pairs naturally with a microservices architecture: small, independently deployable functions map well to discrete business capabilities, which accelerates release cycles and reduces the blast radius of any single change.

Automatic Scalability

Serverless platforms scale function instances up and down in response to real-time demand without any manual intervention from a DevOps team. An application that receives unpredictable or spiky traffic — a flash sale, a viral event, an IoT sensor burst — can absorb that load automatically and then scale back to zero when demand subsides, without any pre-warming or capacity planning.

Pay-Per-Use Billing

Traditional cloud models charge for allocated capacity whether or not it is being used. Serverless introduces a true consumption-based billing model: you pay only when a function executes, typically measured in invocation count and execution duration. This makes it particularly cost-effective for workloads with low average utilisation but occasional high peaks, or for microservices that are invoked infrequently.

Improved Security Posture

Removing server management from the customer’s responsibility also removes an entire category of attack surface. Operating system vulnerabilities, misconfigured SSH access, and server-level malware installation become the cloud provider’s concern. Additionally, the ephemeral and stateless nature of serverless functions limits the window of opportunity for certain attack patterns, and the platform’s automatic scaling can help absorb volumetric DDoS traffic that would overwhelm a fixed-capacity deployment.

Why Serverless Matters Beyond Early Adopters

Serverless is not just a productivity tool for small teams or startups. It has significant implications for large-scale distributed systems. The Internet of Things (IoT) is one compelling example: billions of devices generating intermittent, event-driven data are a near-perfect match for a FaaS execution model, where compute is triggered by incoming events and scales seamlessly with device population growth.

The major cloud platforms — Amazon Web Services, Google Cloud, Microsoft Azure, and IBM Cloud — all offer first-party serverless products. AWS Lambda, launched in 2014, was the first widely adopted commercial FaaS offering and remains a reference implementation for the category. At the time of the original article (2017), AWS reported growing enterprise adoption of Lambda, and competing providers were making similar investments.

The Serverless Ecosystem

The serverless ecosystem extends well beyond the major cloud platforms. It is broadly organised into two layers:

Platforms and Frameworks

Alongside the hyperscalers, a range of platforms and open-source frameworks have emerged to give developers more choice in how they host and run serverless workloads:

• Iron.io — A serverless application platform that supports deployment across public cloud, private cloud, and on-premises environments, giving teams more control over data residency and compliance.
• Auth0 Webtask — Developed by the Identity-as-a-Service company Auth0, Webtask allows developers to run server-side logic without managing infrastructure, with built-in support for a variety of integrations.
• Serverless Framework — A popular open-source, provider-agnostic framework that gives developers a unified interface for building, deploying, and operating serverless applications across multiple cloud providers.

Technology Enablers

A second category of tooling focuses on making serverless platforms easier to operate and observe in production:

• Stackery — An operations management platform that provides infrastructure provisioning and lifecycle visibility for serverless applications.
• IOpipe — A monitoring and debugging tool designed specifically for serverless functions, addressing the observability gap that standard APM tools often leave in FaaS environments.
• Twistlock — A cloud-native security company that, at the time of the original article, offered machine-learning-based security solutions for serverless and container workloads. (Note: Twistlock was later acquired by Palo Alto Networks and integrated into the Prisma Cloud platform.)

Early Enterprise Adopters

Large organisations have validated serverless at significant scale. Netflix, which completed a full migration to the cloud in 2016 and operates at over 100 million subscribers globally, has been a prominent advocate for AWS Lambda. The company uses serverless functions for tasks including media file delivery, instance deployments, backups, and monitoring pipelines — use cases where the event-driven, auto-scaling nature of FaaS provides clear operational advantages.

Other major organisations that had publicly adopted serverless at the time of the original article include Expedia, Coca-Cola, and Adobe, demonstrating that the model is viable across a wide range of industries and workload types.

Remaining Challenges and Opportunities

Serverless is not operations-free. Monitoring, packaging, securing, deploying, and debugging distributed functions all require engineering effort — the work simply shifts in nature rather than disappearing. Several challenges remain that represent genuine opportunities for tooling vendors and platform engineers:

Immature Tooling

Traditional APM, logging, and debugging tools were designed for long-running processes, not ephemeral functions with millisecond lifetimes. Distributed tracing across chains of function invocations, cold-start profiling, and structured log aggregation for high-volume FaaS workloads all require purpose-built solutions that were still maturing when the serverless model emerged.

Vendor Lock-In

Each cloud provider implements FaaS with its own runtime model, trigger types, configuration format, and integration points. Migrating a serverless application from one provider to another typically requires changes to application code, deployment tooling, and potentially the broader software architecture. Provider-agnostic frameworks such as the Serverless Framework partially address this, but the problem has not been fully solved.

Cold Start Latency

Serverless platforms spin up new function instances on demand, but the first invocation after a period of inactivity — a cold start — incurs an initialisation penalty that can range from tens of milliseconds to several seconds depending on the runtime, function package size, and VPC configuration. For latency-sensitive applications, this can be a significant design constraint that requires workarounds such as scheduled keep-warm invocations or provisioned concurrency features offered by some platforms.

Security in a Shared Responsibility Model

While serverless reduces the server-level attack surface, it introduces new security considerations. Insecure function permissions, overly permissive IAM roles, injection attacks via event data, and third-party dependency vulnerabilities all require attention. The shared responsibility model still places significant security obligations on the application developer, even though server management has been delegated to the provider.

Summary

Serverless computing represents a genuine shift in how applications are built, deployed, and operated. For DevOps teams, it changes the work rather than eliminating it: server patching and capacity planning give way to function observability, IAM policy management, cold-start optimisation, and event-driven architecture design. The trade-offs are well-suited to event-driven, microservices-based, and IoT workloads, and the ecosystem of supporting tools continues to mature. Understanding both the advantages and the current limitations is essential for making informed architectural decisions about where serverless fits in your infrastructure strategy.

Cloud services have transformed IT infrastructure over the past decade, but the wave of newer cloud delivery models — microservices, serverless computing, and Function as a Service (FaaS) — signals a more fundamental shift. These trends are not just changing how applications are built and deployed; they are reshaping the skill sets required of both developers and operations professionals, and with them, the very definition of DevOps.

Understanding the differences between these models matters. Most cloud providers understandably position their own offerings as best-in-class. This article cuts through that noise with a clear breakdown of each model, what defines it, and how it connects to DevOps practice.

The Rise of Microservices

The concept of microservice architecture began gaining traction around 2011. By 2015, it had become a dominant architectural pattern at large technology companies. The appeal was clear: microservices allowed large engineering organisations to break applications into small, independently deployable components. Teams could work in parallel, deploy faster, and limit the blast radius of any single failure.

Three characteristics define a true microservice:

• Independent scalability and deployability. Each service can be scaled and released without touching the rest of the application.
• Single responsibility. Each service handles the smallest meaningful unit of business logic.
• Graceful degradation. Services work better together, but the system continues functioning when one fails.

Netflix is a well-known example. Its streaming platform is composed of many individual services — including one responsible for video recommendations. If the recommendation service becomes unavailable, playback continues uninterrupted for users.

Microservices also helped drive the adoption of container technology. Docker, in particular, gave developers a practical way to package individual services with their dependencies and deploy them consistently across environments — without concern for the underlying operating system or hardware.

The Case for Serverless Computing

Serverless computing extends the abstraction further: developers write and deploy code without any involvement in server provisioning, patching, or capacity planning. Google App Engine was an early serverless offering, but the concept gained widespread attention when AWS Lambda launched and demonstrated how practical event-driven, infrastructure-free execution could be.

Three properties define a serverless environment:

• No idle charges. You pay only for actual execution time, not for capacity sitting idle.
• No provisioning required. Infrastructure scales automatically in response to demand.
• No OS or hardware management. The cloud provider handles all of that below the application layer.

One practical consideration: some providers impose concurrency or resource limits that require a manual request to raise. This is a safeguard against unexpectedly large bills when auto-scaling triggers at high volume. Teams moving to serverless should understand these limits before they become production bottlenecks.

Not all serverless platforms are the same. AWS Lambda and Auth0 Webtasks are serverless and Function as a Service. AWS CodeBuild and Google App Engine are serverless, but are not FaaS — an important distinction covered in the next section.

Function as a Service: On-Demand Code Execution

AWS Lambda, introduced in 2014 and made generally available in 2015, popularised the Function as a Service model. FaaS takes the serverless premise and narrows it further: instead of deploying an application or a service, you deploy a single function that executes in response to a specific event.

Three characteristics define FaaS:

• Event-driven execution. Code runs only when triggered; there are no idle executions.
• Automatic scaling. The platform spins up as many function instances as needed, then tears them down.
• Single-purpose scope. Each function does one thing, with no concern for the OS or hardware beneath it.

FaaS functions are typically short-lived — executions are bounded by a maximum runtime set by the provider (AWS Lambda’s default maximum has evolved over time; verify current limits in provider documentation). They suit use cases such as responding to HTTP requests, processing queue messages, applying business logic rules, handling webhooks, or serving as middleware between a user interface and a database.

An important clarification: FaaS does not automatically mean serverless. A framework like Docker Functions can deliver event-triggered, single-function execution while still requiring servers or virtual machines to run the Docker daemon. FaaS describes the execution model — code that fires in response to an event — not the infrastructure model.

Where Platform as a Service Fits

Platform as a Service (PaaS) is the older sibling of these models. PaaS removes hardware and operating system management but typically provides a complete application runtime rather than a function-level abstraction. Providers such as Heroku and Google App Engine fall into this category. They accept application code and handle scaling, load balancing, and runtime management automatically.

Two properties define PaaS:

• End-to-end application platform. The provider supplies the full stack needed to build and run an application.
• No provisioning, hardware, or OS management. The developer focuses only on application code.

Unlike FaaS, PaaS often involves some idle runtime — the platform keeps a baseline capacity running even when traffic is low. For this reason, PaaS can carry idle costs and is generally not considered a microservices architecture in the strict sense.

Many teams have moved from PaaS to FaaS to gain a higher level of abstraction and to reduce dependency on a single vendor’s runtime environment. Google Firebase is a notable exception: it began as a database service and evolved into a broad PaaS that also offers FaaS capabilities through Firebase Functions (backed by Google Cloud Functions), giving developers access to both models from a single platform.

Software as a Service: The Highest Level of Abstraction

Software as a Service (SaaS) represents the furthest point from infrastructure management. With SaaS, users interact with a finished application delivered over the internet — no installation, no configuration, no coding required.

For a product to qualify as SaaS, it must:

• Require no installation on the user’s machine.
• Require no coding to get started.
• Be accessible from any internet-connected device.
• Scale automatically to meet user demand.

Familiar examples include Salesforce, Gmail, and many developer-facing tools for monitoring, security, and analytics. Developers and operations teams consume SaaS products continuously, even while building systems based on other cloud models.

One important distinction: SaaS offerings cannot be directly joined to build a new application. If code is required to connect two systems, at least one of those systems is not purely SaaS. In practice, a serverless application often uses FaaS as the glue layer that connects multiple SaaS products — for example, a Lambda function reading from and writing to Amazon DynamoDB (a managed database service). The FaaS layer contains the business logic; the SaaS products provide the underlying capabilities.

The DevOps Connection: Why These Trends Matter for Your Team

All of the above delivery models — microservices, serverless, FaaS, PaaS, SaaS — are cloud services. Any service that removes the need for local hardware or software installation is, by definition, a cloud offering. And as cloud adoption has grown, the role of traditional IT operations has changed with it.

The original DevOps movement emerged partly from a practical need: as virtualised infrastructure replaced physical servers, operations staff needed to learn scripting and development skills to manage infrastructure programmatically. That is still true. But microservices, serverless, and FaaS introduce a second, less-discussed shift: developers now need to understand operations.

When cloud providers automatically handle provisioning and scaling, it becomes impossible for an operations team to monitor and control resources in the traditional sense. Developers who design and build serverless applications must understand the operational characteristics of the services they use — concurrency limits, cold start behaviour, timeout constraints, data access patterns, and cost implications of scale.

A concrete example illustrates the stakes: Amazon DynamoDB can be provisioned to handle very high throughput. However, read and write performance at scale depends heavily on the choice of partition key (hash key). A poor partition key design causes hot partitions — uneven load distribution that throttles requests even when overall provisioned capacity is sufficient. Once an application is in production, changing the partition key design is costly and disruptive. A developer who does not understand this constraint before writing the data model will likely need to rewrite significant portions of the application later.

This is the essence of what modern DevOps requires in a serverless world. It is not enough for developers to write code that works in isolation. They must understand the operational properties of every managed service in their architecture — before the first line of application code is committed.

Summary: Choosing the Right Cloud Model

Each model offers a different balance of control, abstraction, and operational responsibility. The right choice depends on your team’s skill set, your application’s traffic patterns, and how much control you need over the runtime environment. Understanding these distinctions — rather than accepting a provider’s marketing claims at face value — is a core competency for any modern DevOps engineer.

What Is Serverless Computing?

Serverless computing is a cloud-oriented execution model in which the cloud provider dynamically manages the allocation and provisioning of underlying infrastructure. Despite its name, serverless does not mean there are no servers — hardware still runs your code. What changes is that server management becomes entirely invisible to the application developer.

In a serverless environment, developers do not define server attributes, configure operating systems, or maintain runtime environments. Instead, they write discrete units of logic — commonly called functions — that are invoked on demand in response to events. The cloud provider handles everything beneath that function boundary: scaling, patching, networking, and resource scheduling.

Commercially, serverless is typically billed on a consumption model. Rather than reserving a fixed unit of compute capacity (a VM size or container node), you pay only for the compute time your function actually consumes, measured at a fine-grained interval such as milliseconds, seconds, or minutes depending on the provider.

The architectural pattern most closely associated with serverless is Functions-as-a-Service (FaaS) — fully preconfigured, stateless, event-driven functions deployed and scaled by the platform automatically.

Key Benefits for Developers and Operations Teams

• Reduced operational overhead: Developers no longer maintain OS patch levels, microcode, middleware, or runtime environments. The cognitive and operational load shifts almost entirely to writing and testing business logic.
• Automatic scalability: Serverless platforms scale horizontally by invoking additional function instances in response to demand, without operator intervention or pre-provisioning.
• Cost efficiency: The consumption-based billing model means idle capacity costs nothing. For workloads with irregular or spiky traffic patterns, this can be significantly more cost-effective than reserved instances or always-on containers.
• Faster iteration: Because infrastructure concerns are abstracted away, development cycles can focus exclusively on feature delivery and function logic.

Primary Use Cases

Serverless architectures are best suited to stateless applications and event-driven workloads. Concrete examples include:

• API backends: Publishing and responding to REST or GraphQL API calls where each request is independent.
• Event-driven processing: Triggering logic in response to file uploads, database changes, message queue events, or webhook callbacks.
• Real-time data transformation: Processing streams of data (e.g., filtering, enriching, or routing) without persistent state.
• AI/ML inference endpoints: Serving predictions for use cases such as image recognition, voice recognition, or natural language processing, where each inference call is stateless.
• Notification and alerting pipelines: Sending emails, push notifications, or Slack messages in response to application events.
• Edge and IoT applications: As IoT devices emit event data, serverless functions can perform real-time analysis and trigger control actions — for example, adjusting flow rates or switching device states — without maintaining persistent application state on the edge node.
• Analytical and scientific workloads: Certain batch-oriented high-performance computing jobs — such as genomics pipelines, climate modeling, or business intelligence queries — are well-suited to serverless because individual compute tasks can be parallelized as stateless function invocations.

Serverless is generally not the right fit for long-running, stateful enterprise applications that require persistent connections, in-memory session state, or guaranteed low-latency responses. Those workloads are likely to remain on traditional VM or containerized architectures for the foreseeable future.

A Brief History: Where Did Serverless Come From?

AWS announced Lambda in 2014, widely regarded as the first commercially available FaaS offering. The concept resonated quickly, and the major cloud providers followed with their own implementations:

• AWS Lambda (Amazon Web Services) — announced 2014
• Google Cloud Functions (Google)
• Azure Functions (Microsoft)
• IBM Cloud Functions (IBM, based on the Apache OpenWhisk open-source project; originally launched as Bluemix OpenWhisk)

The space has matured considerably since 2014, but the fundamental FaaS model — event-triggered, stateless, infrastructure-abstracted functions — remains consistent across providers.

Caveats and Risks Developers Must Understand

Serverless is not without operational complexity. Engineers adopting it should be aware of the following challenges:

Latency and Cold Starts

Because serverless functions run in a shared cloud environment, execution is subject to variable latency. Functions that have not been invoked recently may experience a cold start — a delay while the platform initializes the execution environment. This can be significant for latency-sensitive applications. Developers must design functions to handle timeouts gracefully and implement appropriate retry logic.

Error Recovery and Resilience

Serverless functions must be designed to be idempotent where possible. Because invocations may be retried by the platform on failure, functions that are not idempotent risk producing duplicate side effects. Rigorous testing — including failure injection and timeout simulation — is essential before production deployment.

Service Level Agreements

SLAs offered by cloud providers for serverless workloads have historically been less stringent than those for dedicated infrastructure. Teams building applications with strict uptime or latency requirements should review provider SLAs carefully and design for graceful degradation.

Serverless Sprawl

The ease of deploying serverless functions creates a governance risk sometimes called serverless creep — analogous to VM sprawl or container sprawl. Because functions are cheap and quick to deploy, organizations can rapidly accumulate hundreds or thousands of functions with poorly documented ownership, overlapping functionality, and untracked costs. Development managers should establish:

• A function registry or catalogue with clear ownership
• Naming conventions and tagging strategies for cost allocation
• Regular audits of the active function portfolio
• Compliance and audit trails, particularly for functions that process regulated data

Vendor Lock-In and Portability

Different serverless platforms support different runtime languages and trigger mechanisms. A function written for AWS Lambda using a specific event source mapping may not be directly portable to Azure Functions or Google Cloud Functions. Additionally, provider-specific SDKs and integrations can deepen lock-in. Organizations should weigh the convenience of native platform integrations against the risk of being tied to a single provider’s ecosystem, and consider whether open-source frameworks (such as those built on Apache OpenWhisk or the CNCF serverless landscape) address their portability requirements.

How Serverless Relates to Containers and PaaS

Serverless and containers are complementary, not competing technologies. Under the hood, most FaaS platforms use containers as the execution primitive — each function invocation runs inside a lightweight, isolated container environment. The difference is that serverless abstracts container lifecycle management entirely: developers never build container images, define resource limits, or manage orchestration.

Platform-as-a-Service (PaaS) sits in a middle ground. PaaS environments expose a microservices architecture but typically still require developers to reason about containerized services, scaling configurations, and deployment pipelines. Serverless goes further by removing even that layer of concern — provided the cloud provider’s abstraction is sound.

A practical mental model for DevOps teams:

• VMs: Full control, full responsibility for OS and runtime
• Containers (self-managed): Portable, reproducible, but requires orchestration expertise
• PaaS / managed containers: Reduces orchestration burden; developers still define service topology
• Serverless / FaaS: Maximum abstraction; developers define only function logic and event triggers

Getting Started: Practical Recommendations

If your team is evaluating serverless adoption, the Wikibon research team’s guidance remains sound as a starting point:

• Start simple: Choose a well-understood, low-risk stateless workload as your first serverless project — API notification handlers, webhook processors, or scheduled data export jobs are good candidates.
• Design for failure from day one: Implement timeouts, retries, and dead-letter queues before you go to production. Assume invocations will fail and plan recovery paths explicitly.
• Establish governance early: Define tagging, ownership, and audit policies before your function portfolio grows unwieldy.
• Evaluate portability needs: If multi-cloud or cloud-agnostic deployment is a requirement, explore framework options that abstract provider-specific APIs.
• Keep stateful workloads on appropriate infrastructure: Do not force serverless onto applications with persistent session state, long-running transactions, or complex stateful workflows. Use the right tool for the job.

Serverless is a durable architectural pattern, not a passing trend. As FaaS platforms mature and tooling improves, the operational complexity gap between serverless and traditional deployment models will continue to narrow — making it an increasingly practical default choice for stateless, event-driven workloads in cloud-native architectures.

What Is Azure Stack?

Azure Stack is Microsoft’s on-premises extension of its Azure public cloud platform. It allows enterprises and service providers to run their own instances of the Azure environment inside their own datacenters, using the same APIs, tooling, and management interfaces as the public Azure cloud. Rather than treating on-premises infrastructure as a separate silo, Azure Stack is designed to present itself as just another Azure region — enabling a genuinely consistent hybrid cloud model.

As Microsoft CEO Satya Nadella stated at the Inspire conference keynote: “We’re building out Azure as the first hyper-scale cloud that supports true distributed computing with Azure Stack.”

General Availability and Hardware Partners

After more than two years of development and preview programs, Microsoft announced at its 2017 Inspire conference that Azure Stack would reach general availability in September 2017. Hardware-integrated systems — sometimes called Azure Stack appliances — were to be delivered by a set of launch partners:

• Dell EMC — GA appliances available September 2017, based on PowerEdge R730XD systems, with follow-on hardware built on the then-new 14th-generation server platform using Intel Xeon Scalable (“Skylake”) processors.
• Hewlett Packard Enterprise (HPE) — GA appliances available September 2017.
• Lenovo — GA appliances available September 2017.
• Cisco — Appliances planned for later in 2017.
• Huawei — Appliances planned for Q1 2018.

Dell EMC had already launched a single-node developer edition of Azure Stack in May 2017 — priced at $20,000 — for teams wanting to evaluate the platform before production-grade systems became available. Full production appliances were planned to support up to 12 nodes.

A Common Application Model Across Cloud and On-Premises

The central value proposition of Azure Stack is developer consistency. Microsoft Corporate VP Julia White summarized it at the Inspire press briefing:

“You’re writing one set of code, you’re updating one set of code, you’re deploying one set of code but it is running in two places. In a Visual Studio dropdown, you can select Azure or Azure Stack. It’s that simple.”

Julia White, Corporate VP, Microsoft

This means DevOps pipelines, ARM templates, and CI/CD toolchains built for Azure are intended to work without modification against an Azure Stack deployment. Teams do not need to maintain separate infrastructure-as-code definitions or separate deployment scripts for on-premises versus cloud targets.

Supported Workloads at Launch

At general availability, Azure Stack was scoped to the most commonly used Azure capabilities. Supported workloads included:

Infrastructure as a Service (IaaS)

• Virtual Machines — Standard VMs and Windows Server images
• Storage — Azure Blob, Table, and Queue storage

Platform as a Service (PaaS)

• Azure App Service — Including Web Apps, Mobile Apps, API Apps, and Azure Functions
• SQL Server — Running in Azure Stack VMs, enabling database-as-a-service patterns

Services planned for the near-term roadmap at the time included IoT Hub and Azure Data Services. Microsoft Senior Product Director Mark Jewett noted that while native Azure Data Services were not yet available, SQL Server running inside Azure Stack VMs could fill that gap in the interim.

Serverless Computing with Azure Functions On-Premises

One of the more significant technical capabilities included from day one was support for Azure Functions via the App Service offering. This means organizations could run event-driven, serverless workloads entirely on-premises — a scenario not previously easy to achieve with competing platforms at the time.

Nadella positioned serverless as the next major wave in application architecture at the keynote:

“Virtualization has been amazing, but now this new era of micro services, containers and serverless [computing] is going to be fundamentally transformative to the core of what we write as applications.”

Satya Nadella, CEO, Microsoft

By including Azure Functions in the Azure Stack App Service, Microsoft was enabling organizations to adopt serverless patterns without requiring all workloads to reside in a public cloud — a key concern for regulated industries and data-sovereign environments.

Target Use Cases

Azure Stack was positioned to address several scenarios where running workloads entirely in a public cloud is impractical or prohibited:

• Data sovereignty and compliance — Industries or jurisdictions requiring that data remain within specific geographic or organizational boundaries.
• Disconnected or intermittent connectivity — Edge computing scenarios such as cruise ships, oil rigs, remote mining sites, or military deployments where reliable internet access cannot be guaranteed.
• Legacy system modernization — Organizations wanting to build new cloud-native applications that interact with existing on-premises systems without a full cloud migration.
• Consistent hybrid operations — Teams wanting a single control plane, API surface, and toolchain across both public cloud and on-premises deployments.

Underlying Infrastructure: Windows Server 2016 Technologies

Azure Stack is built on the software-defined infrastructure capabilities introduced in Windows Server 2016, including:

• Storage Spaces Direct — Hyper-converged storage using local disks across nodes
• Hyper-V — Virtualization layer for running VMs
• Windows Containers — Container runtime support consistent with Azure

These components allow Azure Stack to deliver a consistent software-defined infrastructure layer that mirrors what Microsoft operates in its public Azure regions, making the common API and management model technically feasible.

How Unique Is Azure Stack’s Hybrid Approach?

Microsoft’s claim of being “the first” true hybrid cloud offering was contested even at launch. Competing solutions from VMware and OpenStack-based appliance vendors had been addressing hybrid cloud scenarios for years before Azure Stack reached general availability.

However, Microsoft’s specific differentiation — and the claim that partners like Dell EMC supported — was the shared control plane: a single Azure Resource Manager (ARM) API surface, portal experience, and toolchain that spans both environments without requiring separate management interfaces. Paul Galjan, Senior Director of Product Management for Dell EMC Hybrid Cloud Platforms, commented at the time: “It is unique. It fits into a niche in the market that no other software vendor is offering anything quite like it.”

Whether that control-plane consistency is a sufficient differentiator for a given organization depends heavily on how deeply invested that organization already is in Azure tooling and skill sets.

Key Takeaways for DevOps Teams

• Azure Stack enables a single ARM-based deployment pipeline that targets both Azure public cloud and on-premises infrastructure.
• DevOps teams can use the same Visual Studio tooling, Azure CLI, PowerShell modules, and ARM templates for both environments.
• Serverless workloads via Azure Functions can be hosted entirely on-premises, reducing dependencies on public cloud connectivity for event-driven architectures.
• PaaS capabilities reduce the operational overhead of managing individual VMs for application hosting — even in disconnected or regulated environments.
• The hardware comes pre-integrated from validated OEM partners, reducing the infrastructure complexity traditionally associated with on-premises private cloud deployments.

Note: This article reflects announcements and plans as of July 2017. Azure Stack has continued to evolve significantly since then, including the introduction of Azure Stack Hub, Azure Stack Edge, and Azure Stack HCI as distinct product lines.

Most of what we now call serverless computing grew from AWS Lambda, later joined by equivalent managed services on Microsoft Azure, Google Cloud Platform, and IBM Bluemix. However, a healthy ecosystem of open source serverless frameworks also exists. These projects range from foundations that commercial clouds build on top of, to experimental research platforms for exploring the boundaries of the model without commercial constraints.

The five frameworks below are self-contained serverless runtimes—not thin wrappers around a specific cloud provider’s service. Projects whose primary purpose is to facilitate an existing managed offering (such as Zappa for AWS Lambda) are out of scope here.

1. Apache OpenWhisk

Apache OpenWhisk is one of the most mature open source serverless frameworks available. Written primarily in Scala, it follows an event-driven model: triggers represent named event streams, actions are the functions that execute in response, and rules bind triggers to actions. A single trigger can chain multiple actions together, enabling simple workflows without a dedicated orchestration layer.

Actions can be written as JavaScript or Swift snippets, or packaged as arbitrary binaries inside Docker containers. OpenWhisk integrates with external services that expose webhooks or API endpoints—including GitHub and Slack—making it straightforward to build event-driven automations across SaaS tools.

IBM chose OpenWhisk as the foundation for its managed serverless offering on IBM Bluemix (now IBM Cloud Functions), which is a strong signal of production readiness. The project graduated through the Apache Incubator process and is a top-level Apache project.

Key characteristics

• Event-driven trigger/action/rule model
• Supports JavaScript, Swift, Python, Java, and Docker-packaged runtimes
• REST API and CLI for managing functions and triggers
• IBM Cloud Functions is built directly on OpenWhisk

2. Fission

Fission is a Kubernetes-native serverless framework created by Platform9. Rather than managing its own container scheduler, it runs on top of an existing Kubernetes cluster—whether that cluster is managed by Platform9 or self-hosted. This means your serverless functions share the same infrastructure and operational tooling as the rest of your Kubernetes workloads.

Functions are provisioned in Docker containers and executed in response to HTTP requests or other event triggers. One notable feature is pool-based pre-warming: Fission keeps a pool of idle containers ready so that commonly invoked functions avoid the cold-start penalty typical of serverless platforms.

The philosophical argument for Fission is that Kubernetes already solves the hard problems of scheduling, networking, and resilience. Serverless on Kubernetes lets developers focus purely on function logic while operators work with familiar Kubernetes primitives rather than a proprietary control plane.

Key characteristics

• Runs on any standard Kubernetes cluster
• Pre-warmed container pools reduce cold-start latency
• HTTP trigger support; integrates with Kubernetes ingress controllers
• Language support via container images—any language that fits in a container

3. IronFunctions

IronFunctions, from Iron.io, takes a container-first approach: each function is a Docker container. Because the unit of work is just a Docker image, IronFunctions is language-agnostic by design—any runtime that can be containerized is a valid choice. The only hard dependency is Docker and a Docker Hub account; an orchestrator like Kubernetes is optional rather than required.

Functions written in Go—the same language used to build IronFunctions itself—can be compiled and deployed directly from the framework’s CLI, making Go a particularly ergonomic choice. IronFunctions also features AWS Lambda compatibility: Lambda functions can be imported and executed within IronFunctions without modification, which provides a migration or multi-cloud path and reduces vendor lock-in.

Key characteristics

• Docker container as the fundamental unit of execution
• Language-agnostic: any containerizable runtime works
• AWS Lambda import compatibility
• Kubernetes and other orchestrators are optional, not required

4. Gestalt

Gestalt positions itself as a pre-integrated suite of microservices for cloud-native applications. Its serverless component—referred to by the project as the Lambda Engine—is one layer within that broader platform rather than a standalone tool.

The Lambda Engine supports a wide range of language runtimes out of the box, including JavaScript, Python, Go, Ruby, Scala, and .NET. If your language is not on the default list, Gestalt supports custom executor implementations. Deployment targets include Kubernetes clusters (installed via Helm) and Mesosphere DC/OS, so the framework fits naturally into organisations that already operate either of those orchestration platforms.

Note: Claims about Gestalt’s performance relative to AWS Lambda in the original source article are not independently verified. Treat such comparisons with caution until you can benchmark against your own workloads.

Key characteristics

• FaaS is one component of a broader cloud-native platform
• Broad language support; extensible with custom executors
• Helm-based install for Kubernetes; DC/OS installer also available
• Designed for organisations already invested in Kubernetes or Mesosphere

5. OpenLambda

OpenLambda is not designed for production. It is an academic and research project whose stated goal is to enable exploration of new approaches to serverless computing. The project’s accompanying research paper outlines its intentions explicitly: provide a minimal, hackable platform where researchers and engineers can experiment with the fundamentals of serverless design without the constraints imposed by a production-ready system.

Only basic functionality is implemented, and the developers themselves warn against production deployment due to intentional security trade-offs made in favour of simplicity and explorability. If you want to understand what happens at the lowest layers of a serverless runtime—scheduling, isolation, cold-start mechanisms—OpenLambda gives you a small, readable codebase to work from.

Key characteristics

• Research and experimentation platform, not for production
• Minimal codebase designed for readability and modification
• Useful for understanding serverless internals at a low level
• Intentional security limitations—do not deploy in shared or public environments

Choosing the Right Framework

The right open source serverless framework depends on your existing infrastructure and goals:

• Already running Kubernetes? Fission integrates directly and adds pre-warming to reduce latency.
• Need AWS Lambda compatibility? IronFunctions imports Lambda functions and removes cloud lock-in.
• Want a battle-tested, cloud-vendor-backed option? Apache OpenWhisk is the most mature choice and powers IBM Cloud Functions.
• Operating a Kubernetes or DC/OS cluster and want broader platform features? Gestalt bundles serverless into a wider cloud-native stack.
• Researching serverless internals? OpenLambda provides a minimal, hackable foundation—just keep it off the public internet.

Open source serverless frameworks give teams control over runtime environment, deployment target, and cost model that managed cloud functions cannot match. As the ecosystem matures, several of these projects have already influenced or become the foundation of commercial offerings—a sign that the underlying designs are sound.

Original article source: infoworld.com (2017). Framework status and features may have evolved since publication—verify current documentation before adopting any project for production use.

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.

Two platforms dominate this space for most enterprise teams: AWS Lambda, which launched in late 2014, and Microsoft Azure Functions, which followed in 2016. Both solve the same core problem, but they differ in meaningful ways. This article breaks down those differences so you can make an informed decision.

What “Serverless” Actually Means

The term is a misnomer — your code still runs on servers. What changes is who manages them. In a serverless model, the cloud provider handles all infrastructure concerns: server provisioning, scaling, availability, and runtime patching. Developers write functions that respond to events (an HTTP request, a file upload, a queue message) and the platform takes care of everything else.

This model is well-suited to event-driven workloads. Common use cases include:

• Media processing (video transcoding, image resizing)
• On-demand ETL pipelines
• Mobile and IoT back ends
• Web application APIs
• Stream and timer-based processing
• Webhook handlers and automation scripts

Programming Language Support

Language support is often the most immediately relevant differentiator, because it directly affects whether your existing developers can be productive on day one.

At the time of the original comparison (early 2017), the two platforms supported the following languages natively:

Both platforms have expanded their language support significantly since 2017 — AWS Lambda now supports runtimes including Go, Ruby, and custom runtimes via the Runtime API, while Azure Functions has similarly grown its supported language list. Always check the current documentation for each service before making a decision based on language support alone.

The practical advice remains sound: match the platform to the skills your team already has. If your back-end developers are primarily PHP or PowerShell practitioners, Azure Functions eliminates the need to introduce a new language. If your team lives in Python or Java, Lambda has been a mature option for those runtimes longer.

Pricing Models

Both services offer a permanent free tier (not just a trial) that is generous enough to cover low-volume workloads and experimentation:

• 1 million free requests per month
• 400,000 GB-seconds of compute time per month

Beyond the free tier, both services bill on two dimensions: the number of function invocations and the compute resources consumed (measured in GB-seconds or GB-milliseconds). The exact per-unit rates below are from the original 2017 source and should be verified against current pricing pages before budgeting.

Azure Functions Pricing (as of original article)

• $0.20 per million executions beyond the free tier
• $0.000016 per GB-second of compute usage
• Optionally, functions can run within an existing Azure App Service Plan, which changes the effective cost

AWS Lambda Pricing (as of original article)

• $0.20 per million requests beyond the free tier
• Compute fees scale with the memory allocation you configure: 128 MB costs approximately $0.000000208 per 100 ms; 1,536 MB costs approximately $0.000002501 per 100 ms

In practice, the headline compute costs are close enough that pricing alone is rarely the deciding factor. Where costs diverge is in the surrounding services: storage, databases, API gateways, data transfer, and monitoring. These ancillary costs can exceed the function execution costs themselves for many real-world applications, so model your full architecture when estimating spend.

Both AWS and Azure provide cost estimation calculators on their respective websites to help with this.

Ecosystem Integration: The More Important Factor

For most organizations, the surrounding ecosystem matters more than the FaaS platform itself. A serverless function rarely runs in isolation — it is triggered by, and produces output for, other cloud services: object storage, message queues, databases, API gateways, and monitoring systems.

John Chapin and Mike Roberts, co-founders of Symphonia (a serverless and cloud consultancy), put it clearly: “We often see developers and companies evaluating serverless compute offerings in a vacuum — the real value is in the capability of the entire serverless ecosystem that a cloud provider offers.”

This leads to the most actionable rule of thumb:

If your organization already has significant investment in a cloud platform, default to that platform’s serverless offering. Migrating data, re-integrating services, and retraining teams costs far more than any per-invocation pricing difference.

Teams already using S3, DynamoDB, API Gateway, and CloudWatch will find Lambda far easier to integrate than Azure Functions. Teams using Azure Blob Storage, Cosmos DB, and Azure Monitor will have the opposite experience.

How to Choose: A Decision Framework

Use these questions to guide your selection:

1. Where does your existing infrastructure live? Default to the serverless offering from your primary cloud vendor.
2. What languages does your team use? Check current runtime support for both platforms. This matters most if you use a less common language like F# or PowerShell.
3. What events will trigger your functions? Verify that the triggering service (e.g., a specific message queue or storage event type) has native integration with your chosen platform.
4. What does your full-stack cost look like? Model the cost of the entire event pipeline, not just the function invocations.
5. Have you run a small proof of concept? Both platforms offer free tiers. Run a representative workload on each before committing.

Getting Started

Both AWS Lambda and Azure Functions are accessible through their respective consoles and CLIs, and both offer infrastructure-as-code support (AWS SAM / CloudFormation for Lambda; Bicep / ARM templates for Azure Functions). Start with a single, well-defined function that handles one event type — a webhook, a file-upload trigger, or a scheduled job — before expanding to more complex event-driven architectures.

The free tiers are generous enough that you can run meaningful experiments at zero cost. Take advantage of that before locking in a platform choice for production workloads.

This article is based on a comparison originally sourced from Datamation (2017), with updated context. Pricing figures and language support lists reflect the state of each platform at that time and should be verified against current AWS and Azure documentation.