Konrad Kowalski (rootsher)Principal Platform & Reliability Architect011010101110111101010111110011101011101001101111

categories

Principal Platform & Reliability Architect

One at a time - the areas this role is made of, and what falls to it in each.

01
Automation and DevOps cultureInfrastructure as Code
Promoting Infrastructure as Code (IaC, e.g. Terraform) over clicking through a console, packaging services as Helm charts and shipping them to Kubernetes the GitOps way - ArgoCD keeps the cluster in step with the repository, so a deployment is a merged branch. Automating the CI/CD pipelines takes repetitive manual work - toil - off the team.
02
SRE standards and observabilitySLI / SLO
Rolling out observability - being able to answer “what just happened” without logging into a server: Prometheus and Grafana for metrics and alerting, New Relic as the APM with logs, request traces, response times and bottlenecks in one place, OpenTelemetry as vendor-neutral instrumentation, Sentry for application errors. Setting the stability numbers on top of it: SLI (Service Level Indicators) and SLO (Service Level Objectives).
03
Strategy and leadershipThe IC track
Setting the technical direction of the whole company together with the business, the CTO and fellow architects - “Principal” is a senior expert position at director level, but with no direct reports (the IC, Individual Contributor, track). This person does not sit in client meetings: the work points inward - hold the team together, clear the blockers out of its way, make sure it never lacks tooling, access or a decision.
04
Platform architectureInternal Developer Platforms
Designing and running the platform every service in the company stands on: the Kubernetes cluster, networking, secrets, permissions, deployments and the cloud underneath (AWS, Azure, GCP). A team gets a ready environment and a single command to ship with, not a server to configure.
05
Platform securitySecurity by default
Building security into the platform instead of bolting it on with an audit at the end: secrets in Vault and never in the repository, access granted by least privilege, service-to-service traffic routed through a service mesh (Istio, Linkerd) - with mTLS encryption and policies for who may talk to whom - and images and dependencies scanned in the pipeline. A vulnerability is then fixed by a deployment, not by a ticket.
06
Reliability and scalabilityResiliency
Defining how systems withstand failure (resiliency) and designing them to absorb sudden traffic spikes, recover on their own (self-healing) and meet demanding availability targets - an SLA of 99.99%, for instance.

Deployment Strategies: Why They Exist

date: 2025-04-08
category: CI/CD
also in: Reliability Engineering
reading: 1 min / 280 words

The simplest deployment once looked like this:

text

stop the old version
put the new version in place
start it

That works if the application can disappear for a while.

It stops working when the system serves traffic all the time, has multiple instances, queues, a database, mobile clients, and users who do not know that a "deployment window" is happening.

Deployment strategies exist for one reason:

text

changing a version is risk

Different strategies control different parts of that risk.

Build, release, and deploy are not the same

It helps to split three words.

text

build
  an artifact is created

deploy
  the artifact reaches an environment

release
  users receive new behavior

In a simple world, all three happen together.

In a larger system, separating them gives control.

You can deploy code without enabling a feature.

You can send only a small part of traffic to a new version.

You can keep two environments ready and switch routing.

You can copy traffic to a new version without showing its response to the user.

What this series covers

This series does not start with Argo Rollouts, Flagger, or a cloud product.

First, the mechanisms need names.

Rolling update replaces instances gradually.

Blue-green keeps two versions and switches traffic.

Canary gives the new version a small percentage of real traffic.

Targeted rollout chooses specific users, rings, or segments.

Feature flags separate deploy from release.

Shadow traffic tests a new version with copied traffic.

Each article follows the same shape:

text

why it appeared
what it really means
minimal example
where it works
where the name lies

Minimal stack

The examples stay as small as possible.

The base is Kubernetes:

text

Deployment
Service
readinessProbe
Gateway API HTTPRoute
ConfigMap or env var

Not because every organization must deploy this way.

Because these primitives make the mechanism visible.

If you understand the mechanism, the tool is only an implementation.

If you do not understand the mechanism, the tool gives you a nicer panel for the same mistake.

We start with the strategy Kubernetes gives you by default: rolling update.