15 — Operations and Cloud — From Linux to Serverless

IaC, containers, CI/CD, cloud, serverless, service mesh — the operations sprawl organized itself when I saw the ladder. The model that organized it: modern operations is a sequence of abstractions — making infrastructure reproducible (IaC), packaged (containers), automated (CI/CD), and abstracted (cloud/serverless) [1]. Each layer builds on the one below it, and the architect's job is knowing which layer a given operational concern lives at.

Operational knowledge is the understanding architects need to design, implement, and manage systems through their lifecycle — deployment, maintenance, efficiency, reliability, security [1].

The foundation: Linux

Underneath everything sits Linux/Unix. Knowledge of UNIX is a must for almost all development because most code is finally deployed on a UNIX/Linux machine [2]. Linux has been the backbone of the free and open-source movement, providing a simple and elegant operating system for almost every need. The architect-relevant skills are the shell, file permissions, process management, networking utilities, and enough systemd to read a service failure. This is the floor; everything above it assumes it.

Reproducible: infrastructure as code

Infrastructure as Code (IaC) manages servers, networks, and other infrastructure through machine-readable configuration files instead of manual setup [3]. Tools like Terraform or CloudFormation let teams version, review, and repeat infrastructure changes just like application code. The architect's win is consistency and reproducibility across development, testing, and production — the same definition produces the same environment, every time, with no "but it works on my machine" drift. IaC is what makes it sane to tear down and recreate environments, which is what makes modern deployment practices possible.

Abstracted: cloud providers

Cloud providers offer a layer of APIs to abstract infrastructure and provision it based on security and billing boundaries [4]. The cloud still runs on servers in data centers, but the abstractions give the appearance of interacting with a single platform. The ability to quickly provision, configure, and secure resources has been key to both the success and the complexity of modern DevOps [4]. The architect's relationship to the cloud is mostly about the service catalog — knowing which managed service fits which workload, and the cost and lock-in implications of each choice.

Packaged: containers

Containers are a construct that uses cgroups, namespaces, and chroot to fully encapsulate and isolate a process [5]. The encapsulated process (a container image) shares the host kernel with other containers, making containers significantly smaller and faster than virtual machines. Container images are designed for portability — full local testing of a static image, and easy deployment to a container-management platform [5].

The portability is the architect's main win — the same image that passed tests is the one that runs in production, eliminating a whole class of environment-mismatch bugs.

Automated: CI/CD

CI/CD is a method to frequently deliver apps by introducing automation into the stages of development [6]. The three concepts are continuous integration (merging code frequently, with automated builds and tests), continuous delivery (keeping the code always release-ready), and continuous deployment (automatically releasing every change that passes tests). CI/CD is the solution to the integration problems that new code causes for development and operations teams — historically called "integration hell" [6]. The architect's interest is the pipeline shape: what gates a change must pass (build, test, security scan, deploy) before it reaches production.

Abstracted further: serverless

Serverless is a cloud-native model where developers build and run applications without managing servers [7]. There are still servers, but they're abstracted away — the provider handles provisioning, maintenance, and scaling, and developers package code (often in containers) for deployment. The trade-off is freedom from operations against cold-start latency, vendor-specific APIs, and harder local testing. Serverless pushes the abstraction sequence to its logical end: the architect thinks in functions and events, not machines.

Coordination: service mesh

A service mesh is a dedicated infrastructure layer for handling service-to-service communication in a cloud-native application, responsible for the reliable delivery of requests through the complex topology of services [8]. In practical terms, it's a tool that controls how services communicate — adding retry, circuit-breaking, mTLS, and observability between services without that logic living in application code. The trade-off is operational complexity (another system to run) against consistent cross-cutting communication concerns. A service mesh earns its keep in a large microservices deployment; in a handful of services it's overhead.

Patterns: cloud design patterns

Cloud design patterns are the catalog of proven approaches for building reliable, scalable, secure applications in the cloud [9]. Each pattern describes the problem it addresses, considerations for applying it, and an example implementation. Most patterns are relevant to any distributed system, whether on Azure or elsewhere — patterns like retry, circuit breaker, backpressure, sidecar, and throttling. The architect uses them as a vocabulary for recurring distributed-systems problems, the same way the Gang-of-Four patterns serve object-oriented design.

How I use this

I layer the abstractions deliberately. Linux is the floor I assume. IaC is non-negotiable for any environment beyond a laptop — if infrastructure isn't in version control, it isn't reproducible and it will drift. Containers are my default packaging unit for services because of the portability and test-to-prod parity. CI/CD is the pipeline that turns a commit into a deployed container, with gates sized to the risk. Cloud and serverless are choices about how much operations to hand to a provider — I reach for managed services aggressively when they remove undifferentiated work, and I reach for serverless when the workload is bursty or event-shaped. A service mesh I add only when the number of services makes cross-cutting communication concerns painful; before that, libraries in each service are simpler. Cloud design patterns I use as a checklist when designing anything distributed — most production incidents map to a pattern someone ignored.

References

[1] "Operations Knowledge," roadmap.sh — Software Architect. [Online]. Available: https://roadmap.sh/software-architect/operations-knowledge

[2] "Linux / Unix," roadmap.sh — Software Architect. [Online]. Available: https://roadmap.sh/software-architect/linux--unix

[3] Red Hat, "What is Infrastructure as Code," [Online]. Available: https://www.redhat.com/en/topics/automation/what-is-infrastructure-as-code-iac

[4] Red Hat, "What are Cloud Providers?," [Online]. Available: https://www.redhat.com/en/topics/cloud-computing/what-are-cloud-providers

[5] Docker, "What is a Container?," [Online]. Available: https://www.docker.com/resources/what-container/

[6] Red Hat, "What is CI/CD?," [Online]. Available: https://www.redhat.com/en/topics/devops/what-is-ci-cd

[7] Cloudflare, "What is Serverless Computing?," [Online]. Available: https://www.cloudflare.com/learning/serverless/what-is-serverless/

[8] Red Hat, "What is a Service Mesh?," [Online]. Available: https://www.redhat.com/en/topics/microservices/what-is-a-service-mesh

[9] Microsoft, "Cloud Design Patterns," Azure Architecture Center. [Online]. Available: https://learn.microsoft.com/en-us/azure/architecture/patterns/