Comment le processus de support du site a changé au cours des vingt dernières années

Le gourou des technologies de l'information et directeur technique du magazine Ars Technica, Jason Marlin, a plus de vingt ans d'expérience dans le soutien aux infrastructures d'information - et, à son avis, beaucoup de choses ont changé dans ce domaine.

Le jeu Pit, qui fonctionnait comme une porte BBS. Dans cette capture d'écran, Lee Hutchinson attaque ces gars-là. Ou ils sont lui.

Dans les années 1980, j'ai grandi comme un vrai nerd - pas dans le sens hipster, mais dans le sens où je portais toujours avec moi un numéro de cinq kilos du magazine Computer Shopper (ouais, ces publications étaient vraiment grandes). Je suis devenu accro aux systèmes de tableau d'affichage à l'âge de dix ans. Il n'est pas surprenant que je sois finalement devenu le directeur technique du site, couvrant les questions scientifiques et technologiques.

Je peux établir des parallèles clairs entre le travail de support de mon BBS (c'est-à-dire le travail du sysop) et la gestion de l'infrastructure web moderne. Marquons ces parallèles en l'honneur du 20e anniversaire du site Ars. Cet article ne sera pas une histoire exhaustive des sites Web, je décrirai ici ma propre expérience dans la gestion de sites, et comment elle a évolué au cours des 20 dernières années - ainsi que la façon dont les outils et la pensée ont changé.

CHARGER «*», 8, 1

Ma première expérience en tant que sysop a été obtenue sur Commodore 128 (bien sûr, en mode 64 bits), où fonctionnait le programme Color 64 de Greg Pfountz. J'ai envoyé à Greg mon chèque (enfin, il a été signé par ma mère) et j'ai reçu une disquette de 5,25 pouces avec une instruction cousue à la main imprimée sur une imprimante matricielle, puis elle a commencé.

La couleur 64 avait l'air incroyable grâce à ASCII, peinte selon la norme ANSI, contrairement à la plupart des autres programmes BBS qui produisaient du texte banal incolore. La couleur 64 a permis de créer une expérience utilisateur. Je ne me souviens plus des noms de mon BBS, mais je garantis que le thème principal était lié aux dragons et / ou au kung-fu. J'ai un peu honte d'admettre que mon surnom était DragonMaster, mais je n'ai confirmé que les stéréotypes associés aux nerds.

Malheureusement, mon infrastructure réseau consistait en une seule ligne téléphonique, ce qui signifiait que je devais déconnecter tous les appareils appelants (c'est-à-dire un téléphone à disque mural) et travailler entre 23 et 5 heures. Cela signifiait également peu d'interactivité BBS. Avec une seule ligne et un seul lecteur Commodore 1571, les utilisateurs ne pouvaient pas discuter entre eux ou télécharger plus d'un jeu à la fois.


Le Commodore 1670 accélère encore le rythme cardiaque

Dans mes rêves, dans un avenir proche, j'ai dirigé le vrai BBS, quelque chose comme le célèbre Las Vegas Fear & Loathing, que j'ai souvent visité. Dans mes rêves, il y avait 10 lignes téléphoniques pour que les utilisateurs puissent communiquer entre eux en temps réel et se connecter à 1200 modems - non, même pas 2400 bauds! Et sur un disque dur mythique avec un volume allant jusqu'à 10 Mo du système Lt. Kernal aurait gardé des stocks infinis de jeux.

Hélas, tout cela était inaccessible pour moi, mais j'étais clairement infecté par une nouvelle maladie qui a encouragé un désir inhabituel chez une personne de créer des lieux numériques dans lesquels les utilisateurs pourraient se rassembler

Années 90

J'ai continué à jouer avec le logiciel BBS, y compris un prédécesseur HTML très intéressant comme Excalibur BBS . Jetez un œil aux résultats de recherche d'images Google pour voir comment ce logiciel était en avance sur son temps.

$: cd ~ / public_html

J'ai rencontré HTML pour la première fois au collège au milieu des années 90; puis j'ai fait mes devoirs et je les ai téléchargés dans le répertoire public d'accueil, et les enseignants pouvaient les réviser pendant leur temps libre en utilisant les navigateurs Netscape ou Mosaic. Un excellent facteur de motivation à l'époque était de 10 points supplémentaires pour «l'utilisation de la technologie».

Apache + Perl + XML + Hébergement partagé

L'une des premières véritables «applications» que j'ai créées en tant que développeur Web était le service des nouvelles d'une entreprise de télécommunications. Tout cela a fonctionné sur un bundle alors répandu: Apache comme serveur HTTP, Perl comme langage serveur et une base de données comme fichier texte. À cette époque, je ne connaissais pas les vraies bases de données, mais je savais comment écrire et analyser du XML. Tout cela a été hébergé sur une plateforme collaborative incroyablement bonne sur laquelle j'ai pu écrire toutes les règles du serveur dans un fichier .htaccess. J'ai vite appris que ce fichier donnait trop de pouvoir à mes mains inexpérimentées!

L'hébergement collaboratif a résolu mes problèmes, mais à l'époque, les développeurs dépendaient des administrateurs pour tout ce qui concernait les versions et les extensions logicielles. Vous deviez également vous soucier de ce que vos voisins font avec des ressources partagées, y compris toutes sortes de choses désagréables. Le piratage d'une machine pourrait compromettre des centaines de sites.

IIS, extensions FrontPage et accès

En conséquence, l'agence où j'ai travaillé a gagné suffisamment de clients pour s'offrir son propre serveur. À mon grand regret, il s'est avéré que c'était une machine Windows qui exécutait IIS (Internet Information Services). Ce territoire ne m'était pas familier, mais après le lancement de Frontpage IDE, j'ai été étonné de voir à quel point Microsoft a simplifié les tâches généralement difficiles de stockage des entrées vérifiées dans la base de données. (Non, sérieusement, juste génial). En conséquence, je suis allé à la recherche de l'IDE graphique parfait, y compris un désordre bref et frustrant avec Macromedia Dreamweaver. Bientôt, j'ai appris que les outils qui créent automatiquement du code produisent généralement une énorme quantité de nouilles, que seuls ces mêmes outils pourraient alors démêler.

La gestion d'IIS sous Windows NT 3.5 ressemblait également à une tâche dangereuse et facile pour une personne ayant de l'expérience sur Unix. Et en même temps, c'était un sentiment de restrictions strictes - où étaient les fichiers .conf dans lesquels il était possible de faire du micro-réglage (et un désordre phénoménal)?

Cet assemblage est devenu ma plateforme pendant un certain temps, nous avons fait plusieurs CMS sur commande pour nos clients, sans aucune pensée de maintenir une base de code commune, un support à long terme ou un contrôle de version. Quelle horreur.

Début des années 2000 commençant par ColdFusion

Maintenant, je comprends l'horreur de la situation, mais ensuite j'ai vraiment aimé l'environnement Allaire ColdFusion , et je l'ai utilisé pendant au moins quatre ans pour créer des applications et des réseaux d'entreprise suffisamment grands. Elle a travaillé sur la base du CFML (langage de balisage ColdFusion). Cela ressemblait à du HTML, mais il faisait des requêtes triviales aux bases de données et à leur intégration avec des technologies externes comme Java Servlets ou CORBA. ColdFusion avait de nombreux adversaires, mais je n'ai jamais été partisan d'une technologie particulière et j'ai simplement choisi ce qui m'a permis de terminer la tâche le plus rapidement.

Des frameworks Web apparaissent

La barrière d'entrée très faible de ColdFusion lui a valu la notoriété d'un langage idiot qui a attiré des programmeurs de faible qualité dans ce domaine - un peu comme PHP était. Je ne peux pas contester cela, mais l'ironie est que ma première connaissance d'un bon framework web a eu lieu sous la forme de Fusebox . Cela a commencé par une tentative d'organiser une application en utilisant des noms simples de fichiers et des conventions de système de répertoires. Cela semblait évident, mais, comme la plupart des développeurs Web de l'époque, je me suis tourné vers une approche en constante évolution de la mise en page des applications et j'ai lutté avec des choses qui se séparaient les unes des autres, telles que les requêtes de base de données et les composants de sortie. J'ai joué avec Struts , mais comme il était impossible d'utiliser Java dans le travail principal, je ne le comprenais toujours pas. Mais Fusebox m'a ouvert les yeux sur les plateformes avec le paradigme MVC (model view controller) qui va au-delà des limites de langages spécifiques. Et c'était bien des années avant l'apparition de cette présentation démolissante de 15 minutes de Ruby on Rails faite par David Heinemeyer Hansson .

Aujourd'hui, je n'envisagerais jamais de créer une grande application sans choisir un framework, et aujourd'hui nous avons de nombreux choix intéressants. Pour PHP, j'aime le plus Laravel .



Oui, alors ça a fait sauter le toit.

Hébergement Web en cluster

J'ai eu ma première expérience avec un site Web à fort trafic en 2002. Au fur et à mesure que le trafic augmentait, la responsabilité aussi, ainsi que le nombre d'appels au milieu de la nuit demandant un redémarrage du serveur. Et enfin, j'ai décidé de tout savoir sur l'équilibrage de charge, la mise en cache et l'hébergement de cluster. Ce fut une autre révélation, car elle a ouvert les possibilités d'une mise à l'échelle presque illimitée.

Si une machine était hors ligne, nous avions des voitures de sécurité pour nous assurer que tout fonctionnait. Nous avions des analyses et des mesures de cluster détaillées. La vie était belle, comme mon rêve.

Montée des machines virtuelles: AWS, Vagrant

AWS (Amazon Web Services) est apparu, semble-t-il, de nulle part, et a donné aux développeurs exactement ce dont nous avions besoin. Ils ont également retiré les intermédiaires de l'hébergement traditionnel. Nous n'avions pas à demander quelles technologies nous étions autorisés à utiliser; tout à coup, tout était possible. Vous voulez essayer de faire une application sur Django ou NodeJS? Pas de problème. Lancez quelques machines virtuelles et c'est parti. Tout cela pourrait être fait avec AWS: pare-feu virtuels, équilibreurs de charge, clusters spéciaux pour les bases de données, CDN (réseau de distribution de contenu) pour les ressources statiques, et presque tout ce à quoi vous pourriez penser. Il est devenu un centre de données pour l'auto-fabrication - et c'était à la fois une malédiction et une bénédiction. Lors de l'ajout de chaque nouveau service, il était nécessaire de le suivre, et pour que quelqu'un sache comment l'augmenter après que tout se brise (et que tout se brise). Trop passionné par le développeur, il était très facile de mordre plus qu'il ne pouvait mâcher.

Ce qu'AWS a rendu possible dans le cloud, Vagrant l'a rendu possible sur une machine de production. Vagrant nous a donné un accès facile et scriptable à divers fournisseurs de VM. J'ai pu tester de nouveaux types de Linux et toutes sortes de progiciels dans un environnement que, en matière de déploiement, il était très facile de recréer dans le cloud. En cas de problème lors de l'installation, la commande de destruction vagabonde la plus simple vous permet de recommencer depuis la même image. Cela a rendu le développement beaucoup plus agréable que d'exécuter des serveurs sur un système d'exploitation domestique ou d'utiliser directement VMWare ou VirtualBox.

Années 2010 - Des webmasters aux DevOps

Ralentissons un peu et parlons de la façon dont j'ai toujours détesté le terme webmaster.

Homme: Que fais-tu dans la vie?
Moi: je crée des applications web sympas en utilisant différents langages de programmation, et je travaille avec l'infrastructure ...
Homme: Ahhh, donc vous êtes un WEBMASTER!

Je veux supprimer ce mot dégoûtant.

En plus d'associer ce mot à un cube de jeu à 20 faces, il ne décrit pas du tout le rôle que beaucoup d'entre nous jouent dans la programmation et la gestion de l'infrastructure. Par conséquent, j'aime vraiment ce changement, au cours de la dernière décennie, vers des termes plus respectés tels que DevOps . Les ingénieurs DevOps utilisent la programmation pour créer, gérer et documenter une infrastructure du monde réel.

Chef + ansible

Lorsque j'ai commencé à travailler chez Ars Technica, nous voulions pouvoir ajouter ou supprimer facilement des serveurs Web et des serveurs de base de données dans un environnement virtualisé. Après avoir exploré plusieurs approches, nous nous sommes installés sur Chef , qui simplifie la gestion des infrastructures grâce à une hiérarchie d'analogies, principalement liées à la cuisine (couteau, livre de recettes, recettes, etc.). Après avoir étudié comment les propriétés des variables, ou «attributs», comme on les appelle ici, découlent des rôles et se résument à des nœuds séparés, il devient très simple de gérer les logiciels et versions de serveur à partir d'une seule plateforme. Chef nous a permis d'arrêter la microgestion de serveurs individuels dans des clusters et a facilité la tâche de mise à niveau en masse.

Aujourd'hui, personnellement, je préfère travailler avec Ansible , un système basé sur Python développé par Redhat - il est plus facile de travailler avec et est un peu moins fragile lorsque l'on travaille dans de petites organisations. Contrairement à Chef, où un serveur central est requis, Ansible utilise SSH à partir de la machine hôte (dans notre cas, à partir de nos ordinateurs portables à partir desquels nous développons), mais pour les grandes entreprises, il a toujours un serveur, Tower. Ansible vous permet également d'écrire la plupart de la configuration dans YAML, ce qui améliore considérablement sa lisibilité.

Depuis plusieurs années, nous hébergeons le ServerCentral Turing Group . Ils nous aident à choisir le bon équilibre entre ce que nous sommes bons (écrire du code et configurer la VM) et ce que nous ne pouvons pas contrôler complètement - ce sont des générateurs diesel de sécurité, des réseaux redondants ou la copie en temps réel des données vers un centre de données conçu pour contourner les échecs.

À partir de 2019

Je serai toujours nostalgique de ces jours sereins de saisie manuelle des commandes du modem lorsque quelque part à l'horizon, nous avons été attirés par les promesses faites par The Lawnmower Man ou Hal 9000. Mais le moment actuel contient également d'énormes opportunités pour la prochaine phase de l'évolution des infrastructures. Il y a tellement d'outils prometteurs que nous prévoyons de mettre en place, par exemple Docker Swarm ou Kubernetes . Il est étonnant de voir jusqu'où nous sommes allés et à quel point le développeur d'aujourd'hui est plus productif par rapport à ces vieux jours remplis du grincement mystérieux du BBS. J'espère que nous observerons une abstraction toujours croissante de la technologie multicouche complexe requise pour une présence Web moderne.

Nous vous souhaitons donc plein succès dans les 20 prochaines années!