Un bref historique du déploiement des applications

Écrire des applications, c'est bien. Si seulement nous pouvions faire cela plutôt que de nous embêter avec tout le processus de mise en place et de fonctionnement, n'est-ce pas ? Je dis souvent que les applications sont comme des avions : lorsqu'elles sont en vol, il y a de fortes chances, si vous les avez bien conçues, qu'elles continuent à fonctionner sans problème. C'est au moment du décollage et de l'atterrissage que l'on rencontre généralement des problèmes, c'est-à-dire au moment du déploiement.

Dans cet article de blog, je vais faire un bref historique de la manière dont nous avions l'habitude de déployer les applications, en examinant ce qui a changé, ce qui a bien fonctionné et ce qui n'a pas été si bien en cours de route.

Bref historique du déploiement d'applications

1) Déploiement traditionnel (de la fin des années 1990 au début des années 2000)

• Méthode : téléchargements manuels par protocole de transfert de fichiers (FTP) vers des serveurs. Les webmasters développaient l'application localement, puis la transféraient manuellement vers un serveur de production.
• Outils : clients FTP standard tels que FileZilla ou WS_FTP, entre autres.

Aujourd'hui, vous seriez choqué de connaître les énormes systèmes qui ont été déployés de cette manière, et vous penseriez probablement que c'est de la folie - mais c'était aussi amusant et vivifiant ! Vous aviez une chose à modifier. Vous double-cliquiez sur l'icône de votre client FTP préféré (oui, nous utilisions Windows). Vous naviguiez jusqu'à un fichier. Double-clic. Modifier quelque chose. Sauvegarder. Voilà, le changement a été effectué. Nous n'utilisions pas beaucoup de frameworks. Il y a donc de fortes chances que vous ayez un énorme fichier PHP quelque part. Et votre changement était localisé. Et s'il était cassé ? Vous double-cliquiez à nouveau et corrigiez le problème. Lorsque les temps de cycle sont de l'ordre de la seconde, c'était parfait. Enfin, jusqu'à ce que ce ne soit plus le cas.

Souvent, votre application fonctionnait sur un seul serveur, dédié à cet usage. La base de données dont vous aviez besoin tournait sur ce serveur, ou si vous utilisiez quelque chose de plus gourmand en ressources, vous aviez probablement un serveur séparé pour la base de données - ce que nous appelions les déploiements multi-tiers. En général, quelqu'un d'autre s'occupait de ce serveur (l'administrateur de la base de données).

En 1998, Apache disposait de ce que l'on appelle les hôtes virtuels, qui permettaient d'hébergerplusieurs sites sur la même machine, ce qui a eu pour effet d'entasser de plus en plus d'applications sur le même serveur. Ainsi, si vous modifiez un fichier dans le mauvais répertoire... eh bien...

À l'époque, vous travailliez peut-être déjà avec de vrais pros et vous étiez sur El Reg et Slashdot, de sorte que vous aviez déjà un semblant de séparation des responsabilités. Si c'était le cas, vous aviez déjà un serveur de test et vous faisiez ce truc sur le staging. Ensuite, un administrateur système se chargeait de la copie vers la production, ce qui était très bien - jusqu'à ce que ce ne soit plus le cas.

2) L'introduction des systèmes de contrôle de version (VCS ) (début des années 2000)

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

À cette époque, les professionnels sont devenus encore plus sérieux et veulent réellement contrôler les éléments qu'ils déploient. Les ingénieurs ont également commencé à détester les dossiers appelés production_v12_final_final_backup_charles_final.

Nous avons donc commencé à utiliser SVN et mettre quelque chose en production signifiait généralement utiliser SVN, ce qui était lent, pénible et souvent cassé. Mais c'était la façon la plus sérieuse de faire les choses. Les personnes intelligentes ont appris à utiliser Symlinks, à mettre en place SVN d'abord, puis à passer à la racine web. C'était comme GitOps sans les Ops, et avec pull plutôt que push.

Mais il s'agissait toujours d'un système à base unique. La dépendance a connu ses meilleurs jours à cette époque. Et généralement, la mise en scène et la production étaient déjà désynchronisées depuis longtemps. C'est à ce moment-là que l'expression "ça marche sur ma machine" est devenue courante.

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

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

Vous seriez étonné de voir le nombre de choses qui fonctionnent encore de cette manière : aller sur une page web et pouvoir sélectionner un modèle déployable d'un certain nombre d'applications (principalement PHP, mais plus tard beaucoup plus). Et c'est là que quelque chose d'intéressant s'est produit. Le déploiement d'applications est devenu beaucoup plus facile. En un seul clic.

