Cloud Computing Models

TheThe cloud" is not one thing — it's a spectrum of how much of the infrastructure stack a provider manages versus how much is left to the customer, and knowing where a given service sits on that spectrum is the difference between understanding a cloud bill and just paying it. A team of Berkeley researchers set out an early, influential account of what was actually new about cloud computing — elastic, pay-as-you-go access to apparently infinite computing resources, with no upfront capital commitment — at a point when the term was still being used loosely for almost anything delivered over a network¹; the service-model taxonomy below was later formalised by NIST specifically to give the industry a shared, precise vocabulary for what had until then been used inconsistently by different vendors².

IaaS, PaaS, and SaaS

Model	Provider manages	Customer manages	Example
IaaS (Infrastructure as a Service)	Physical hardware, virtualisation, networking	OS, runtime, applications, data	A raw virtual machine (AWS EC2, Azure VM)
PaaS (Platform as a Service)	Hardware, OS, runtime environment	Application code and data	A managed application runtime (Azure App Service, Google App Engine)
SaaS (Software as a Service)	Everything — the whole application	Just configuration and data entered into it	A hosted email or CRM product

MovingMoving down that table trades control for convenience: IaaS gives the most flexibility (install anything, configure anything) at the cost of managing the most yourself; SaaS gives the least flexibility but requires managing almost nothing. "AIaaS" (AI as a Service) is a looser, more marketing-driven term layered on top of this — it generally refers to PaaS- or SaaS-shaped offerings specifically for AI capabilities (a hosted model API, a managed training pipeline), rather than a formally distinct service model with its own separate management boundary.

Serverless Computing

ServerlessServerless computing (despite the name, servers still exist — they're just entirely the provider's concern) takes PaaS a step further: rather than provisioning and paying for a running application continuously, code is deployed as individual functions that the platform invokes only in response to specific triggers — an HTTP request, a file upload, a scheduled time — and billing is based on actual execution time, often down to fractions of a second, rather than on how long a server has simply been left running idle. The trade-off is cold starts: a function that hasn't run recently may need to be freshly provisioned before it can respond, adding latency to that first invocation that a continuously-running server wouldn't have. The system-level architecture choices this connects to — how services within an application are decomposed and how they communicate — are covered in full on Software Architecture Styles.

MLOps

MLOpsMLOps applies the discipline of CI/CD to the specific lifecycle of a machine-learning model, which has requirements ordinary software CI/CD wasn't built for. Code CI/CD tests whether code still behaves correctly after a change; MLOps also has to track data versioning (exactly which dataset trained which model — a model's behaviour depends on its training data just as much as its code) and model versioning (a model retrained on updated data is a genuinely different artefact from its predecessor, not just a code change, and needs its own tracked identity). A typical MLOps pipeline automates: retraining when new data arrives or performance drifts, evaluating the new model against held-out data before it's allowed to replace the current one in production, and rolling back automatically if a newly deployed model's real-world performance degrades — the same continuous-deployment discipline as ordinary software, extended to cover the fact that a model's "correctness" is statistical and can silently drift over time in a way code logic errors don't.

Choosing a Cloud AI Platform

TheThe three major public cloud providers offer broadly overlapping categories of AI service — pre-trained APIs for common tasks (vision, language, translation), managed environments for training custom models, and the underlying compute infrastructure to run either — under different names (AWS's SageMaker and Rekognition, Azure's Cognitive Services and Machine Learning, Google Cloud's Vertex AI and Vision AI). The practical choice between them, in most organisations, is driven less by any one being categorically better at a given AI task and more by which cloud already hosts the rest of the organisation's infrastructure — data-transfer costs and integration friction between clouds are real and usually outweigh small differences in any one specific API's accuracy.

References