Cloud Computing

To do anything with AWS you need an account, and Stratospheric advises anyone with a serious one to create a separate account for experiments. Its first chapter installs the command-line tool, which asks for an access key, a secret, a default region and an output format, and explains the region: AWS services are distributed across regions, each fairly isolated from the others for data residency and latency, and each with two or more availability zones so that services survive the loss of one.[4] The console, in the same book's phrase, is the cockpit for everything AWS, good for viewing resources and starting a debugging session, but it declines to set up infrastructure by hand there because manual setup is error-prone and not repeatable.[4] A book for administrators moving to DevOps in Azure says the same of the portal: fine for discovering what is possible, but use the command line and save the work in scripts.[8]

AWS CloudFormation - The Easy Way opens with the account, a tour of the console and a first EC2 instance reached over SSH, and its catalogue of services is a fair sketch of a provider's offer: EC2 for compute that boots in minutes and is paid for only while it runs, RDS for relational databases with six engines, Elastic Load Balancing, Route 53 for DNS and IAM for identity.[5] The Azure equivalent is a lab-building guide from the MVPDays authors, which creates a free account and then a Windows Server virtual machine in the portal, choosing a size that supports nested virtualisation, premium disks and a static public address.[7]

Every provider gives a customer a private network inside its public one. AWS CloudFormation - The Easy Way describes Amazon's virtual private cloud (VPC) as a logically isolated section of AWS in which you choose an address range and create subnets, route tables and gateways: a public subnet for web servers and a private one for databases with no internet access, security groups and access control lists as layers of protection, and the option of a VPN from the corporate data centre so the cloud becomes an extension of it.[5] Stratospheric builds exactly that: a VPC with the range 10.0.0.0/16, one public subnet made public by an internet gateway, a route table and route, and security groups and roles for the container service, noting that production would use at least two subnets in different availability zones.[4]

On Azure the lab guide gives one virtual machine several public addresses, with address translation through Windows routing and the network security group.[7] Connecting an office network to the cloud is its own small genre: one MVPDays book repeats the same Azure site-to-site VPN setup against a Sophos UTM, a Cisco Meraki, a Palo Alto firewall and Microsoft's routing service, a chapter each,[26] and a Terraform primer for Azure ends on a virtual network and a security group rule.[27] Seeing the traffic afterwards is the subject of a cookbook for VMware's network monitoring product, with chapters on adding AWS and Azure as data sources.[42] Even an HTTP/3 book has deployment sections on cloud provider security groups, load balancer affinity and content delivery networks.[25]

The first unit of cloud compute was the rented virtual machine: AWS CloudFormation - The Easy Way's application stack is a load balancer, a launch configuration, an auto scaling group and a scaling policy, the classic pattern for a fleet of identical servers that grows and shrinks with demand.[5] The second is the container. Stratospheric packages a Spring Boot application as a Docker image and runs it on Amazon's Elastic Container Service (ECS), where a service runs some number of copies of a task backed by an image, keeps that many alive, restarts any that fail health checks and replaces old versions in a rolling deployment.[4] The third is the function, which has a section below.

Cloud Strategy begins from the disappointment that follows a naive migration: lifting and shifting legacy applications is unlikely to bring the anticipated benefits, re-architecting them can be cost prohibitive, and the full rewards need changes to the business model and the organisation, so an enterprise needs a more nuanced strategy than "cloud first".[1] It warns that transporting existing processes to the cloud earns an organisation a new data centre but not a cloud.[1] Its first chapter argues that corporate IT is structured around buying components, that the cloud is not another component but the backbone where data, software, security and analytics all live, and that the nearest precedent is a major ERP system, where installing the software was easy and the organisational change was both the hardest part and the source of the benefit.[1]

Building Software Platforms brings a tool to the same decisions: Wardley maps, diagrams with a value chain axis from less to more visible to the user and an evolution axis from uncharted to industrialised, on which positioning the elements of a business shows where it stands and the paths forward; its author holds that building in-house is right for whatever is core to the business, and that the examples use AWS because of that provider's timing.[3] A field guide to Microsoft's cloud ERP shows the question from the software side, with chapters on the product on premises versus in the cloud and on migrating to the cloud.[44] The DevOps-in-Azure book is blunter: the cloud "pours gas on the fire" of DevOps through its lack of hardware and its automation-driven, API-first environment.[8]