Cependant, il s'avère que cela rend la maintenance des applications d'autant plus difficile. Lorsque le déploiement est facile mais que la mise à jour est difficile, ce n'est pas génial. En général, ces outils vous permettaient non seulement de modifier des données par FTP, mais ils vous fournissaient également un client web, de sorte que vous n'aviez pas besoin de savoir comment vous connecter à FTP.

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

• Méthode : les applications web devenant de plus en plus complexes, les développeurs se sont tournés vers les serveurs dédiés et les serveurs privés virtuels pour bénéficier d'un meilleur contrôle et de plus de ressources. Cela a permis aux développeurs de personnaliser les paramètres du serveur en fonction des besoins de leur application.
• Outils : VMware, Xen, puis KVM.

La virtualisation a eu un impact considérable : soudain, nous avons pu commencer à séparer les applications du matériel. Désormais, il est possible de créer une image de machine et de la déployer plutôt que l'application.

Ce thème reviendra bien plus tard sous la forme de conteneurs. Plus important encore, parce que vous pouviez avoir différentes bases. Mais la création d'images était une histoire complexe. Les déploiements étaient lents. Certains ont adopté les nouveaux outils pour adopter de nouvelles pratiques. D'autres ont continué à traiter les machines basées sur des VM comme une chose avec laquelle ils utilisaient FTP. Ou SVN. Avec les mêmes résultats.

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

• Méthode : le cycle de vie du développement logiciel a vu l'introduction d'outils de déploiement automatisé qui ont permis 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 de logiciels, comme moi, sont devenus très très fatigués de nos échanges avec les administrateurs système. Nous étions maltraités. Et nous savions coder.

Nous avons donc décidé de résoudre le problème par le code. C'est ce que nous appelons aujourd'hui DevOps. Il en existait principalement deux versions :

1. Le code qui s'exécutait sur votre machine et automatisait ce qui était auparavant des actions manuelles (comme FTP, SVN up, ou basculer un Symlink).
2. Le code qui s'exécutait sur les serveurs et faisait essentiellement les mêmes choses.

Les serveurs étaient toujours la propriété des administrateurs système, mais en 2006, EC2 était devenu une réalité. En tant que développeur, vous pouviez accéder à une machine en cours d'exécution sans en demander la permission. Mais l'état d'esprit n'avait pas encore changé. Et les développeurs peu formés à la sécurité se faisaient le plus souvent rapidement (P)posséder.

Néanmoins, si les administrateurs système de l'époque étaient suffisamment modernes, ils commençaient à vous permettre de déployer directement. Au moins pour la mise en scène. Car c'était aussi les années du tiercé : dev-staging-prod. Nous étions suffisamment automatisés pour maintenir (en souffrant) les trois. Ce qui était mieux que staging-prod. Malgré tout, staging a dérivé, et dev était presque toujours à différents stades de rupture.

6) Plate-forme en tant que service (PaaS ) (début des années 2010)

• Méthode : des plateformes qui font abstraction de l'infrastructure, permettant aux développeurs de se concentrer sur le code. Les applications peuvent être poussées vers ces plateformes, qui s'occupent de la configuration du serveur, de la mise à l'échelle et du déploiement.
• Outils : Heroku, Google App Engine, Microsoft Azure App Service etPlatform.sh.

C'est la phase dont nous avons le plus envie de parler, car nous sommes un PaaS. Et même si nous aimerions parler de nous-mêmes, nous devons respecter nos aînés.

A ce stade, nous avons goûté à la liberté de déployer directement, et à la lourdeur de l'intégration continue. La plupart d'entre nous, habitués à la laideur des ordinateurs et au fait que tous les logiciels sont cassés, ont accepté cela comme faisant partie du coût de l'activité. Sauf qu'au cours de ces années, quelque chose d'autre s'est produit : Ruby et Ruby on Rails. Un changement de donne avec son propre sens de l'esthétique. Les gens de Ruby étaient plus attachés à la beauté et à la simplicité qu'à toute autre chose.

À l'époque, nous étions au paroxysme de la loi de Moore : les ordinateurs devenaient plus rapides et votre code lent deviendrait plus rapide avec le temps, alors pourquoi ne pas plutôt se concentrer sur sa lisibilité et sa beauté ?

Dans le monde Ruby, les tests n'étaient pas considérés comme "le coût de l'activité parce que le langage est un désordre peu sûr", mais comme la preuve que l'on pouvait penser au système en termes simples. Pour reprendre les mots du poète français Boileau, "ce que l'on conçoit bien, s'exprime clairement, et les mots pour le dire viennent facilement".

