A customer-facing website and a self-service rack of virtual machines look like very different things, but structurally both are digital services: a managed boundary around the capabilities needed to deliver and sustain a defined outcome for consumers, exposed through some kind of interface. That boundary can sit anywhere in the technology stack — a commercial website, an application platform, a managed virtual infrastructure service — and services at very different levels still share the same underlying vocabulary.
Every digital service has an Offering, which defines what the service provides, and an Interface, through which people or machines consume it. Depending on the service, its boundary may also include Application, Platform, Virtualization, Hardware, and Data Center layers. A service therefore comprises the layers relevant to what it delivers—not a fixed slice of the stack shared by every service.
In this model, a service’s boundary identifies the layers its provider directly manages. Capabilities outside that boundary are consumed through other digital services, though the provider remains accountable for its promised outcome regardless of which layers it manages itself. Services routinely stack this way: an application platform can be a digital service in its own right while also being the foundation that several business-facing digital services are built on.
The rest of this post works through what each of those seven layers means, then how they combine and stack across real examples — including how familiar commercial labels such as SaaS, PaaS, and IaaS describe capabilities exposed at a service boundary.
The Seven Layers
Offering and Interface are always present; the rest are optional, depending on how much of the stack a service directly manages — what it actually spans is where the interesting design decisions live. Nor are the seven homogeneous: Offering describes the promised capability, Interface describes how it is consumed, and everything below describes progressively more physical parts of the implementation.
| Layer | Presence | What it is |
|---|---|---|
| Offering Layer | Always present | The promised capability — what the service exists to provide to whoever consumes it, human or machine. “Let customers buy products.” “Provision a virtual machine on demand.” “Store an object and get it back later.” Every service has one, even when everything beneath it is consumed from someone else. |
| Interface Layer | Always present | The concrete, consumable surface through which that capability is reached: a web UI, an API, a CLI, a Terraform provider, a self-service portal. Every service has one — it sits on whichever implementation layer lies immediately beneath it. |
| Application Layer | Optional | Custom logic that turns whatever the service runs on — typically a Platform, but sometimes Virtualization directly — into its specific promised outcome: request handlers, business rules, database queries. Not every service has one: control-plane logic intrinsic to a Platform or Virtualization product belongs to that underlying layer rather than forming a separate Application layer of its own. |
| Platform Layer | Optional | What turns compute, storage, and network capacity into one or more environments an application can run on: managed runtimes, data services, networking primitives, secrets, and observability plumbing. A provider may assemble and operate this layer itself or consume it through another digital service. |
| Virtualization Layer | Optional | Hardware turned into schedulable resources: virtual compute, virtual storage, virtual network. A hypervisor produces this layer; infrastructure providers expose it as a managed service. |
| Hardware Layer | Optional | The physical equipment that runs inside a Data Center: racks, servers, network gear, storage arrays. Usually consumed through Virtualization, though bare-metal services expose it more directly. |
| Data Center Layer | Optional | The physical site itself: the facility, its geography and jurisdiction, its power and connectivity, its physical security. Higher layers almost always abstract the specific facility away, but its location and characteristics still constrain residency, latency, resilience, and regulatory compliance. |
Interface Is Not Application
Interface and Application are easy to conflate, since both often get bundled together as “the application” people build. But they are separate layers in this model: Interface is just the exposed surface — a web UI, an API, a CLI — while Application, when a service has one, is the custom logic behind that surface.
Take a rack, its servers, and its network, virtualized and exposed through something like Proxmox’s own self-service portal. That service’s scope stops at Virtualization: it provides schedulable virtual resources, but no execution environment or application-oriented data services constituting a Platform layer. Proxmox’s orchestration, authorization, scheduling, and lifecycle logic are custom logic in the functional sense, but they are control-plane logic intrinsic to the Virtualization product itself, not a specialization of some Platform underneath — so they belong to the Virtualization layer rather than forming a separate Application layer. Proxmox’s web UI and API are still that service’s Interface, and “provision a virtual machine on demand” is still its Offering.
Different Boundaries, Same Vocabulary
Call the Proxmox rack Service A. Now compare it with Service B: an analytics tool — a team builds a web application that other businesses use to track their own usage metrics. Its own code — request handlers, business rules, database queries — is its Application layer; the pages and API responses that code produces are the Interface; “track and report on a customer’s usage data” is the Offering. Underneath, the team runs it on a platform-as-a-service — someone else’s Platform, built on someone else’s Virtualization, built on someone else’s Hardware, housed in a Data Center the team never has to think about. The team directly designs and operates three layers: Offering, Interface, and Application; it obtains everything below from other services.
Neither boundary looks like the other’s — Service A stops below Platform with no Application layer of its own, Service B spans the top three layers and consumes the rest — yet both are digital services, each with an Offering delivered through an Interface. Same seven concepts, two very different shapes.
How the Market Labels These Offerings
None of this is new — the market already has names for several offerings resembling these layers, although those names describe what consumers receive rather than every layer a provider manages internally. Service A exposes virtualized infrastructure and therefore resembles Infrastructure-as-a-Service (IaaS). Service B exposes a finished analytics application and is Software-as-a-Service (SaaS), whether its provider runs it on PaaS, IaaS, or infrastructure of its own. A separately offered application platform is Platform-as-a-Service (PaaS), while a managed database is Database-as-a-Service (DBaaS). Each label identifies the capability presented at a service boundary; it does not fully reveal what lies behind that boundary.
Because each of those products is a digital service in its own right, the stack can be walked recursively, and the same service can play different roles depending on which relationship you examine: Service B’s PaaS provider is itself a consumer of Infrastructure-as-a-Service from a cloud provider, which in turn virtualizes Hardware it owns and houses in a Data Center it owns or leases. The PaaS’s own boundary never changes — Offering and Interface always face upward, dependencies always face downward — only the relationship being examined does.
Where the Boundary Sits Is a Design Decision
A service’s boundary is chosen, not derived — nothing forces it to stop at any particular layer. Three considerations usually decide it, and none of them are really about the technology:
Operational responsibility. Who responds directly if this layer fails at 3 a.m.? An organization may manage the layer itself or consume it from a provider that assumes responsibility for operating it. Either way, the organization remains accountable for the outcome promised by its own service.
Economics of scale. Virtualizing hardware well enough to sell reliably is expensive to do once and cheap to do at scale — which is why most organizations consume Virtualization from a cloud provider rather than building a rack of their own, the way Service A does.
Capability. Directly managing a layer only pays off if the organization actually has, or is willing to build, the capability to run it well. A team with deep infrastructure skills and no interest in application work is a natural fit for Service A. A team that wants to spend all of its capacity on the product it is selling is a natural fit for consuming everything below Interface, as in Service B.
Two services solving what looks like the same problem can legitimately draw the boundary in different places, and both can be right for the organization that built them.
This is the same vocabulary the Digital Service Life Cycle Model uses across all seven layers, whatever level of the stack a given service happens to occupy — not just the business-facing case most people picture first.
Where does your own service’s boundary actually stop — and is that because the technology forced it there, or because that is simply where your team’s capability, or appetite for 3 a.m. pages, ran out? Leave a comment below, or reach out through another channel if you would rather keep the conversation private. Follow the RSS feed for more.