Most enterprises run hybrid estates for years, and the Microsoft-centred books are largely about the seams. A guide to moving on-premises Exchange to Office 365 is written as the redeployment document of a real migration, and its first chapter is an inventory of what hybrid means: supported Exchange versions and roles, Active Directory synchronisation, certificates for federation, and tables of the ports and endpoints a hybrid identity deployment needs; later chapters install Azure AD Connect and deploy federation services.[18] A Windows Server 2019 migration lab threads Azure through an on-premises upgrade with Azure File Sync for older files, moving a WordPress site to Azure, and appendices on Azure Backup, update management and Site Recovery.[45] The backup guide from the same authors ends with backing up to Azure,[20] and the virtual machine manager guide with connecting the on-premises product to an Azure subscription.[19]

Management tooling crosses the boundary both ways. A PowerShell conference anthology has a chapter on extending Azure Update Management beyond Azure,[22] and the handbook for the third version of Desired State Configuration explains that the engine's local configuration manager was decoupled so that vendors and internal teams could build their own orchestrators, which is how Azure Automation State Configuration and the agent reporting to Azure Policy came to exist.[12]

A recurring use of the cloud in the Windows books is as a place to run a lab without buying hardware. The MVPDays guides run on one Azure virtual machine with nested Hyper-V inside it: the lab-building book argues that the whole lab then costs one VM plus its public addresses,[7] and the System Center guides list that host, a DS8 Azure VM, in their lab tables and route the nested machines to the internet through a router VM.[19][20]

The Kubernetes books make the opposite choice for the same reason. One is deliberately local-first, building clusters on a laptop with Kind so the reader learns without a cloud bill, with one late chapter mapping the material onto DigitalOcean, Amazon EKS and Google GKE;[41] another runs every lab on Kind while noting that Kubernetes runs on AWS, Google Cloud and Azure.[40] The cloud reaches back into on-premises estates too: the first case in a Windows Server troubleshooting book is a 2017 ticket in which servers rebooted mysteriously, traced through event log entries to a cloud patching service.[21]

The Pulumi Book sorts the tools into two families. Configuration management tools such as Ansible, Chef, Puppet and SaltStack manage the software and settings of a computer that already exists, standing in for what an administrator would do at the command line; provisioning tools such as Terraform, CloudFormation, the AWS CDK and Pulumi create cloud infrastructure from scratch through the provider's API, standing in for the console.[6] Both share two principles, that the code is declarative, saying what the infrastructure should be rather than how to build it, and that operations are idempotent, giving the same result however often they run; both therefore need state, a snapshot of what exists as of the last successful run.[6]

Learn Terraform The Hard Way draws the same line from the other side: where Chef, Puppet and Ansible manage from within the system, through an agent or over SSH, Terraform manages from outside through a remote API, and the difference shows as soon as the resources are load balancers, private networks and fleets of machines.[10] Its first exercise is deliberately local, a resource that writes a file, used to introduce the cycle of initialising a module, reading the plan that compares desired state with what Terraform believes exists, approving the apply and inspecting the state file.[10]

CloudFormation is AWS's own provisioning service. AWS CloudFormation - The Easy Way explains it as writing a template that describes all the resources you want, after which the service provisions them and works out what depends on what, and the template can be reused in several regions; the book builds a multi-tier WordPress site as three stacks, for IAM, the network and the application, covers stack policies that protect resources from updates, and ends with reference appendices on intrinsic functions and helper scripts.[5]

Stratospheric gives the feel of a template. A stack is CloudFormation's unit of work; a template names a format version, dated 2010 and unchanged since, and a Resources section in which each resource has a type and properties; dependencies are resolved automatically, so a VPC is created before its subnet and deleted after it; Parameters take inputs and Outputs export values that other stacks import by name.[4] Having walked through more than two hundred lines of YAML, the book promises the Cloud Development Kit (CDK), which describes the same infrastructure in Java.[4] A Kubernetes book uses CloudFormation for the parts of a cluster the cloud owns, with templates for the VPC, the EKS cluster and its node group applied through Ansible.[35]

Terraform is the provider-neutral provisioner. In Learn Terraform The Hard Way the move from local files to the cloud is a provider stanza with AWS access keys and a single VPC resource, with a note that providers exist for Azure, GitHub, Kubernetes and much else.[10] The Azure primer covers the same first steps for that provider, from the concepts to authenticating with the Azure command line or a service principal and a storage account to hold the state.[27] Two study guides track HashiCorp's certifications, one following the Associate exam's objectives,[33] the other the Authoring and Operations Professional exam in an Azure edition.[34]