Un autre élément important a été Git, qui a rapidement remplacé SVN.

Il y a une énorme différence d'intentionnalité entre `svn up` et `git push`. Mais l'essentiel est que Git a rendu les branches bon marché et rapides. Les gens de Heroku, avec leur amour de la simplicité et de l'esthétique Ruby, ont dit en gros que les serveurs et les serveurs en nuage sont maintenant du bétail. Ce que les administrateurs système font pour nous peut et doit être automatisé. Nous allons simplifier et vous donner un seul runtime et une seule base de données. C'est toujours la même chose, il n'y a pas à sortir des sentiers battus. De cette façon, vous pouvez `git push` et votre code fonctionnera sur un serveur accessible au public.

Cela aurait pu être la fin de la ligne, le dernier mot de l'histoire, mais Heroku a été racheté très tôt par Salesforce. Cela ne veut pas dire que Salesforce a été un mauvais gestionnaire, ils ont même ajouté quelques runtimes en cours de route, mais le service est resté essentiellement ce qu'il était, ignorant tout ce qui allait passer dans les 15 prochaines années. Et l'incapacité d'Heroku à évoluer avec son temps a rendu les gens méfiants à l'égard de l'idée.

Le PaaS aurait pu permettre aux développeurs de s'exprimer sans cérémonie ni bureaucratie inutiles, mais peindre à l'intérieur des lignes n'en a pas l'air.

Mais même si l'on s'en tenait à ces lignes, Heroku et ses copies de moindre importance de Google et AWS (AppEngine et Beanstalk) laissaient une grande partie des problèmes au développeur (et maintenant à l'équipe DevOps). Il pouvait gérer la production, mais l'intégration continue, la mise en scène du développement et tout ce qui n'était pas l'exécution unique et la base de données gérée attachée étaient laissés à l'abandon. Ce qui était la plupart des choses nécessaires à toute organisation logicielle mature.

Nous y reviendrons lorsque nous parlerons d'Upsun, mais c'est essentiellement le pari que nous avons fait. Qu'il est possible d'envelopper l'ensemble du processus en un seul, car une véritable plate-forme en tant que service doit être une plate-forme pour l'ensemble du cycle de livraison continue.

7) Conteneurisation et microservices (milieu des années 2010)

• Méthode : les applications ont commencé à être développées comme des collections de microservices faiblement couplés. Les conteneurs encapsulent ces services, garantissant qu'ils disposent de toutes les dépendances nécessaires à leur fonctionnement.
• Outils : Docker, Kubernetes, Docker Swarm et Platform.sh.

Pour continuer sur le thème du PaaS, deux des choses que le premier système PaaS ne résolvait pas étaient l'exécution de logiciels localement et l'exécution de microservices. Non pas l'exécution locale de microservices, car c'était pratiquement impossible à l'époque.

Les premiers systèmes PaaS étaient axés sur la simplification et, comme nous l'avons dit, ils étaient centrés sur le cas d'utilisation spécifique du monolithe unique avec la base de données unique 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, permettant des environnements cohérents et reproductibles.
  • Serverless : les développeurs écriraient des fonctions qui seraient exécutées en réponse à des événements, sans se soucier des serveurs sous-jacents.
• Outils : AWS Lambda, Google Cloud Functions, Azure Functions, Terraform, Ansible, oh et Platform.sh.

9. les applications web progressives (PWA) et JAMstack (de la fin des années 2010 au début des années 2020)

• Méthode : évolution vers des applications rendues côté client et l'utilisation d'API pour les opérations de 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, vous l'aurez deviné, Platform.sh.

10. l 'informatique de pointe (années 2020)

• Méthode : rapprocher le calcul et le stockage des données de l'endroit où ils sont nécessaires, afin d'améliorer les temps de réponse et d'économiser de la bande passante.
• Outils : AWS Wavelength, Cloudflare Workers, Akamai Edge Workers et Upsun.

Zoom arrière : vers l'automatisation

Au fil des ans, l'automatisation, l'abstraction et l'amélioration de l'expérience des développeurs ont pris de l'ampleur. À mesure que le web et ses technologies associées évoluent, les méthodes et outils de déploiement continueront à changer pour répondre aux nouveaux défis et opportunités.

Dans cette histoire, l'important, en ce qui concerne ce qui se passe actuellement, ce sont deux tendances en particulier :

L'essor de la conteneurisation

