Les métiers du cloud

Une seule compétence, 5 intitulés de poste différents

Vous terminez le domaine sécurité de ce cours à l'aise avec les politiques IAM et le modèle de responsabilité partagée, et vous ouvrez un site d'offres d'emploi en cherchant « cloud ». Les résultats affichent Cloud Engineer, Cloud Architect, DevOps Engineer, Site Reliability Engineer et Cloud Security Engineer, et la moitié d'entre eux listent les mêmes prérequis : AWS ou Azure, réseau, IAM, un peu de scripting. Rien ne vous dit encore lequel choisir.

Les offres ne divergent pas sur le fournisseur cloud ou les services mentionnés. Elles divergent sur 2 points : ce que vous passeriez réellement votre journée à faire, et le niveau d'autorité que vous auriez sur la conception globale. Apprenez à lire ces 2 signaux, et le site d'offres cesse de ressembler à 5 versions du même poste.

Cloud Engineer : construire et exploiter ce que l'architecture définit

Un Cloud Engineer prend un design qui existe déjà, en détail ou dans les grandes lignes, et le construit : provisionner du calcul et du stockage, câbler le réseau, écrire les scripts d'infrastructure as code vus plus tôt dans ce cours, et maintenir le système en bon état une fois lancé. C'est généralement le point d'entrée le plus courant dans le cloud, puisque le travail quotidien est concret et directement lié aux services que vous avez déjà étudiés.

Une semaine type ressemble à monter un nouveau découpage de VPC et de sous-réseaux à partir d'un ticket, déboguer pourquoi un Auto Scaling Group ne lance pas de nouvelles instances, ou modifier un script Terraform pour ajouter une réplique de lecture à une base de données. Le travail est concret et les décisions restent surtout locales : comment implémenter une partie du système, pas si le système devrait avoir cette forme en premier lieu.

Cloud Architect : concevoir le système et assumer les arbitrages

Un Cloud Architect travaille un niveau au-dessus. Au lieu d'implémenter une partie du système, l'architecte décide de ce à quoi le système entier devrait ressembler : quels services répondent à un ensemble de besoins métier, où se situent les arbitrages de redondance et de coût, et comment les pièces s'articulent. Ce poste arrive généralement après plusieurs années d'expérience en ingénierie, puisque le travail consiste à anticiper des conséquences qu'un ingénieur moins expérimenté n'a pas encore eu l'occasion de voir de ses propres yeux.

Un Cloud Architect ressemble à l'architecte d'un bâtiment. L'architecte dessine le plan, décide où placer les murs porteurs, ce qui correspond aux décisions de redondance et de montée en charge, et choisit les matériaux, ce qui dans un système cloud revient à choisir les services. Le Cloud Engineer, lui, est l'équipe du maître d'œuvre : elle coule les fondations, tire les câbles, construit exactement ce que le plan spécifie, puis maintient le bâtiment terminé en état de marche. L'analogie tient pour la séparation conception / construction, mais elle casse à un endroit : une architecture cloud continue de changer après sa mise en service, contrairement à un bâtiment achevé, si bien que le même ingénieur navigue souvent entre construction et conception à mesure que le système évolue. Les 2 rôles sont moins nettement séparés en pratique que sur un vrai chantier.

Frontière : distinguer Architect et Engineer dans une vraie offre

DevOps Engineer et Platform Engineer : traiter l'exploitation comme un problème d'ingénierie logicielle

Vous avez déjà rencontré le DevOps comme pratique plus tôt dans ce cours, la culture et l'outillage qui referment l'écart entre écrire du code et le faire tourner. DevOps Engineer, c'est cette même idée sous forme d'intitulé de poste : quelqu'un qui construit et maintient le pipeline CI/CD et l'automatisation d'infrastructure as code qui permettent aux développeurs de livrer sans remise manuelle à une équipe d'exploitation séparée. Platform Engineer est un intitulé proche, de plus en plus courant, pour la même idée sous-jacente : construire les outils internes et les chemins balisés qui permettent aux autres ingénieurs de déployer en toute sécurité par eux-mêmes.