Pulumi's difference is the language. Where most tools have you declare resources in static JSON or YAML, which grows awkward as soon as you want three servers in production and one in test, Pulumi programs are written in TypeScript, Python, Go, Java, C# or other general-purpose languages, with loops, functions, packages and unit tests, and by default it keeps state in a hosted service.[6] Its guiding principle, borrowed from Perl's creator, is that easy things should be easy and hard things possible, and its first walkthrough is a single-page website on S3.[6]

Configuration management predates the cloud and still runs much of it. Ansible for DevOps opens its first chapter on snowflake servers and the shell scripts that grew up to tame them, and most of its worked examples run on local virtual machines, with cloud providers in later chapters.[11] In the Microsoft world the equivalent is PowerShell: a textbook on professional PowerShell has an infrastructure-as-code chapter whose example modules create an Azure SQL server, a storage account, a load balancer and a virtual machine,[23] and the conference anthology includes automating an Azure Sentinel deployment and Azure DevOps for small operations teams.[22] Desired State Configuration was rewritten for its third version as a standalone engine whose source is mostly Rust, with the configuration manager decoupled so that any orchestrator can drive it.[12]

GitOps makes a Git repository the source of truth for what is deployed. A short introduction explains the environment repository, push-based against pull-based deployments, preview environments, and how GitOps relates to DevOps, NoOps and what it calls CIOps, before a quickstart with the Flux operator on Kubernetes driven by GitHub Actions.[36] Stratospheric builds towards a fully automated continuous deployment pipeline from the one-command deployment of its first chapter.[4]

A Java microservices book explains the problem containers solve: applications share a machine's operating system and libraries with everything else on it, so a necessary update can break them, and a container is an isolated partition inside a single operating system that gives developers a predictable environment and virtualises processor, memory, storage and network at the operating-system level.[14] Stratospheric's Dockerfile is four lines, and the image is pushed to Docker Hub before the cloud sees it, with Amazon's own registry introduced later.[4] The two Docker books go deeper into the engine: one through images, Compose, Swarm, networking, volumes and security, with a 2025 edition adding local language models and WebAssembly workloads,[37] the other beneath Docker to containerd, runC, namespaces and control groups.[38] A short ASP.NET Core book runs two services in a Docker Swarm, chosen for brevity over Kubernetes.[13]

A small book on operators gives the clearest short account of Kubernetes: an open-source platform from Google for scheduling workloads on a cluster, whose basic unit is the Pod, originally one or more Docker containers with an allotment of processor, memory, network and disk, better understood as a workload scheduler or a distributed kernel composed of controllers each driving some resource to a desired state; custom resource definitions, added in versions 1.7 and 1.8, let users write controllers of their own.[15] An introduction built around a Drupal site takes a reader from container runtimes through deploying, scaling and rolling back to Helm, Ingress and autoscaling.[39]

The cloud enters where the cluster comes from. A book on Ansible and Kubernetes builds an Amazon EKS cluster with CloudFormation in one chapter and a Google GKE cluster with Terraform in another.[35] The Azure DevOps book rebuilds a monolith on Azure Kubernetes Service,[8] and a deep learning book grows its serving layer with Kubernetes on the way to a managed pipeline.[24] Amazon's ECS, as Stratospheric uses it, is the alternative for managed containers without Kubernetes.[4]

Site reliability engineering, the practice that began at Google and treats operations as a software engineering problem, supplies the vocabulary of the operations chapters: the service level objective a service promises its users, and the error budget it leaves to spend on change until it runs out. Stratospheric's third part is the AWS side of the job: CloudWatch logging and why unstructured text falls short, metrics, alarms created with the CDK, and synthetic monitoring with canaries.[4] The Azure DevOps book monitors with Azure Monitor and Application Insights,[8] and the serverless books cover retrieving logs and adding deployment alerts.[31] Scale brings its own material: a book of lessons from a fictional big-tech company covers HTTP traffic shaping, multi-region failover and operating through chaos,[43] and a data platform book treats continuous delivery, monitoring, disaster recovery and the management of alpha, beta and production environments as one subject.[9]

The Certified Cloud Security Professional syllabus, as one exam reference follows it, organises cloud security into six domains: concepts, architecture and design; data security; platform and infrastructure security; application security; security operations; and legal, risk and compliance.[29] Identity is the thread through the practical books. Stratospheric's first deployment needs a capability flag to let a stack create IAM roles, and its services list includes Cognito for user registration and login and Secrets Manager;[4] AWS CloudFormation - The Easy Way's first stack is the IAM stack of roles, profiles and policies;[5] the Lambda books insist on least-privilege roles[30] and on running with restricted user accounts.[31]