• Avant Kubernetes, le paysage du déploiement était déjà transformé par Docker, qui a popularisé la technologie des conteneurs. Les conteneurs ont apporté un environnement cohérent du développement à la production, garantissant que l'excuse "ça marche sur ma machine" appartenait au passé. Cependant, alors que les conteneurs commençaient à gagner du terrain, le besoin de les gérer, de les orchestrer et de les mettre à l'échelle efficacement s'est fait de plus en plus sentir, en particulier pour les applications à grande échelle.

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

• Kubernetes a été introduit par Google en 2014, sur la base de son expérience avec Borg, un système interne de gestion de clusters. Kubernetes a permis de relever les défis de l'orchestration, de la mise à l'échelle et de la gestion des conteneurs.
• Kubernetes n'était pas le seul acteur au début. D'autres outils et plateformes, comme Docker Swarm et Apache Mesos, se disputaient la vedette dans le domaine de l'orchestration des conteneurs. Cependant, Kubernetes a rapidement gagné en popularité grâce à son ensemble de fonctionnalités robustes, à sa communauté active et au soutien de géants de l'industrie, ce qui lui a permis de devenir la norme de facto pour l'orchestration de conteneurs.

Si Kubernetes a débuté comme un outil d'orchestration de conteneurs, son influence s'est étendue bien au-delà, remodelant le paysage du déploiement. Il a permis à des modèles tels que les microservices de prospérer, a dynamisé de nouveaux paradigmes tels que GitOps et a catalysé un vaste écosystème d'outils et d'extensions.

La place d'Upsun

Upsun essaie de prendre toute l'histoire ci-dessus et de distiller ce qui fonctionne dans une boîte en libre-service bien ordonnée :

1. simplification et abstraction

• Ensemble d'outils unifiés : un PaaS moderne fait abstraction des complexités de l'infrastructure sous-jacente, ce qui permet aux développeurs de se concentrer sur l'écriture du code et le déploiement des applications. Au lieu de jongler avec 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 dès le départ.
• Flux de travail 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é futures

• Éviter le verrouillage du fournisseur : de nombreuses solutions PaaS, y compris Upsun, sont conçues pour être agnostiques au cloud. Cela signifie que vous n'êtes pas lié à un fournisseur de cloud spécifique, ce qui vous donne la flexibilité de changer de fournisseur ou même d'utiliser plusieurs fournisseurs sans changements significatifs de la base de code.
• S'adapter aux tendances : Les solutions PaaS modernes peuvent rapidement intégrer de nouveaux outils ou s'adapter à l'évolution des meilleures pratiques, ce qui permet aux développeurs d'avoir toujours accès aux dernières méthodologies et technologies sans les inconvénients d'une intégration manuelle.

3) Cohérence entre les environnements

Upsun, par exemple, permet aux développeurs de cloner leur environnement de production pour le développement, les tests ou la mise en attente. Cela garantit que l'application se comporte de manière cohérente à tous les stades, réduisant ainsi les risques de comportements inattendus en production dus à des différences d'environnement.

4) CI/CD intégré

De nombreuses plateformes PaaS modernes sont livrées avec des pipelines intégrés d'intégration et de déploiement continus, garantissant que le code est testé et déployé de manière transparente. Cette intégration réduit le besoin d'outils tiers et rationalise le processus de développement jusqu'au déploiement.

5) Évolutivité et performances

Grâce à des fonctions de mise à l'échelle automatique, les solutions PaaS peuvent gérer des charges de trafic variables sans intervention manuelle. Elles peuvent allouer des ressources en fonction des besoins, ce qui garantit des performances et une rentabilité optimales.

6. sécurité

Les solutions PaaS modernes sont souvent dotées de fonctions de sécurité intégrées, notamment de correctifs automatisés, de configurations réseau sécurisées et de certifications de conformité. Cette sécurité intégrée signifie moins de configuration manuelle et moins d'outils tiers, ce qui réduit les points de défaillance potentiels.

7. efficacité économique

En réduisant le besoin d'outils et de services multiples, le PaaS peut entraîner des économies. Les organisations n'ont pas besoin d'investir dans l'expertise pour chaque outil individuel 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, une série d'outils a transformé la façon dont nous envisageons le déploiement d'applications et l'infrastructure, et chacun d'entre eux s'accompagne de ses propres complexités. Les solutions PaaS modernes, comme Upsun, sont une réponse à la demande de méthodologies de déploiement plus simples, unifiées et à l'épreuve du temps. Alors que la technologie continue d'évoluer, la capacité à rester agile et adaptable avec un minimum de friction est un avantage clé, faisant du PaaS un choix attractif pour de nombreuses organisations.

Si vous souhaitez l'essayer, commencez votre essai gratuit dès aujourd'hui.

Regarder cette vidéo