Ercan Ermis

I’m Ercan Ermis. Senior cloud platform engineer based in the Netherlands. I write here about cloud, AWS, EKS, Terraform, observability, and the platform-engineering decisions that decide whether a system stays up at 3 AM.

How I got here

The first computer in my life was an Amstrad with two 5.25-inch floppy drives, Floppy A and Floppy B, bought by my father in 1986 for his business. The real switch flipped in 1998, fourth grade, when my teacher installed Linux on one of the Windows 95 machines in our school computer lab and said “this is Linux, it is free software.” Then Pac-Man appeared on that black screen and I was done.

Why does this thing work. How does it actually work. What else can I make it do. More than thirty years later I am still asking those questions and still at the keyboard. Hours in front of a computer have always been the place I feel most comfortable and most at peace. The platform-engineering work on this site is what happens when you let that question loop run for a few decades.

The posts on this site come from real production systems, not slides. Banking risk computation at BMW Bank with a 24/7/365 availability requirement. The migration of a 16-year-old on-prem betting platform onto AWS with zero downtime and no data loss. Multiplayer mobile games running at acquisition scale through Miniclip. A live-streaming ingest pipeline I owned end-to-end as the only engineer. Each of those left scars and the scars become posts.

How I work

Platform Engineering, SRE, and DevOps are one job for me, not three. I design the target architecture, write the Terraform that provisions it, build the CI/CD that deploys onto it, and stay on the pager for the result. The split into separate roles is an org chart; the actual work is one loop. I write from inside that loop.

The bias is toward:

  • Reusable modules and paved roads, not bespoke per-team infrastructure.
  • Least-privilege IAM, KMS, and network isolation as defaults, not retrofits.
  • Cost awareness on the same dashboard as latency and error rate.
  • Honest failure-mode analysis. “Should be fine” is not an SLO.

What you will find here

Most posts fall into one of three buckets:

  • AWS and EKS in production. Operating clusters, sizing nodegroups, IAM patterns that actually scale, networking gotchas, control-plane upgrades without drama.
  • Terraform and Terragrunt at organization scale. Module boundaries, state ownership, drift, review automation, the boring infrastructure that pays compound interest.
  • Observability and reliability. Prometheus, Grafana, CloudWatch, structured logs, runbooks that someone other than the author can actually follow.

The audience I have in mind is the engineer who already knows the AWS CLI, already runs Kubernetes somewhere, and wants the non-obvious bit, the trade-off, or the failure mode I hit so they do not.

Credentials and community

Projects

  • UptimeCoach, Personal SaaS lab for global uptime monitoring, provisioned across 20 AWS regions as a working multi-region reference architecture.
  • news.ercan.ai, Curated AI news, link drops, and opinionated bulletins in short form.
  • awsmonthly.cloud, Monthly AWS news magazine. Digest-style roundup of what shipped, what changed, and what matters. (Coming soon, haven’t had time yet.)

Consulting and advisory

I take on a small number of consulting engagements each year, and I genuinely enjoy it. The variety of teams, stacks, and constraints is what keeps my own platform instincts sharp. The work I do for clients directly feeds the writing on this site, and vice versa.

How I work with teams:

  • Platform engineering advisory. Your team is hitting the point where “just Terraform and hope” stops working. I help with module boundaries, state ownership, CI/CD design, least-privilege IAM, and the operating model that turns platform into a product, not a cost center.
  • AWS cost optimization. Real optimization, not the “buy Savings Plans and call it done” variety. I go through your bill line by line, trace the waste to specific workloads, and restructure. Most engagements find 30-50% without touching a line of application code.
  • Interim platform lead. Your team is between leads or growing through a critical phase. I step in for a fixed period, set the technical direction, build the paved roads, and help you hire or promote the long-term lead.
  • Migration and modernization. Lifting legacy into AWS, breaking monoliths into services, or untangling a multi-account mess. I have done enough of these to know which parts hurt and how to sequence them so they do not.

The full surface I consult on: AWS, cloud architecture, CI/CD pipelines, Linux, GitHub and GitLab tooling, Terraform and Terragrunt, Kubernetes and EKS, observability, cost optimization, migration, and the platform-engineering operating model that holds the rest together. If it runs in a production cloud account or in a build pipeline, it is in scope.

These are small, focused engagements. One or two running at a time. If what you are dealing with sounds like the kind of thing I write about here, reach me on LinkedIn. A short message about the problem and the shape of your team is all we need to start.

Read this next