Petit historique du déploiement d'applications

Créer des applications, c'est génial. Si seulement on pouvait se contenter de ça plutôt que de se prendre la tête avec tout le processus pour les mettre en service, pas vrai ? Je dis souvent que les applications, c'est comme les avions : une fois qu'elles sont en vol, il y a de fortes chances que, si tu les as bien conçues, elles continuent de fonctionner sans accroc. C'est au décollage et à l'atterrissage qu'on rencontre généralement des problèmes — autrement dit, lors du déploiement.

Dans cet article, je vais te présenter un bref historique de la façon dont on déployait les applications autrefois, en examinant ce qui a changé, ce qui a bien fonctionné et ce qui n’était pas terrible en cours de route. 

Une brève histoire du déploiement d’applications

1. Le déploiement traditionnel (fin des années 1990 à début des années 2000)

• Méthode : transferts manuels vers les serveurs via le protocole FTP (File Transfer Protocol). Les webmasters développaient l’application localement, puis la transféraient manuellement vers un serveur de production.
• Outils : des clients FTP classiques comme FileZilla ou WS_FTP, entre autres.

Aujourd’hui, tu serais surpris de savoir quels systèmes gigantesques étaient déployés de cette manière, et tu trouverais probablement ça complètement fou — mais c’était aussi amusant et stimulant ! Tu avais une modification à faire. Tu double-cliquais sur l’icône de ton client FTP préféré (oui, on utilisait Windows). Tu allais jusqu’au fichier. Double-clic. Tu modifiais un truc. Tu enregistrais. Et voilà, la modification était en place. On n’utilisait pas beaucoup de frameworks. Du coup, il y avait souvent un énorme fichier PHP quelque part. Et ta modification était localisée. Et si ça plantait ? Eh bien, tu faisais un nouveau double-clic et tu corrigeais le problème. Quand les cycles ne duraient que quelques secondes, ça allait. Enfin, jusqu’à ce que ça ne passe plus.

Souvent, ton application tournait sur un seul serveur, dédié à cet usage. Il hébergeait la base de données dont tu avais besoin, ou si tu faisais tourner quelque chose de plus gourmand en ressources, tu avais probablement un serveur séparé pour la base de données — ce qu’on appelait des déploiements multi-niveaux. Et en général, quelqu’un d’autre s’en occupait (l’administrateur de base de données).

En 1998, Apache proposait ce qu’on appelait des « hôtes virtuels », ce qui permettait d’héberger plusieurs sites sur la même machine, ce qui a conduit les gens à entasser de plus en plus d’applications sur le même serveur. Alors si tu modifiais un fichier dans le mauvais répertoire… eh bien.

À l’époque, tu travaillais peut-être déjà avec de vrais pros et tu fréquentais El Reg et Slashdot, donc tu avais déjà une sorte de séparation des responsabilités. Si c’était le cas, tu disposais en fait déjà d’un serveur de test et tu effectuais ces opérations sur l’environnement de préproduction. Ensuite, un administrateur système se chargeait de copier les modifications vers l’environnement de production, ce qui fonctionnait bien… jusqu’à ce que ça ne fonctionne plus.

2. L’arrivée des systèmes de contrôle de version (VCS) (début des années 2000)

• Méthode : les développeurs ont commencé à utiliser des VCS pour gérer les versions du code. Le déploiement impliquait parfois de récupérer le code le plus récent directement sur un serveur de production.
• Outils : CVS et Subversion.

À ce stade, les pros étaient devenus encore plus sérieux, et ils voulaient vraiment garder le contrôle sur ce qu’ils déployaient. Et les ingénieurs ont aussi commencé à détester les dossiers nommés production_v12_final_final_backup_charles_final. 

On a donc commencé à utiliser SVN, et mettre quelque chose en production signifiait généralement faire un « SVN up », ce qui était lent, pénible et plantait souvent. Mais c’était la manière sérieuse de faire les choses. Les plus malins ont appris à utiliser les liens symboliques : faire d’abord un « SVN up », puis basculer vers la racine web. C’était comme du GitOps sans le « Ops », et avec du « pull » plutôt que du « push ».

