Guide du développeur pour créer des applications sans supporter la charge de l'infrastructure

La plupart des développeurs d'applications consacrent beaucoup de temps à des tâches qui n'ont rien à voir avec la création de fonctionnalités. Le sprint 0 disparaît dans les fichiers Jenkins et les configurations Terraform. Les nouveaux environnements nécessitent des tickets à plusieurs équipes et une attente d'une à deux semaines. Les mises à niveau du runtime se transforment en projets de plusieurs mois.

Il s'agit là d'une taxe sur l'infrastructure, qui s'accumule. Chaque heure passée à déboguer les autorisations IAM ou à attendre la mise en place de l'environnement est une heure qui n'est pas consacrée au produit. Les outils conçus pour les spécialistes de l'infrastructure (Terraform, Kubernetes, configurations cloud brutes) sont devenus la norme pour les développeurs d'applications qui n'ont jamais signé pour ce travail.

Il existe une distinction plus claire entre ce qui relève de la responsabilité des développeurs et ce qui devrait être automatisé. Une distinction claire entre ces deux aspects modifie la manière dont les équipes planifient, construisent et livrent.

Que signifie réellement « ne pas porter le fardeau de l'infrastructure » ?

Soyons clairs sur ce que nous ne suggérons pas : abandonner toutes les connaissances en matière d'infrastructure ou prétendre que le déploiement n'a pas d'importance. L'objectif est de séparer ce dont vous avez besoin de la manière dont cela est provisionné.

L'infrastructure doit être une dépendance de votre application, comme n'importe quelle autre dépendance dans votre base de code. Vous déclarez ce dont vous avez besoin (une base de données PostgreSQL, un cache Redis, un runtime Node.js) et la plateforme s'occupe du reste. Au-delà du contrat entre le code de votre application et une dépendance, vous ne devriez pas avoir à vous soucier du fonctionnement de cette dépendance.

En pratique, cela signifie que vous n'avez plus besoin d'écrire des modules Terraform pour provisionner des bases de données gérées. Vous n'avez plus besoin de déboguer Kubernetes YAML lorsque votre pod ne se planifie pas. Vous n'avez plus besoin de passer de votre IDE aux consoles des fournisseurs de cloud pour comprendre pourquoi les autorisations IAM bloquent votre déploiement.

Vous écrivez du code. Vous le poussez vers Git. Votre application s'exécute.

Abstraction de l'infrastructure : ce que les développeurs doivent garder sous contrôle

Tout ne doit pas être abstrait. Certaines décisions relatives à l'infrastructure ont une incidence directe sur le comportement de votre application, et celles-ci relèvent de la responsabilité de l'équipe de développement.

• Les décisions relatives à l'architecture de l'application restent les vôtres. Votre application peut-elle fonctionner correctement dans une configuration à plusieurs nœuds ? Gère-t-elle correctement la mise à l'échelle horizontale ? Ces questions nécessitent une bonne compréhension de votre code, et non de votre fournisseur de cloud.
• Le choix des services vous appartient. Vous savez si votre charge de travail nécessite PostgreSQL ou MySQL, si Redis est adapté à votre stratégie de mise en cache et si Elasticsearch répond à vos besoins en matière de recherche. La plateforme doit rendre ces services disponibles instantanément, mais le choix vous appartient.
• Les exigences en matière de performances relèvent de votre domaine. De combien de CPU et de mémoire votre application a-t-elle besoin ? Quels sont les temps de réponse attendus par vos utilisateurs ? Vous comprenez mieux ces contraintes que n'importe quelle équipe d'infrastructure.
• La logique métier et le flux de données restent évidemment votre prérogative. La manière dont votre application traite les demandes, stocke les données et gère les erreurs est au cœur du travail de développement.

Ce qui doit être abstrait

Tout le reste. Plus précisément, tout ce qui nécessite des connaissances spécialisées en infrastructure, mais qui ne modifie pas le fonctionnement du code de votre application.

• La mise à disposition de l'environnement ne doit pas occuper tout votre Sprint 0. Lorsqu'une plateforme gère cela automatiquement, vous passez de la validation du code à la mise en place d'un environnement opérationnel en quelques minutes au lieu de plusieurs jours ou semaines. Chaque branche Git peut générer un environnement complet avec la même configuration, les mêmes services, le même routage et les mêmes données de production facultatives.
• La configuration du réseau et du routage doit être invisible. Les certificats TLS, l'équilibrage de charge, la gestion DNS et la découverte de services peuvent tous être gérés par la plateforme. Vous ne devriez pas avoir besoin de comprendre les VPC ou les groupes de sécurité pour déployer une application web.
• Les mises à jour du runtime et des services ne devraient pas être des projets qui durent des mois. En tant que développeur, vous ne devriez pas vous soucier des versions secondaires de votre runtime ou de votre service. Vous ne devriez pas avoir à vous occuper de leur mise à jour, car ce n'est pas votre priorité. Votre priorité devrait être de créer de la valeur ajoutée ou de maintenir votre application.
• En matière de sécurité des infrastructures, les garde-fous devraient remplacer entièrement la prise de décision. Systèmes de fichiers de production en lecture seule, certificats TLS automatisés, isolation stricte des environnements : ces éléments devraient être intégrés, et non configurés.

Comment la réduction des frais généraux liés à l'infrastructure modifie la vitesse de développement

Lorsque vous supprimez l'infrastructure de votre chemin critique, le développement s'accélère.

