This is Chapter 1 of the System Design series. Architecture reviews and design discussions keep coming back to the same vocabulary regardless of what’s being built. I keep this list so I’m reasoning from consistent definitions each time, not re-deriving the same trade-offs from scratch. Core concepts Systems Always Lose Consistency - CAP Is Fundamental Scalability Availability Latency Consistency CAP Idempotency Fault tolerance 1. Scalability Vertical scaling (bigger machine) buys time but hits a ceiling fast and creates a single point of failure. Horizontal scaling (more machines) is the default for anything expected to grow past a single box, at the cost of needing to handle state, coordination, and partial failure across nodes. 2. Availability Usually expressed in nines: ...

The Kubernetes Fundamentals domain in my KCNA study notes assumes container runtime knowledge going in - Docker, in practice, since it’s still the most common way people get there. The Kubernetes Fundamentals series is the companion to this post, one level up the stack. Prerequisites WSL2 with Ubuntu on Windows, or native Linux/macOS sudo access on the machine you’re installing on A Docker Hub account if you want to push images Installing Docker On WSL2/Ubuntu, install Docker Engine directly rather than Docker Desktop - run this from your home directory in the WSL2 shell: ...

This is Chapter 1 of the DevSecOps Guardrails series. I wired cdk-nag in as the first guardrail in this series because it is CDK-native: it runs against the construct tree at synth time and blocks the build on any rule violation - before a changeset is created, before any AWS API call is made. It sees the construct level, not just the synthesised template, which means it can catch things cfn-lint cannot. ...

This is Chapter 5 of the Infrastructure as Code with AWS CDK series. The same cdk deploy command that runs locally works in any pipeline - the differences are auth and orchestration. Common flags for CI These apply regardless of which CI system you use: cdk synth # generate CloudFormation template cdk deploy --require-approval never -c env=prod # deploy without interactive prompts cdk deploy --outputs-file outputs.json # write stack outputs to file --require-approval never skips the IAM change confirmation that CDK shows interactively. Required in CI. ...

This is Chapter 4 of the Infrastructure as Code with AWS CDK series. Chapter 3 built FileProcessorConstruct - the tests here cover that construct and the stack it lives in. How CDK testing works CDK unit tests don’t deploy anything. They synthesize a stack into a CloudFormation template and run assertions against that template. No AWS credentials needed, and the suite runs in CI without any special setup. The aws_cdk.assertions module is already part of aws-cdk-lib - no extra install required. ...