Ercan Ermis

Ich bin Ercan Ermis. Senior Cloud Platform Engineer in den Niederlanden. Ich schreibe hier uber Cloud, AWS, EKS, Terraform, Observability und die Plattformentscheidungen, die daruber entscheiden, ob ein System um 3 Uhr nachts lauft.

Wie ich hier gelandet bin

Der erste Computer in meinem Leben war ein Amstrad mit zwei 5,25-Zoll-Diskettenlaufwerken, Floppy A und Floppy B, den mein Vater 1986 fur sein Geschaft gekauft hat. Der eigentliche Schalter wurde 1998 umgelegt, in der vierten Klasse, als mein Lehrer Linux auf einem der Windows-95-Rechner im Schulcomputerraum installierte und sagte: “Das ist Linux, das ist freie Software.” Dann erschien Pac-Man auf diesem schwarzen Bildschirm und es war um mich geschehen.

Warum funktioniert dieses Ding. Wie funktioniert es eigentlich. Was kann ich sonst noch damit machen. Mehr als dreissig Jahre spater stelle ich immer noch dieselben Fragen und sitze immer noch an der Tastatur. Stunden vor einem Computer waren immer der Ort, an dem ich mich am wohlsten und am ruhigsten fuhle. Die Platform-Engineering-Arbeit auf dieser Seite ist das, was passiert, wenn diese Frage-Schleife ein paar Jahrzehnte lang lauft.

Die Beitrage auf dieser Seite stammen aus echten Produktionssystemen, nicht aus Folien. Bankrisikoberechnung bei BMW Bank mit 24/7/365-Verfugbarkeitsanforderung. Die Migration einer 16 Jahre alten On-Prem-Wettplattform auf AWS ohne Ausfallzeit und ohne Datenverlust. Multiplayer-Mobilespiele im Akquisitionsmassstab uber Miniclip. Eine Live-Streaming-Ingest-Pipeline, die ich als einziger Ingenieur von Ende zu Ende betrieben habe. Jede dieser Erfahrungen hat Narben hinterlassen, und die Narben werden zu Beitragen.

Wie ich arbeite

Platform Engineering, SRE und DevOps sind fur mich ein Job, nicht drei. Ich entwerfe die Zielarchitektur, schreibe das Terraform, das sie provisioniert, baue die CI/CD, die darauf deployt, und bleibe auf dem Pager fur das Ergebnis. Die Aufteilung in getrennte Rollen ist ein Organigramm; die eigentliche Arbeit ist eine Schleife. Ich schreibe aus dem Inneren dieser Schleife.

Die Ausrichtung:

  • Wiederverwendbare Module und Paved Roads, nicht massgeschneiderte Infrastruktur pro Team.
  • Least-Privilege-IAM, KMS und Netzwerkisolation als Standard, nicht als nachtragliche Erganzung.
  • Kostenbewusstsein im selben Dashboard wie Latenz und Fehlerrate.
  • Ehrliche Fehlermodus-Analyse. “Sollte okay sein” ist kein SLO.

Was Sie hier finden

Die meisten Beitrage fallen in eine von drei Kategorien:

  • AWS und EKS in Produktion. Cluster betreiben, Nodegroups dimensionieren, IAM-Muster die tatsachlich skalieren, Netzwerk-Fallstricke, Control-Plane-Upgrades ohne Drama.
  • Terraform und Terragrunt im Organisationsmassstab. Modulgrenzen, State-Eigentum, Drift, Review-Automatisierung, die langweilige Infrastruktur die Zinseszins zahlt.
  • Observability und Zuverlassigkeit. Prometheus, Grafana, CloudWatch, strukturierte Logs, Runbooks denen jemand anderes als der Autor tatsachlich folgen kann.

Die Zielgruppe, die ich im Kopf habe, ist der Ingenieur, der bereits die AWS-CLI kennt, bereits Kubernetes irgendwo betreibt und den nicht-offensichtlichen Teil, den Kompromiss oder den Fehlermodus will, auf den ich gestossen bin, damit sie es nicht mussen.

Qualifikationen und Community

  • UptimeCoach, ein personliches SaaS-Labor, das uber 20 AWS-Regionen als funktionierende Multi-Region-Referenz bereitgestellt wird.

Beratung und Advisory

Ich nehme jedes Jahr eine kleine Anzahl von Beratungsauftragen an, und ich mag das wirklich. Die Vielfalt an Teams, Stacks und Randbedingungen halt meine eigenen Plattform-Instinkte scharf. Die Arbeit, die ich fur Kunden mache, fliesst direkt in die Texte auf dieser Seite ein und umgekehrt.

Wie ich mit Teams arbeite:

  • Platform Engineering Advisory. Ihr Team erreicht den Punkt, an dem “einfach Terraform und hoffen” nicht mehr funktioniert. Ich helfe bei Modulgrenzen, State-Verantwortung, CI/CD-Design, Least-Privilege-IAM und dem Betriebsmodell, das Plattform zum Produkt macht, nicht zur Kostenstelle.
  • AWS-Kostenoptimierung. Echte Optimierung, nicht die “Savings Plans kaufen und fertig”-Variante. Ich gehe Ihre Rechnung Zeile fur Zeile durch, verfolge die Verschwendung zu spezifischen Workloads und strukturiere um. Die meisten Engagements finden 30-50%, ohne eine Zeile Anwendungscode anzufassen.
  • Interim Platform Lead. Ihr Team ist zwischen Leads oder durchlauft eine kritische Wachstumsphase. Ich komme fur einen festgelegten Zeitraum, setze die technische Richtung, baue die Paved Roads und helfe Ihnen, den langfristigen Lead einzustellen oder zu befordern.
  • Migration und Modernisierung. Legacy auf AWS heben, Monolithen in Services zerlegen oder ein Multi-Account-Chaos entwirren. Ich habe genug davon gemacht, um zu wissen, welche Teile wehtun und wie man sie sequenziert, damit sie es nicht tun.

Die volle Bandbreite, zu der ich berate: AWS, Cloud-Architektur, CI/CD-Pipelines, Linux, GitHub- und GitLab-Tooling, Terraform und Terragrunt, Kubernetes und EKS, Observability, Kostenoptimierung, Migration und das Platform-Engineering-Betriebsmodell, das den Rest zusammenhalt. Wenn es in einem produktiven Cloud-Account oder in einer Build-Pipeline lauft, ist es im Umfang.

Kleine, fokussierte Engagements. Eins oder zwei gleichzeitig. Wenn das, womit Sie sich beschaftigen, nach den Themen klingt, uber die ich hier schreibe, erreichen Sie mich auf LinkedIn. Eine kurze Nachricht zum Problem und zur Teamstruktur genugt fur den Start.

Weiterlesen