Pourquoi cet article ?
Je m'appelle Mustafa. Je suis développeur sur une application Java legacy — Tomcat, Apache, Jenkins, Gradle. Le genre de stack où tu passes tes journées à débugger des problèmes de cookies, des certificats SSL, et des pipelines Jenkins capricieux.
J'aime ce que je fais. Mais j'ai réalisé un truc : les parties de mon boulot que je préfère, ce n'est pas le code Java. C'est le déploiement, l'automatisation, le debugging d'infrastructure. Quand je passe une journée à écrire un Dockerfile, à configurer un pipeline CI/CD, ou à diagnostiquer pourquoi le serveur refuse de démarrer — c'est là que je suis dans mon élément.
Alors j'ai décidé de devenir ingénieur DevOps. Et de documenter chaque étape du parcours ici, sur Dev.to.
Aujourd'hui, c'est le Jour 0 : pas de code, pas d'outil. Juste comprendre le terrain de jeu.
C'est quoi le cloud, concrètement ?
Avant de plonger dans AWS, Terraform et Kubernetes, il faut répondre à une question toute bête : pourquoi le cloud existe ?
Le problème (que je vis tous les jours)
Au boulot, quand on a besoin d'un nouveau serveur, voilà ce qui se passe :
- On fait une demande
- On attend que quelqu'un le provisionne
- On le configure à la main (ou presque)
- S'il tombe en panne un vendredi soir, c'est la galère
Et si on a besoin de 3 environnements identiques (dev, staging, prod) ? On recommence 3 fois. Et si la config diverge entre les environnements ? Bon courage pour débugger le fameux "ça marche sur mon poste".
La solution cloud
Le cloud, c'est simple : tu loues des ressources informatiques à la demande, et tu paies ce que tu consommes.
L'analogie qui m'a aidé à comprendre :
Tu ne construis pas ta propre centrale électrique pour alimenter ta maison. Tu branches ta prise et tu paies EDF. Le cloud, c'est pareil — mais pour les serveurs, le réseau et le stockage.
Tu veux un serveur ? Tu cliques (ou tu tapes une commande), et en 30 secondes il existe. Tu n'en as plus besoin ? Tu le supprimes et tu arrêtes de payer. Pas de matériel à gérer, pas de datacenter à refroidir.
Les 3 géants du cloud
| Provider | Entreprise | Part de marché | Ce qu'il faut retenir |
|---|---|---|---|
| AWS | Amazon | ~31% | Le leader, le plus d'offres d'emploi en France |
| Azure | Microsoft | ~25% | Très présent dans les grandes entreprises et ESN |
| GCP | ~11% | Fort en data et machine learning |
J'ai choisi de commencer par AWS pour une raison pragmatique : c'est celui qui revient le plus souvent dans les offres DevOps en Île-de-France. Mais les concepts sont les mêmes partout — et les outils comme Terraform fonctionnent avec les trois.
Les 5 services AWS que je vais utiliser
AWS a des centaines de services. C'est terrifiant au début. Mais la réalité, c'est que 90% des DevOps en utilisent moins de 20. Et pour mon premier projet, j'en ai besoin de seulement 5.
Voici comment je les ai compris en les comparant à ce que je connais déjà :
| Service AWS | En une phrase | Mon équivalent actuel |
|---|---|---|
| EC2 | Un serveur virtuel | Mon serveur de qualif au boulot, mais créé en 30 secondes |
| VPC | Un réseau privé dans le cloud | Le réseau interne de ma boîte, avec ses sous-réseaux |
| RDS | Une base de données managée | Ma base PostgreSQL, mais AWS gère les backups et mises à jour |
| S3 | Du stockage de fichiers illimité | Un disque dur géant accessible de partout via une URL |
| IAM | La gestion des droits et accès | Les users Linux + sudo, mais en version cloud avancée |
Le truc rassurant : ce ne sont pas des concepts nouveaux. Ce sont les mêmes briques que je manipule déjà — serveurs, réseau, stockage, droits — mais dans un autre emballage.
Et pourquoi "Infrastructure as Code" ?
Dernière pièce du puzzle. AWS a une interface web (la "console") où tu peux tout créer en cliquant. Alors pourquoi s'embêter à écrire du code ?
Imagine ce scénario :
- Tu crées un serveur en cliquant dans la console
- 3 mois plus tard, un collègue te demande : "c'est quoi la config exacte ?"
- Tu fouilles dans l'interface... et tu ne retrouves plus tous les réglages
- Tu dois recréer la même chose pour un autre client — tu recommences tout à la main
Maintenant imagine l'alternative :
# main.tf — mon serveur en 5 lignes
resource "aws_instance" "web" {
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t3.micro"
tags = {
Name = "mon-premier-serveur"
}
}
Ce fichier texte est ta documentation. Il est dans Git, versionné, relu en code review. Tu veux le même serveur pour un autre client ? terraform apply. Tu veux 10 serveurs ? Tu changes un chiffre. Tu veux revenir en arrière ? git revert.
C'est exactement le même principe que Docker : au lieu de configurer un serveur à la main, tu écris un Dockerfile. L'Infrastructure as Code, c'est pareil mais pour tout le reste — le réseau, les bases de données, les droits d'accès, le load balancer...
Si tu viens du monde Java/Jenkins comme moi, pense-y comme ça : le Jenkinsfile a remplacé la configuration manuelle des jobs Jenkins. Terraform, c'est le Jenkinsfile de ton infrastructure cloud.
Ce que j'ai fait aujourd'hui
✅ Créé mon compte AWS Free Tier (gratuit pendant 12 mois sur plein de services)
✅ Choisi la région eu-west-3 (Paris) — le datacenter le plus proche
✅ Activé le MFA sur mon compte root (première règle de sécurité cloud)
✅ Fait un tour dans la console AWS — c'est impressionnant le nombre de services, mais je ne me laisse pas intimider
Prochaine étape
Dans le prochain article, j'installe Terraform sur ma machine et je crée mon tout premier serveur EC2 — en code. Mon premier terraform apply. J'ai hâte de voir ce que ça donne.
Si tu es dans la même situation que moi — dev qui veut évoluer vers le DevOps — suis cette série. On apprend ensemble, étape par étape.
Cet article fait partie de la série *"De Dev à DevOps — Mon parcours"*. Chaque article correspond à une leçon pratique avec du vrai code et un vrai projet portfolio à la clé.
Tu as des questions ou des conseils ? Je suis preneur en commentaires !
Top comments (0)