• Les boucles de rétroaction plus rapides deviennent la norme. Lorsque la création d'un environnement de test ne prend que quelques secondes au lieu de remplir des tickets, vous effectuez des tests plus fréquemment. Vous détectez les problèmes plus tôt. Vous livrez avec plus de confiance.
• Les branches de fonctionnalités deviennent de véritables environnements. Chaque branche que vous poussez peut devenir un environnement totalement indépendant, avec votre code d'application, une copie de votre base de données et tous les services associés. Son URL générée automatiquement peut être envoyée aux parties prenantes ou aux systèmes CI. À chaque fois, vous vous demandez vraiment « à quoi ressemblerait mon site si je fusionnais cela avec la production ? ».
• La planification des sprints change. Sans le travail d'infrastructure du Sprint 0, vous commencez à créer des fonctionnalités dès le premier jour. Sans les retards liés à la mise à disposition de l'environnement, vous n'avez plus besoin de gonfler les estimations avec le « temps d'infrastructure ». Vous planifiez en fonction de la complexité du développement, et non des frais généraux opérationnels.
• Les astreintes deviennent moins stressantes. Lorsque l'infrastructure est prévisible et que les retours en arrière sont fiables, vous dormez mieux. Sérieusement.

Craintes courantes liées à l'abandon du contrôle de bas niveau

Les équipes hésitent souvent à adopter des environnements standardisés, car elles craignent de perdre en flexibilité. Abordons les préoccupations les plus courantes.

• « Et si j'ai besoin d'une configuration personnalisée ? » Standardisé ne signifie pas rigide. Une plateforme bien conçue expose la configuration là où elle est importante (allocation des ressources, sélection des services, variables d'environnement, etc.) tout en masquant la complexité là où elle ne l'est pas (réseau, IAM, mécanismes de mise à l'échelle).
• « Qu'en est-il de l'enfermement propriétaire ? » Le code de votre application ne change pas. Vos schémas de base de données restent les mêmes. Vos API restent identiques. La portabilité qui compte, celle de votre application réelle, reste portable.
• « Comment puis-je déboguer les problèmes de production ? » Probablement mieux que vous ne le faites actuellement. Lorsque tous les environnements sont identiques (même configuration, mêmes services, même structure de données), les problèmes de débogage « ça marche sur ma machine » disparaissent. Des clones en production complète en quelques minutes vous permettent de tester dans des conditions réelles sans toucher aux systèmes en direct.
• « Qu'en est-il des exigences de conformité et de sécurité ? » La conformité intégrée (SOC 2, ISO 27001, PCI-DSS) dépasse souvent ce que les équipes obtiennent avec des configurations DIY. Lorsque la sécurité est intégrée à la plateforme, vous en héritez automatiquement.

Ce qui permet d'avoir confiance lorsque l'infrastructure est automatisée

La confiance vient de la prévisibilité. Lorsque vous comprenez exactement ce qui va se passer à chaque déploiement, la peur diminue.

• Git devient la seule source de vérité. La configuration de votre infrastructure coexiste avec votre code dans un simple fichier YAML. Les modifications de l'infrastructure passent par des pull requests avec le même processus de révision que les modifications de code. Chaque déploiement est déterministe et basé sur les commits Git. La restauration signifie revenir en arrière sur les commits.
• Stabilité de la configuration dans le temps. L'un des défis de Terraform réside dans les mises à niveau de version et les changements de syntaxe entre les versions. La mise à niveau de Terraform représente souvent un travail considérable. Avec des plateformes standardisées, un fichier de configuration datant de plusieurs années fonctionne toujours aujourd'hui.
• La parité des environnements est garantie. La même configuration est déployée en développement, en préproduction et en production. Les différences spécifiques à chaque environnement sont gérées par des variables, et non par des configurations différentes. Il n'y a tout simplement pas de dérive entre les environnements.

Pour commencer

Pour aller de l'avant, vous n'avez pas besoin de réécrire votre application ni d'abandonner tout ce que vous savez. Commencez par un projet non critique. Créez un fichier de configuration simple. Envoyez-le à Git. Regardez votre application se déployer.

Lorsque vous constaterez à quel point cette boucle de rétroaction peut être rapide, lorsque vous ferez l'expérience de la création d'un environnement complet à partir d'une branche en quelques secondes, le fardeau de l'infrastructure commencera à vous sembler un problème qui appartient au passé.

Vous êtes devenu développeur pour créer des choses. Il est temps de revenir à cela.

En savoir plus

• Qu'est-ce que Upsun ?
  Comprenez les concepts fondamentaux qui sous-tendent l'infrastructure pilotée par Git et comment Upsun simplifie la complexité opérationnelle.
• Infrastructure basée sur Git : pourquoi la configuration en tant que code est préférable au déploiement par simple clic.
  Examinez plus en détail pourquoi les déploiements basés sur YAML sont plus performants que le provisionnement manuel pour les applications maintenables et évolutives.
• Configurez votre environnement de développement local.
  Connectez votre processus local à Upsun à l'aide de tunnels DDEV ou SSH pour itérer plus rapidement sans avoir à pousser chaque modification.
• Interface de ligne de commande (CLI)
  Gérez vos projets, environnements et déploiements directement depuis votre terminal avec la CLI Upsun.
• Gérez les environnements Upsun.
  Apprenez à créer, brancher, synchroniser et fusionner des environnements liés à votre processus Git.