Une tâche concrète ressemble à écrire un pipeline GitHub Actions qui exécute des tests, construit une image de conteneur, et la déploie automatiquement sur un environnement de staging à chaque merge, sans que personne ne copie de fichiers à la main sur un serveur.

Site Reliability Engineer : la même idée, tournée vers la disponibilité

Google, qui a inventé le terme, décrit directement le Site Reliability Engineering : le SRE, c'est ce qui se passe quand vous demandez à un ingénieur logiciel de concevoir une fonction d'exploitation. Un SRE passe sa journée à construire le monitoring, les alertes et la remédiation automatisée vus dans le domaine fiabilité de ce cours, les SLI et les SLO qui mesurent si un système est sain, et l'automatisation qui corrige une classe entière de panne au lieu de réparer chaque incident à la main.

Il est tentant d'entendre « SRE » et de supposer qu'il s'agit d'administration système avec un titre plus moderne. Ce n'est pas le cas. L'administration système traditionnelle répond aux problèmes à la main, un par un. Le SRE répond en écrivant du logiciel qui prévient ou corrige automatiquement toute une catégorie de problème, ce qui est un ensemble de compétences réellement différent, construit sur la programmation, pas seulement sur l'expérience d'exploitation.

Cloud Security Engineer : mettre en œuvre la part du client dans la responsabilité partagée

Un Cloud Security Engineer prend le modèle de responsabilité partagée vu plus tôt dans ce cours et le transforme en travail quotidien : écrire et auditer des politiques IAM, repérer des buckets de stockage mal configurés laissés ouverts au public, revoir les paramètres de chiffrement des données au repos et en transit, et vérifier que les contrôles de gouvernance et de conformité sont réellement appliqués, pas seulement documentés. Ce métier existe dans des organisations de toutes tailles, puisqu'une politique IAM mal configurée ou un bucket ouvert cause exactement autant de dégâts dans une startup de 3 personnes que dans une grande entreprise.

Comment les métiers s'articulent

La demande derrière ces métiers

Le Bureau of Labor Statistics américain ne suit pas directement un métier appelé « Cloud Engineer », mais sa catégorie officielle la plus proche, Computer Network Architects, projette environ 11 200 postes ouverts par an sur la prochaine décennie, portés en grande partie par l'expansion continue de la cloud computing et les refontes réseau qui l'accompagnent. Ce seul chiffre sous-estime la demande réelle, puisqu'il exclut entièrement les métiers cloud de développement, d'administration et de sécurité, mais c'est un signal utile et prudent que la tendance sous-jacente est réelle et suivie officiellement, pas seulement du marketing sectoriel.

Entrer dans le métier sans années d'expérience en production

Il est tentant de supposer que chacun de ces métiers exige des années d'expérience sur site avant qu'une entreprise ne vous considère pour un poste cloud. Les offres de niveau débutant acceptent couramment un autre type de preuve à la place : du travail en labs, des projets personnels que vous pouvez décrire en entretien, et une certification fondamentale. Rien de tout cela n'exige un emploi payé au préalable, ce qui est exactement ce que la prochaine leçon de ce sujet vous prépare à construire.

Où cela vous mène

Les 5 métiers s'appuient tous sur le même socle de calcul, stockage, réseau et IAM que vous avez construit tout au long de ce cours ; ce qui les sépare, c'est le périmètre (implémenter face à concevoir), la méthode (exploitation manuelle face à ingénierie automatisée), et le focus (construire, exploiter ou sécuriser). Connaître cette carte vous dit quelles offres correspondent réellement à ce que vous voulez faire de vos journées. La prochaine leçon passe de connaître la carte à prouver que vous savez faire le travail, grâce à de la pratique gratuite plutôt qu'à un emploi payé.