This article is based on a TechTarget piece originally published in 2017. The core architectural concepts remain relevant, though specific service details and pricing models may have evolved.
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
| Model | Idle Costs | Provisioning Required | Abstraction Level | Typical Use Case |
|---|---|---|---|---|
| Microservices | Depends on host | Depends on host | Architecture pattern | Modular, independently deployable services |
| Serverless | No | No | High | Event-driven workloads, variable traffic |
| FaaS | No | No | Very high | Lightweight, short-lived event handlers |
| PaaS | Sometimes | No | High | Full application runtimes without infrastructure work |
| SaaS | N/A | No | Highest | Finished software consumed directly by users |
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.