Konrad Kowalski (rootsher)Principal Platform & Reliability Architect101101101100101000001100100001010000001011110101

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.

mTLS

posts (1)

2025-03-11
Introduction to Service Mesh: Why Istio and Linkerd Exist
Service mesh appeared because, in a microservice system, traffic, identity, and observability problems started repeating in every service.
DevOps / Networking

mTLS

posts (1)

Introduction to Service Mesh: Why Istio and Linkerd Exist