Mais bon, tu tournais toujours sur un système à base unique. C’était l’âge d’or des dépendances à cette époque. Et en général, l’environnement de test et la production étaient déjà désynchronisés depuis un bon moment. C’est là que l’expression « ça marche sur ma machine » a commencé à faire son apparition.

3. L’hébergement mutualisé et les panneaux de contrôle (années 2000)

• Méthode : l’essor de l’hébergement mutualisé a permis aux particuliers et aux petites entreprises d’héberger facilement des applications web. Des panneaux de contrôle comme cPanel permettaient aux utilisateurs de gérer les paramètres d’hébergement et de déployer des applications.
• Outils : cPanel, Plesk, DirectAdmin.

Tu serais surpris de voir combien de choses fonctionnent encore comme ça : tu te rends sur une page web et tu peux choisir parmi un modèle de déploiement proposant tout un tas d’applications (principalement en PHP, mais bien plus par la suite). Et c’est là que quelque chose d’intéressant s’est produit. Le déploiement des applications est devenu tellement plus simple. En un clic. 

Mais en réalité, ça rend la maintenance des applications d’autant plus difficile. Quand le déploiement est facile mais que la mise à jour est compliquée, ce n’est pas idéal. En général, ces outils te permettaient non seulement de modifier des éléments via FTP, mais ils te fournissaient aussi un client web pour que tu n’aies pas besoin de savoir comment te connecter à FTP.

4. Serveurs dédiés et serveurs privés virtuels (VPS) (milieu des années 2000)

• Méthode : à mesure que les applications web gagnaient en complexité, on s’est tourné vers les serveurs dédiés et les VPS pour bénéficier de plus de contrôle et de ressources. Ça a permis aux développeurs de personnaliser les paramètres du serveur en fonction des besoins de leur application.
• Outils : VMware, Xen, puis KVM par la suite.

La virtualisation a eu un impact énorme : tout à coup, on a pu commencer à séparer les applications du matériel. Désormais, on pouvait créer une image de machine et la déployer à la place de l’application. 

Ce concept réapparaîtra bien plus tard sous la forme des conteneurs. Et surtout, parce qu’on pouvait disposer de différentes bases. Mais la création d’images était un processus complexe. Les déploiements étaient lents. Certains ont adopté les nouveaux outils pour mettre en place de nouvelles pratiques. D’autres ont continué à considérer les machines basées sur des VM comme de simples outils pour utiliser le FTP ou le SVN. Avec les mêmes résultats.

5. Déploiement automatisé et intégration continue (CI) (fin des années 2000 à début des années 2010)

• Méthode : le cycle de vie du développement logiciel a vu l'arrivée d'outils de déploiement automatisé qui permettaient de tester le code et de le déployer automatiquement sur les serveurs de production.
• Outils : Jenkins, Bamboo, Capistrano et Fabric.

À un moment donné, les développeurs, comme moi, en ont vraiment eu marre de nos échanges avec les administrateurs système. On nous traitait mal. Et on savait coder. 

On a donc décidé de résoudre le problème par le code. C’est ce qu’on appelle encore aujourd’hui le DevOps. Il y avait principalement deux versions de cette approche :

1. Du code qui tournait sur ta machine et automatisait des actions auparavant manuelles (comme le FTP, la mise à jour SVN ou la modification d’un lien symbolique).
2. Du code qui tournait sur les serveurs et qui faisait globalement la même chose.

Les serveurs appartenaient toujours aux administrateurs système, mais en 2006, l’EC2 était déjà bien implanté. En tant que développeur, tu pouvais désormais accéder à une machine en fonctionnement sans avoir à demander la permission. Mais les mentalités n’avaient pas encore changé. Et les développeurs peu formés à la sécurité se faisaient le plus souvent rapidement « (P)owned ». 

Pourtant, si tes administrateurs système de l’époque étaient assez modernes, ils commençaient à te permettre de déployer directement. Au moins vers l’environnement de préproduction. Parce que c’étaient aussi les années du trio gagnant : dev-staging-prod. On était suffisamment automatisés pour gérer (non sans mal) les trois. Ce qui était mieux que staging-prod. Mais l’environnement de préproduction dérivait, et l’environnement de développement était presque toujours à différents stades de dysfonctionnement.

