---
title: "15 — Operations and Cloud — From Linux to Serverless"
uid: operations-and-cloud
tags: ["devops", "roadmap:software-architect", "ci-cd", "serverless", "cloud", "containers", "service-mesh", "cloud-design-patterns", "linux", "infrastructure-as-code"]
excerpt: "Modern operations is a sequence of abstractions — reproducible (IaC), packaged (containers), automated (CI/CD), abstracted (cloud/serverless) — each layer building on the one below."
date: 2026-08-13T03:27:39+0000
source: https://www.aveshina.my.id/en/blog/operations-and-cloud
---

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].

```figure
<svg viewBox="0 0 680 270" xmlns="http://www.w3.org/2000/svg" class="my-6 w-full max-w-2xl" role="img" aria-label="Virtual machine versus container. Left: a VM stack — each VM has its own guest OS, running one app, on a hypervisor on a host OS. Right: a container stack — multiple containers share one host OS kernel, each running an app, lighter and faster.">
  <g font-family="ui-sans-serif, system-ui, sans-serif" text-rendering="geometricPrecision">
    <!-- VM -->
    <text x="170" y="28" font-size="13" font-weight="700" fill="#134e4a" text-anchor="middle">Virtual Machine</text>
    <rect x="40" y="44" width="260" height="200" rx="8" fill="#ccfbf1" stroke="#0d9488" stroke-width="1.5"/>
    <g font-size="10" fill="#134e4a" text-anchor="middle">
      <rect x="56" y="56" width="110" height="50" rx="5" fill="white" stroke="#0d9488"/>
      <text x="111" y="76">App A</text>
      <text x="111" y="92">Guest OS</text>
      <rect x="180" y="56" width="110" height="50" rx="5" fill="white" stroke="#0d9488"/>
      <text x="235" y="76">App B</text>
      <text x="235" y="92">Guest OS</text>
      <rect x="56" y="116" width="234" height="28" rx="5" fill="#a7f3d0" stroke="#0d9488"/>
      <text x="173" y="134">Hypervisor</text>
      <rect x="56" y="154" width="234" height="28" rx="5" fill="#5eead4" stroke="#0d9488"/>
      <text x="173" y="172">Host OS</text>
      <rect x="56" y="192" width="234" height="28" rx="5" fill="#2dd4bf" stroke="#0d9488"/>
      <text x="173" y="210">Infrastructure</text>
      <text x="173" y="236" font-style="italic" fill="#0f766e">heavy: full guest OS per app</text>
    </g>

    <!-- Container -->
    <text x="510" y="28" font-size="13" font-weight="700" fill="#1e1b4b" text-anchor="middle">Container</text>
    <rect x="380" y="44" width="260" height="200" rx="8" fill="#e0e7ff" stroke="#6366f1" stroke-width="1.5"/>
    <g font-size="10" fill="#1e1b4b" text-anchor="middle">
      <rect x="396" y="56" width="70" height="50" rx="5" fill="white" stroke="#6366f1"/>
      <text x="431" y="76">App A</text>
      <text x="431" y="92">bins/libs</text>
      <rect x="476" y="56" width="70" height="50" rx="5" fill="white" stroke="#6366f1"/>
      <text x="511" y="76">App B</text>
      <text x="511" y="92">bins/libs</text>
      <rect x="556" y="56" width="70" height="50" rx="5" fill="white" stroke="#6366f1"/>
      <text x="591" y="76">App C</text>
      <text x="591" y="92">bins/libs</text>
      <rect x="396" y="116" width="234" height="28" rx="5" fill="#c7d2fe" stroke="#6366f1"/>
      <text x="513" y="134">Container runtime</text>
      <rect x="396" y="154" width="234" height="28" rx="5" fill="#a5b4fc" stroke="#6366f1"/>
      <text x="513" y="172">Host OS (shared kernel)</text>
      <rect x="396" y="192" width="234" height="28" rx="5" fill="#818cf8" stroke="#6366f1"/>
      <text x="513" y="210">Infrastructure</text>
      <text x="513" y="236" font-style="italic" fill="#3730a3">light: shared kernel, portable image</text>
    </g>
  </g>
</svg>
```

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](https://roadmap.sh/software-architect/operations-knowledge)

[2] "Linux / Unix," roadmap.sh — Software Architect. [Online]. Available: [https://roadmap.sh/software-architect/linux--unix](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](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](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/](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](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/](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](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/](https://learn.microsoft.com/en-us/azure/architecture/patterns/)

```quiz
Q: What does Infrastructure as Code primarily buy an architect?
- Faster runtime execution of application code
- Reproducibility and consistency — the same definition produces the same environment every time
correct: 1
explain: IaC defines infrastructure in versioned, machine-readable files so environments are reproducible and reviewable, eliminating drift and "works on my machine" problems.

Q: Why are containers smaller and faster than virtual machines?
- Containers run on specialized container hardware
- Containers share the host kernel and only package the app plus its bins/libs, instead of a full guest OS
correct: 1
explain: Containers use cgroups, namespaces, and chroot to isolate a process that shares the host kernel. VMs each carry a full guest OS, which is far heavier.

Q: What's the difference between continuous delivery and continuous deployment?
- They are the same thing
- Continuous delivery keeps code always release-ready; continuous deployment automatically releases every change that passes tests
correct: 1
explain: Delivery means every change is release-ready (a human decides when to release). Deployment automates that last step — every passing change goes to production.

Q: A service mesh earns its complexity when…
- the project has a single service
- there are many services and cross-cutting concerns (retry, circuit breaking, mTLS, observability) between them
correct: 1
explain: A service mesh handles service-to-service communication concerns consistently across a topology of services. With only a few services, libraries in each are simpler; the mesh pays off at scale.

Q: Serverless abstracts away what from the developer's concern?
- The application's business logic
- Server provisioning, maintenance, and scaling — developers package code and the provider runs it
correct: 1
explain: Serverless removes server management: the provider handles provisioning, scaling, and maintenance. The trade-offs are cold-start latency, vendor APIs, and harder local testing.
```