Ercan Ermis

Je suis Ercan Ermis. Ingenieur senior en plateforme cloud aux Pays-Bas. J’ecris ici sur le cloud, AWS, EKS, Terraform, l’observabilite et les decisions d’ingenierie de plateforme qui determinent si un systeme reste operationnel a 3 h du matin.

Comment j’en suis arrive la

Le premier ordinateur de ma vie etait un Amstrad avec deux lecteurs de disquettes 5,25 pouces, Floppy A et Floppy B, achete par mon pere en 1986 pour son entreprise. Le declic reel s’est produit en 1998, en quatrieme annee, quand mon enseignant a installe Linux sur une des machines Windows 95 du laboratoire informatique de l’ecole et a dit “ca c’est Linux, c’est du logiciel libre”. Puis Pac-Man est apparu sur cet ecran noir et c’etait fini pour moi.

Pourquoi cette chose fonctionne. Comment fonctionne-t-elle vraiment. Que puis-je lui faire faire d’autre. Comment lui faire faire ca differemment. Plus de trente ans plus tard, je pose toujours ces quatre questions et je suis toujours au clavier. Les heures devant un ordinateur ont toujours ete l’endroit ou je me sens le plus a l’aise et le plus en paix. Le travail de platform engineering sur ce site est ce qui arrive quand on laisse cette boucle de questions tourner pendant quelques decennies.

Les articles de ce site proviennent de systemes de production reels, pas de slides. Le calcul du risque bancaire chez BMW Bank avec une exigence de disponibilite 24/7/365. La migration d’une plateforme de paris on-prem de 16 ans vers AWS avec zero temps d’arret et zero perte de donnees. Des jeux mobiles multijoueurs a l’echelle d’acquisition via Miniclip. Un pipeline d’ingestion de streaming live que j’ai gere de bout en bout en tant que seul ingenieur. Chacune de ces experiences a laisse des cicatrices, et les cicatrices deviennent des articles.

Comment je travaille

Platform Engineering, SRE et DevOps sont un seul metier pour moi, pas trois. Je concois l’architecture cible, j’ecris le Terraform qui la provisionne, je construis le CI/CD qui deploie dessus, et je reste sur le pager pour le resultat. La separation en roles distincts est un organigramme ; le travail reel est une boucle. J’ecris depuis l’interieur de cette boucle.

Le parti pris est pour :

  • Des modules reutilisables et des Paved Roads, pas de l’infrastructure sur mesure par equipe.
  • IAM a moindre privilege, KMS et isolation reseau par defaut, pas en rattrapage.
  • La conscience des couts sur le meme tableau de bord que la latence et le taux d’erreur.
  • Une analyse honnete des modes de defaillance. “Ca devrait aller” n’est pas un SLO.

Ce que vous trouverez ici

La plupart des articles tombent dans l’une de trois categories :

  • AWS et EKS en production. Operer des clusters, dimensionner des nodegroups, des patterns IAM qui passent vraiment a l’echelle, les pieges reseau, les montees de version du plan de controle sans panique.
  • Terraform et Terragrunt a l’echelle de l’organisation. Limites de modules, propriete de l’etat, derive, automatisation de revue, l’infrastructure ennuyeuse qui rapporte des interets composes.
  • Observabilite et fiabilite. Prometheus, Grafana, CloudWatch, logs structures, des runbooks que quelqu’un d’autre que l’auteur peut reellement suivre.

Le public que j’ai en tete est l’ingenieur qui connait deja la CLI AWS, fait deja tourner Kubernetes quelque part, et veut le detail non-evident, le compromis ou le mode de defaillance que j’ai rencontre pour qu’il n’ait pas a le faire.

Credentials et communaute

  • UptimeCoach, un laboratoire SaaS personnel provisionne sur 20 regions AWS comme reference multi-region operationnelle.

Conseil et advisory

Je prends un petit nombre de missions de conseil chaque annee, et j’apprecie vraiment cela. La variete des equipes, des stacks et des contraintes est ce qui garde mes propres instincts de plateforme affutes. Le travail que je fais pour les clients alimente directement les ecrits sur ce site, et vice versa.

Comment je travaille avec les equipes :

  • Advisory en ingénierie de plateforme. Votre equipe atteint le point ou “juste Terraform et on espere” cesse de fonctionner. J’aide avec les limites de modules, la propriete de l’etat, la conception CI/CD, l’IAM a moindre privilege et le modele operatif qui transforme la plateforme en produit, pas en centre de couts.
  • Optimisation des couts AWS. De la vraie optimisation, pas le genre “achetez des Savings Plans et c’est bon”. Je passe en revue votre facture ligne par ligne, trace le gaspillage jusqu’aux charges specifiques et restructure. La plupart des missions trouvent 30 a 50% sans toucher une ligne de code applicatif.
  • Lead plateforme interim. Votre equipe est entre deux leads ou traverse une phase de croissance critique. J’interviens pour une periode definie, je fixe la direction technique, je construis les Paved Roads et je vous aide a recruter ou promouvoir le lead permanent.
  • Migration et modernisation. Migrer du legacy sur AWS, diviser des monolithes en services ou demeler un chaos multi-comptes. J’en ai fait assez pour savoir quelles parties font mal et comment les sequencer pour qu’elles ne fassent pas mal.

La surface complete sur laquelle je conseille : AWS, architecture cloud, pipelines CI/CD, Linux, outillage GitHub et GitLab, Terraform et Terragrunt, Kubernetes et EKS, observabilite, optimisation des couts, migration, et le modele operatif de platform engineering qui tient le reste ensemble. Si ca tourne dans un compte cloud de production ou dans un pipeline de build, c’est dans le perimetre.

Des missions courtes et ciblees. Une ou deux a la fois. Si ce a quoi vous faites face ressemble au genre de choses sur lesquelles j’ecris ici, contactez-moi sur LinkedIn. Un court message sur le probleme et la forme de votre equipe suffit pour demarrer.

A lire ensuite