6. Plateforme en tant que service (PaaS) (début des années 2010)

• Méthode : des plateformes qui masquaient l’infrastructure, permettant aux développeurs de se concentrer sur le code. On pouvait pousser les applications vers ces plateformes, qui se chargeaient de la configuration des serveurs, de la mise à l’échelle et du déploiement.
• Outils : Heroku, Google App Engine, Microsoft Azure App Service et Platform.sh.

C’est la phase dont on a le plus envie de parler, parce qu’on est nous-mêmes une PaaS. Et même si on adorerait parler de nous, on doit respecter nos aînés. 

À ce stade, on avait goûté à la liberté du déploiement direct, mais aussi à la lourdeur de l’intégration continue. La plupart d’entre nous, bien habitués à la laideur des ordinateurs et aux bugs de tous les logiciels, acceptaient ça comme faisant partie des coûts de l’activité. Sauf que, pendant ces années-là, il s’est passé autre chose : Ruby et Ruby on Rails. Une véritable révolution, avec une esthétique qui lui est propre. Les adeptes de Ruby étaient plus attachés à la beauté et à la simplicité qu’à toute autre chose. 

À l’époque, on était au paroxysme de la loi de Moore : les ordinateurs devenaient de plus en plus rapides et ton code lent finirait par s’accélérer avec le temps, alors pourquoi ne pas se concentrer plutôt sur sa lisibilité et sa beauté ? 

Dans le monde de Ruby, les tests n’étaient pas considérés comme « le prix à payer parce que le langage est un fouillis peu sûr », mais comme la preuve d’une réflexion sur le système en termes simples. Pour reprendre les mots du poète français Boileau : « Ce qu’on conçoit bien s’exprime clairement, et les mots pour le dire viennent facilement ». 

Un autre élément majeur a été Git, qui est arrivé assez vite et a supplanté SVN.

Il y a une énorme différence d’intention entre `svn up` et `git push`. Mais l’essentiel, c’est que Git a rendu la création de branches peu coûteuse et rapide. Les gens de Heroku, avec leur amour de la simplicité et de l’esthétique Ruby, ont en gros déclaré que les serveurs, y compris ceux du cloud, étaient désormais du bétail. Ce que les administrateurs système font pour nous peut et doit être automatisé. On va simplifier les choses et te proposer un seul environnement d’exécution et une seule base de données. Toujours pareil ; pas de déviation des règles. Comme ça, tu peux faire `git push` et ton code s’exécutera sur un serveur accessible au public. 

Ça aurait pu être la fin de l’histoire, le mot de la fin, mais Heroku a été racheté très tôt par Salesforce. Ça ne veut pas dire que Salesforce ait été un mauvais gestionnaire, loin de là : ils ont même ajouté quelques environnements d’exécution par la suite, mais le service est resté globalement ce qu’il était, ignorant tout ce qui allait évoluer autour de lui au cours des 15 années suivantes. Et l’incapacité d’Heroku à évoluer avec son temps a rendu les gens méfiants vis-à-vis de ce concept. 

Le PaaS aurait pu être ce qui libérait les développeurs pour qu’ils s’expriment sans formalités ni bureaucratie inutiles, mais rester dans les limites imposées, ça ne donne pas cette impression.

Mais même en restant dans les limites imposées, Heroku et ses imitateurs de second ordre chez Google et AWS (AppEngine et Beanstalk) laissaient pas mal de tracas aux développeurs (et aujourd’hui aux équipes DevOps). Ça pouvait gérer la production, mais l’intégration continue, les environnements de préproduction, et tout ce qui ne concernait pas le runtime unique et la base de données gérée associée étaient laissés pour compte. Or, c’était justement l’essentiel de ce dont toute entreprise logicielle mature avait besoin. 