Secrets are the other thread. A guide to HashiCorp Vault opens with the Equifax, British Airways and Marriott breaches and the argument, quoted from an industry report, that the new perimeter is the data itself and the users who access it; its description of Vault is a description of the cloud secrets problem, systems and their operators both needing database credentials and API keys and the difficulty being who has access and auditing it, and its answer includes dynamic secrets, so that an application needing an S3 bucket receives an AWS key pair generated on demand and revoked when its lease expires.[17] The Pulumi Book builds secrets management into the provisioning tool,[6] the Azure DevOps book uses Key Vault,[8] and the startup checklist has items on securing access through cloud providers and container environments and reviewing the security of SaaS providers.[47] On the Microsoft side a lab book tests Defender Advanced Threat Protection on Windows Server with simulated ransomware and fileless attacks.[46]

Paying by the hour, the request or the gigabyte is the cloud's defining economic feature, and it cuts both ways. Cloud Strategy lists per-second billing among the cloud's attractions and argues in its budgeting part that elastic pricing and automation can significantly reduce operational cost, but only for an organisation willing to leave past assumptions behind.[1] AWS CloudFormation - The Easy Way repeats the provider's own case: no up-front purchase, payment only while a virtual server runs, and a claimed saving of up to 80 percent against the equivalent on-premises deployment.[5] Running Serverless shows how far pricing reaches into design, devoting its opening to the ways request pricing shapes architecture, security and product decisions.[31] A data platform book makes balancing performance against cost, so a company does not burn its cash running the software side of the business, one of its framing questions, and names analytics costs, tiered storage and time-to-live settings as the levers.[9] The Pulumi Book gives the practical reason idempotency matters: a tool that forgot its state would create new machines on every run and rack up charges.[6]

Every cloud service is a distributed system, and Distributed Systems for practitioners supplies the vocabulary. A distributed system is one whose components sit on different networked computers and coordinate by passing messages; the reasons to build one are performance at lower cost, scalability, and availability, where five nines means five minutes of downtime a year and is reached through redundancy.[16] The fallacies of distributed computing, collected at Sun Microsystems, are the assumptions that break in the cloud: that the network is reliable, that latency is zero, that a remote call is like a local one, when libraries such as gRPC and Thrift hide a difference of several orders of magnitude between a memory access and a call across a network.[16] The data science course puts eventual consistency, the CAP theorem and Amdahl's law in its chapter on distributed computing.[28]

Platform Strategy observes that nearly every large cloud customer its author advised was building an in-house platform, often several, and that building on a commercial cloud raises questions with no settled answers: which functions belong in the in-house platform and which in the cloud's, what happens when the cloud launches a feature that supersedes yours, who owns the services the platform provisions.[2] Its first part explains the amplifier effect that makes platforms attractive, from the marketplace flywheel of eBay, Uber and Airbnb to the way operating systems and clouds hide complexity, and warns that many platform initiatives consume multi-year investments only to be obsolete or unwanted by launch; its last part is about the platform team.[2]

Building Software Platforms is the engineering counterpart: an internal platform built on managed cloud services, serverless first, that relieves developers of running software so they can deliver value, with services running "with" the platform rather than "on" it to ward off layered architectures.[3] On Azure the platform is partly bought: the DevOps book's second part runs through continuous integration with GitHub and Azure DevOps, continuous delivery, monitoring, and then containers, Kubernetes and serverless.[8]

Data platforms are where cloud cost and performance meet most directly. The Architectural Blueprints for Building Business Optimized Data Platforms follows one car-search platform from a monolithic web application to a distributed system processing data from hundreds of sources, framing each step as a business trade-off; its case study replicates fields from an RDS database into OpenSearch for autocomplete and searches under two hundred milliseconds, and its scaling chapters move to microservices with DynamoDB and tiered storage for cost.[9] The data science course covers cloud storage types, key-value and graph databases, the BigQuery and Redshift warehouses, and the managed machine learning services SageMaker, Azure ML Studio and Google AutoML.[28] A deep learning book takes a model from research code to a production service with cloud training, distributed training, Kubernetes, and MLOps pipelines with TFX, Vertex AI and Google Cloud.[24] The ERP field guide has become a book about cloud AI as well, with chapters on Copilot and agents in its latest edition.[44]

The newest books add AI to the picture: Platform Strategy has a chapter on platforms for AI,[2] and the current Docker book runs language models locally with a model runner.[37]