How cloud costs actually accumulate, how to reason about compute choices, and how the industry got to where it is today.
The twelve-factor app is a set of principles for building cloud-native applications, published by developers at Heroku, covering configuration, dependencies, and process design; more than a decade later, most of its core ideas — like strict separation of config from code, and treating processes as stateless and disposable — remain standard practice, even as the specific platform assumptions behind a few of the original factors have shifted.
A message queue lets a service hand off work without waiting for it to be processed immediately, decoupling producer and consumer in time as well as in code; publish-subscribe extends this to many independent consumers reacting to the same event, and event-driven architecture built on these patterns trades the simplicity of direct, synchronous calls for resilience to temporary failures and independent scalability, at the cost of harder-to-trace, eventually-consistent behavior.
Spot instances sell a cloud provider's unused compute capacity at a steep discount compared to on-demand pricing, in exchange for the provider being able to reclaim that capacity with little notice when it's needed elsewhere; the discount is real and substantial, but it's only a good trade for workloads that can actually tolerate interruption, which rules out plenty of applications by design.
A monolith deploys as a single unit and keeps components in-process, which is simple to develop and operate at small scale but couples every part's deployment and scaling together; microservices split an application into independently deployable services, gaining independent scaling and deployment at the cost of network calls between components that were previously simple in-process function calls, and all the distributed-systems complexity that comes with it.
A service mesh is a dedicated infrastructure layer, typically implemented as sidecar proxies alongside each service instance, that handles service-to-service traffic management, security, and observability — moving that logic out of application code and into infrastructure; it solves a real problem for organizations running many interdependent microservices, and adds real operational complexity that isn't worth it for simpler architectures.
The CAP theorem proves that a distributed data system can't simultaneously guarantee consistency, availability, and partition tolerance; because network partitions are a real possibility that has to be tolerated, the actual choice every distributed database makes is between consistency and availability specifically during a partition, not a free choice among all three properties at once.
Replication keeps multiple copies of the same data on different nodes, providing redundancy and the ability to scale read traffic across replicas; sharding splits a dataset across multiple nodes so no single node holds all of it, which is what allows write throughput and total data volume to scale beyond what any one machine can handle — and most large-scale systems eventually need both, for different reasons.
Cloud computing's core idea — computing as a metered, shared utility — predates the term by decades; the modern industry traces to Amazon Web Services launching S3 and EC2 in 2006, followed by Google and Microsoft's competing platforms, then a second wave built on Docker containers (2013) and Kubernetes orchestration (2014), which gave rise to today's infrastructure-as-code and CI/CD practices.
Virtual machines offer the most control and the slowest startup, billed for uptime; containers package an application with its dependencies for fast, portable startup, typically orchestrated with Kubernetes; serverless functions remove server management entirely, scale to zero, and bill per invocation — and the right choice depends on how a workload's traffic and control needs actually behave, not which model is newest.
Cloud bills tend to grow out of control for a handful of recurring, well-understood reasons — unused ('zombie') resources, data transfer charges, oversized instances, and a lack of cost visibility — and cost allocation tagging is the main mechanism that turns an opaque total bill into spend attributable to specific teams and projects.