On y reviendra quand on parlera d’Upsun Cloud, mais c’est essentiellement le pari qu’on a fait. Pour qu’une véritable plateforme en tant que service (PaaS) puisse englober l’ensemble du processus, elle doit nécessairement être une plateforme couvrant tout le cycle de livraison continue.

7. Containerisation et microservices (milieu des années 2010)

• Méthode : les applications ont commencé à être développées comme des ensembles de microservices faiblement couplés. Les conteneurs encapsulaient ces services, en s’assurant qu’ils disposaient de toutes les dépendances nécessaires à leur exécution.
• Outils : Docker, Kubernetes, Docker Swarm et Platform.sh.

Pour rester sur le thème du PaaS, il y avait deux problèmes que les premiers systèmes PaaS ne résolvaient pas : l’exécution locale des logiciels et celle des microservices. L’exécution locale des microservices était pratiquement impossible à l’époque.

Les premiers systèmes PaaS visaient la simplification et, comme on l’a dit, ils s’articulaient autour d’un cas d’utilisation spécifique : une application monolithique unique avec une seule base de données gérée. 

8. Infrastructure-as-Code (IaC) et serverless (fin des années 2010)

• Méthode :
  • IaC : la mise en place et les configurations de l'infrastructure ont commencé à être traitées comme du code, ce qui a permis de créer des environnements cohérents et reproductibles.
  • Serverless : les développeurs écrivaient des fonctions qui s’exécutaient en réponse à des événements, sans se soucier des serveurs sous-jacents.
• Outils : AWS Lambda, Google Cloud Functions, Azure Functions, Terraform, Ansible, et Platform.sh.

9. Applications web progressives (PWA) et JAMstack (fin des années 2010 à début des années 2020)

• Méthode : on s’est orienté vers des applications avec rendu côté client et l’utilisation d’API pour les opérations backend. Le déploiement consistait principalement à pousser des fichiers statiques vers les nœuds périphériques des réseaux de diffusion de contenu (CDN).
• Outils : Netlify, Vercel, Cloudflare Pages, et tu l’as deviné, Platform.sh.

10. L’edge computing (années 2020)

• Méthode : rapprocher le calcul et le stockage des données de l'endroit où on en a besoin, pour améliorer les temps de réponse et économiser de la bande passante.
• Outils : AWS Wavelength, Cloudflare Workers, Akamai Edge Workers et Upsun Cloud.

Vue d’ensemble : la tendance à l’automatisation

Au fil des années, on a assisté à une évolution vers plus d’automatisation, une meilleure abstraction et une expérience développeur améliorée. À mesure que le Web et ses technologies associées évoluent, les méthodes et outils de déploiement continueront de changer pour répondre aux nouveaux défis et opportunités.

Dans cet article, ce qui est important, par rapport à ce qui se passe actuellement, ce sont surtout deux tendances :

L’essor de la conteneurisation

• Avant Kubernetes, le paysage du déploiement était déjà en pleine transformation grâce à Docker, qui a popularisé la technologie des conteneurs. Les conteneurs ont permis d’uniformiser l’environnement, du développement à la production, mettant ainsi fin à l’excuse « ça marche sur ma machine ». Cependant, à mesure que les conteneurs gagnaient du terrain, le besoin de les gérer, de les orchestrer et de les faire évoluer efficacement s’est fait de plus en plus pressant, surtout pour les applications à grande échelle.

L’émergence de Kubernetes (milieu des années 2010)

• Kubernetes a été lancé par Google en 2014, en s’appuyant sur son expérience avec Borg, un système interne de gestion de clusters. Kubernetes a répondu aux défis liés à l’orchestration, à la mise à l’échelle et à la gestion des conteneurs.
• Au début, Kubernetes n'était pas le seul acteur sur le marché. D'autres outils et plateformes, comme Docker Swarm et Apache Mesos, se disputaient la vedette dans le domaine de l’orchestration des conteneurs. Mais Kubernetes a rapidement gagné en popularité grâce à ses fonctionnalités robustes, à sa communauté active et au soutien des géants du secteur, ce qui lui a permis de devenir la norme de facto en matière d’orchestration des conteneurs.

