Ercan Ermis

Sono Ercan Ermis. Ingegnere senior di piattaforma cloud nei Paesi Bassi. Scrivo qui di cloud, AWS, EKS, Terraform, osservabilità e le decisioni di platform engineering che determinano se un sistema resta in piedi alle 3 del mattino.

Come sono arrivato qui

Il primo computer della mia vita è stato un Amstrad con due lettori floppy da 5,25 pollici, Floppy A e Floppy B, comprato da mio padre nel 1986 per la sua attività. La vera storia d’amore è iniziata nel 1998, in quarta elementare, quando la mia insegnante installò Linux su una delle macchine Windows 95 nel laboratorio informatico della scuola e disse “questo è Linux, è software libero”. Poi Pac-Man è apparso su quello schermo nero e per me è stata la fine.

Perché funziona questa cosa. Come funziona davvero. Cos’altro posso farle fare. Come posso farle fare quello in modo diverso. Più di trent’anni dopo continuo a pormi queste quattro domande e sono ancora alla tastiera. Le ore davanti a un computer sono sempre state il posto in cui mi sento più a mio agio e più in pace. Il lavoro di platform engineering su questo sito è ciò che succede quando lasci girare quel ciclo di domande per qualche decennio.

I post su questo sito provengono da sistemi di produzione reali, non da slide. Calcolo del rischio bancario presso BMW Bank con requisiti di disponibilità 24/7/365. La migrazione di una piattaforma di scommesse on-prem di 16 anni su AWS con zero downtime e nessuna perdita di dati. Giochi multiplayer mobile su scala di acquisizione tramite Miniclip. Una pipeline di ingestione di streaming live che ho gestito end-to-end come unico ingegnere. Ognuna ha lasciato cicatrici, e le cicatrici diventano post.

Come lavoro

Platform Engineering, SRE e DevOps sono un unico lavoro per me, non tre. Progetto l’architettura target, scrivo il Terraform che la provisioning, costruisco la CI/CD che ci deploya sopra e rimango in reperibilità per il risultato. La divisione in ruoli separati è un organigramma; il lavoro reale è un ciclo. Scrivo dall’interno di quel ciclo.

Il bias è verso:

  • Moduli riutilizzabili e Paved Road, non infrastruttura su misura per team.
  • IAM a privilegio minimo, KMS e isolamento di rete come predefiniti, non retrofit.
  • Consapevolezza dei costi nella stessa dashboard di latenza e tasso di errore.
  • Analisi onesta dei modi di guasto. “Dovrebbe andare bene” non è un SLO.

Cosa troverai qui

La maggior parte dei post rientra in una di tre categorie:

  • AWS ed EKS in produzione. Gestire cluster, dimensionare nodegroup, pattern IAM che scalano davvero, trabocchetti di rete, upgrade del control plane senza drammi.
  • Terraform e Terragrunt a scala organizzativa. Confini dei moduli, proprietà dello stato, deriva, automazione delle revisioni, l’infrastruttura noiosa che paga interessi composti.
  • Osservabilità e affidabilità. Prometheus, Grafana, CloudWatch, log strutturati, runbook che qualcuno oltre all’autore può effettivamente seguire.

Il pubblico che ho in mente è l’ingegnere che conosce già la AWS CLI, gestisce già Kubernetes da qualche parte e vuole il dettaglio non ovvio, il trade-off o il modo di guasto che ho incontrato io così loro non devono.

Credenziali e comunità

  • UptimeCoach, un laboratorio SaaS personale distribuito su 20 regioni AWS come riferimento multi-regione funzionante.

Consulenza e advisory

Accetto un piccolo numero di incarichi di consulenza ogni anno, e mi piace davvero. La varietà di team, stack e vincoli è ciò che mantiene affilati i miei istinti di piattaforma. Il lavoro che faccio per i clienti alimenta direttamente gli scritti su questo sito, e viceversa.

Come lavoro con i team:

  • Advisory di platform engineering. Il tuo team sta raggiungendo il punto in cui “solo Terraform e speranza” smette di funzionare. Aiuto con confini dei moduli, proprietà dello stato, progettazione CI/CD, IAM a privilegio minimo e il modello operativo che trasforma la piattaforma in un prodotto, non in un centro di costo.
  • Ottimizzazione dei costi AWS. Ottimizzazione vera, non il tipo “compra Savings Plans e fine”. Esamino la tua fattura riga per riga, traccio lo spreco fino a carichi di lavoro specifici e ristrutturo. La maggior parte degli incarichi trova il 30-50% senza toccare una riga di codice applicativo.
  • Lead di piattaforma ad interim. Il tuo team è tra un lead e l’altro o sta attraversando una fase critica di crescita. Intervengo per un periodo definito, imposto la direzione tecnica, costruisco le Paved Road e aiuto ad assumere o promuovere il lead a lungo termine.
  • Migrazione e modernizzazione. Sollevare legacy su AWS, spezzare monoliti in servizi o districare un caos multi-account. Ne ho fatti abbastanza per sapere quali parti fanno male e come sequenziarle perché non lo facciano.

La superficie completa su cui faccio consulenza: AWS, architettura cloud, pipeline CI/CD, Linux, strumenti GitHub e GitLab, Terraform e Terragrunt, Kubernetes ed EKS, osservabilità, ottimizzazione dei costi, migrazione, e il modello operativo di platform engineering che tiene insieme il resto. Se gira in un account cloud di produzione o in una pipeline di build, rientra nello scopo.

Incarichi piccoli e mirati. Uno o due alla volta. Se ciò con cui hai a che fare suona come il tipo di cose di cui scrivo qui, contattami su LinkedIn. Un breve messaggio sul problema e la forma del tuo team è tutto ciò che serve per iniziare.

Da leggere dopo