Digital Building Blocks

Cloud computing, as formally defined by NIST Special Publication 800-145, delivers on-demand access to a shared pool of configurable computing resources (networks, servers, storage, applications, and services) over a network with minimal management effort or service provider interaction. The definition establishes five essential characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service.

The three service models partition responsibility between provider and consumer. Infrastructure as a Service (IaaS) - exemplified by AWS EC2, Azure Virtual Machines, and Google Compute Engine - delivers virtualised compute, storage, and networking. The provider manages the physical hardware; the organisation manages the operating system upward. Platform as a Service (PaaS) - Google App Engine, Heroku, Azure App Service - adds runtime and middleware to the provider's scope. The organisation manages only the application and data. Software as a Service (SaaS) - Salesforce, Microsoft 365, Workday - delivers complete applications; the organisation configures but does not manage the stack.

The economic logic of cloud is elasticity and unit cost reduction. AWS S3 storage costs fell approximately 90% between 2008 and 2023. On-demand compute means organisations pay for what they use rather than provisioning for peak load. For organisations with variable demand - a retailer with a Black Friday spike, a tax software provider with an April filing deadline - this economics shift alone justifies migration.

A microservices architecture structures an application as a collection of small, independently deployable services. Each service owns its own data store, exposes its functionality through a defined API, and can be developed, deployed, and scaled independently of other services. The contrast is with a monolithic architecture: a single deployable unit where all application logic is compiled and deployed together.

Jeff Bezos's API mandate at Amazon, issued in approximately 2002, is one of the most cited origin points for microservices thinking in practice. The mandate required all Amazon teams to expose their data and functionality through service interfaces with no exceptions. Teams that needed each other's data had to access it through those interfaces. Direct database access, shared memory, or any other coupling mechanism was prohibited. The mandate enforced the separation of concerns that microservices architecture depends on.

The Twelve-Factor App methodology, published by Heroku engineers in 2011, formalised the operational requirements for cloud-native microservices: explicit dependency declaration, configuration via environment variables, disposable processes, stateless services, and log streams as event streams. These twelve factors describe what a service must be to be independently deployable, scalable, and operable without manual intervention.

An Application Programming Interface (API) is a defined contract through which one software component exposes its capabilities to another. In a microservices architecture, APIs are the mechanism by which independently deployable services communicate without coupling to each other's internal implementation. The API defines what a service does; the implementation is invisible to callers.

OpenAPI 3.1, maintained by the OpenAPI Initiative and based on the Swagger specification, is the dominant standard for describing RESTful HTTP APIs. An OpenAPI document specifies every endpoint, the inputs each endpoint accepts, the outputs it produces, and the error conditions it signals. This machine-readable contract enables automated testing, client code generation, and documentation - all without the API provider and consumer teams needing to coordinate on every change.

The UK Government Digital Service (GDS) published API technical and data standards requiring government services to use RESTful APIs with OpenAPI specifications. The NHS Digital API platform, processing hundreds of millions of transactions annually by 2023, is built on these standards. The GDS standards reflect a policy recognition that API interoperability is as much a governance challenge as a technical one: without standards, organisations build APIs that only their own systems can consume.

The Internet of Things (IoT) extends digital sensing and connectivity to physical assets: machines, vehicles, buildings, and infrastructure. Edge computing processes data at or near the point of collection rather than transmitting it to a central cloud. Together, they create the data layer that enables digitalisation of physical processes that were previously analogue.

Network Rail committed to deploying over 100,000 sensors across the UK rail network by 2022 under its digital railway programme. Sensors monitor track geometry, overhead line condition, switch position, and signal state in real time. Edge processing units on each section of track analyse sensor data locally, triggering alerts before faults cause service disruption. The latency requirements - milliseconds for safety-critical signals - make central cloud processing impractical. Edge compute is not an alternative to cloud; it is a complement that handles the subset of decisions that cannot tolerate network round-trip delays.

UK mobile internet traffic exceeded desktop traffic for the first time in 2016, according to Ofcom data. For most consumer-facing digital services, the mobile device is now the primary interaction channel. Mobile-first design is the practice of designing for the most constrained context - small screen, touch interaction, variable connectivity, and battery limits - before designing for desktop. The result is interfaces that work well everywhere rather than desktop interfaces degraded for mobile.

GDS applied mobile-first principles to all UK government digital services, most visibly in the GOV.UK design system. The system mandates progressive enhancement: core functionality delivered in HTML that works without JavaScript, enhanced by CSS and JavaScript where available. This ensures that services remain accessible on low-end devices and in areas with limited connectivity - a genuine equity concern in a country where 7% of adults remain offline and many more have low-end devices.

DevOps is the combination of cultural practices, organisational structures, and tooling that enable organisations to deliver software changes rapidly and reliably. The name signals the integration of development and operations functions that were historically separate: developers who wrote code and operations engineers who ran production systems. In organisations with mature DevOps practice, the team that builds a service is also responsible for running it - creating a direct feedback loop between code quality and operational stability.

Netflix is the most cited high-watermark for DevOps at scale: thousands of production deployments per day, with automated testing and progressive rollout mechanisms ensuring that a bad deployment is detected and rolled back within minutes rather than causing sustained customer impact. Monzo, the UK digital bank, operates a similar model: new features are deployed to production multiple times per day, using feature flags to control exposure and automated circuit breakers to prevent cascading failures.

The building blocks in this module are interdependent. Microservices require APIs to communicate without coupling. APIs require consistent standards (OpenAPI) to be interoperable. Independent deployment of microservices requires cloud infrastructure for elastic provisioning. And delivering that deployment safely, at speed, requires DevOps practices: automated testing, continuous integration, and deployment pipelines that can roll back in seconds. None of these building blocks achieves its purpose in isolation.