Konrad Kowalski (rootsher)Principal Platform & Reliability Architect010011011000110010101110100001111110000010110101

categories

roleESC ×

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.

Shadow traffic

posts (1)

2025-12-02Deployment Strategies: Why They Exist6/6
Shadow Traffic: Testing Without Responding to the User
Shadow traffic sends a copy of a request to the new version, but the user receives the old version's response. It tests behavior without taking over traffic.
DevOps / CI/CD

Shadow traffic

posts (1)

Shadow Traffic: Testing Without Responding to the User