Konrad Kowalski (rootsher)Principal Platform & Reliability Architect010100100110001100001111000111000000000000011111

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.

Gateway API Without the Magic

date: 2024-10-15
category: Networking
also in: Containers
reading: 1 min / 154 words

Ingress looked like a standard until the real standard became nginx.ingress.kubernetes.io/* annotations.

That is the starting point for this series.

Not:

text

Gateway API is new, so let's learn it

But:

text

why did a simple HTTP routing API end up as a mix of Kubernetes YAML and controller-specific configuration?

The series has four parts.

The first one follows the line from Service through Ingress to Gateway API. Not Kubernetes museum work. Just enough history to see why Ingress had no clean place for production behavior.

The second one splits the word gateway apart. API gateway, ingress gateway, mesh gateway, and Kubernetes Gateway API are not interchangeable terms.

The third one is about GatewayClass. That is where the abstraction meets a real controller, which makes it a platform decision.

The fourth one gets practical about migrating from ingress-nginx: what can move into the standard API, what remains implementation-specific, what should not be carried over silently, and how to test next to the old controller.

We start with the problem Gateway API tries to name better than Ingress: from Service to Gateway API.