Si Kubernetes a commencé comme un outil d’orchestration de conteneurs, son influence s’est largement étendue au-delà, redéfinissant le paysage du déploiement. Il a permis à des modèles comme les microservices de s’épanouir, a dynamisé de nouveaux paradigmes comme le GitOps et a catalysé un vaste écosystème d’outils et d’extensions.

La place d’Upsun Cloud

Upsun Cloud cherche à prendre tout ce qui précède et à en extraire l’essentiel pour en faire une solution claire et en libre-service :

1. Simplification et abstraction

• Ensemble d’outils unifié : une PaaS moderne masque les complexités de l’infrastructure sous-jacente, ce qui permet aux développeurs de se concentrer sur l’écriture de code et le déploiement d’applications. Au lieu de jongler entre plusieurs outils pour l’orchestration des conteneurs, la mise à l’échelle, la journalisation, la surveillance, etc., les développeurs disposent d’une plateforme unifiée qui intègre ces fonctionnalités prêtes à l’emploi.
• Processus rationalisés : les développeurs peuvent définir l’infrastructure et les services dont leur application a besoin à l’aide de fichiers de configuration. Cette approche simplifie et codifie le processus de déploiement.

2. Résilience et flexibilité pour l’avenir

• Évite l’enfermement propriétaire : de nombreuses solutions PaaS, dont Upsun Cloud, sont conçues pour être indépendantes du cloud. Ça veut dire que tu n’es pas lié à un fournisseur de cloud spécifique, ce qui te donne la flexibilité de changer de fournisseur ou même d’en utiliser plusieurs sans avoir à modifier en profondeur ton code.
• S’adapter aux tendances : les solutions PaaS modernes peuvent rapidement intégrer de nouveaux outils ou s’adapter à l’évolution des bonnes pratiques, garantissant ainsi aux développeurs un accès permanent aux dernières méthodologies et technologies sans les contraintes d’une intégration manuelle.

3. Cohérence entre les environnements

Upsun Cloud, par exemple, permet aux développeurs de cloner leur environnement de production pour le développement, les tests ou la préproduction. Ça garantit que l’application se comporte de manière cohérente à toutes les étapes, ce qui réduit les risques de comportements inattendus en production dus à des différences d’environnement.

4. CI/CD intégrés

De nombreuses plateformes PaaS modernes intègrent des pipelines d’intégration continue et de déploiement continu, garantissant ainsi que le code est testé et déployé en toute fluidité. Cette intégration réduit le recours à des outils tiers et rationalise le processus, du développement au déploiement.

5. Évolutivité et performances

Grâce à des fonctionnalités de mise à l’échelle automatique, les solutions PaaS peuvent gérer des charges de trafic variables sans intervention manuelle. Elles peuvent allouer des ressources selon les besoins, garantissant ainsi des performances optimales et un bon rapport coût-efficacité.

6. Sécurité

Les solutions PaaS modernes intègrent souvent des fonctionnalités de sécurité, notamment l’application automatisée des correctifs, des configurations réseau sécurisées et des certifications de conformité. Cette sécurité intégrée réduit les configurations manuelles et le recours à des outils tiers, ce qui diminue les points de défaillance potentiels.

7. Rentabilité

En réduisant le besoin de recourir à de multiples outils et services, le PaaS permet de réaliser des économies. Les entreprises n’ont pas besoin d’investir dans une expertise spécifique pour chaque outil, et les coûts opérationnels peuvent être réduits grâce aux économies d’échelle réalisées par les fournisseurs de PaaS.

En conclusion, l’évolution des outils a transformé notre façon d’envisager le déploiement des applications et l’infrastructure, et chacun d’entre eux comporte ses propres complexités. Les solutions PaaS modernes, comme Upsun Cloud, répondent à la demande de méthodologies de déploiement plus simples, unifiées et pérennes. À mesure que la technologie continue d’évoluer, la capacité à rester agile et à s’adapter avec un minimum de frictions constitue un avantage clé, faisant du PaaS un choix attractif pour de nombreuses entreprises.

Envie de l’essayer ? Commence ton essai gratuit dès aujourd’hui. 

Regarde cette vidéo