Adieu à EC2-Classic, ce fut une belle époque
(allthingsdistributed.com)- Le 15 août 2023, AWS a arrêté la dernière instance d’EC2-Classic, mettant fin à l’exploitation du premier modèle de calcul cloud lancé avec EC2 en 2006
- Le cœur de Classic était un réseau à plan unique 10.0.0.0/8 ; à l’époque, l’innovation tenait au fait de rendre l’accès à la capacité de calcul simple, tout en masquant une implémentation interne complexe
- En 2006, m1.small proposait un vCPU équivalent à un Xeon 1,7 GHz, 1,75 Go de RAM, 160 Go de disque local et un réseau à 250 Mb/s pour 0,10 $ de l’heure ; par la suite, EC2 s’est étendu à de grandes instances comme P3dn.24xlarge
- Elastic IP, Auto Scaling, Load Balancing, CloudWatch et de nouveaux types d’instances ont été ajoutés, et en 2013 VPC est devenu le nouveau standard pour des zones cloud isolées et définissables par client
- Classic a été maintenu pendant dix années supplémentaires après l’arrivée de nouvelles plateformes de virtualisation comme Nitro, en raison de son usage par les clients ; la documentation, les outils et le support ont continué jusqu’à l’arrêt ou la migration de toutes les instances
Fin d’EC2-Classic et architecture initiale
- AWS a toujours abordé avec prudence l’arrêt de services dont dépendent les activités de ses clients
- SimpleDB continue d’être proposé même après que DynamoDB s’est imposé comme l’option de base de données « NoSQL » des clients
- Deux ans après l’annonce par Jeff Barr du retrait d’EC2-Classic, la dernière instance de Classic a été arrêtée le 15 août 2023
- EC2 a fonctionné pendant près de 17 ans, et parmi les services AWS, seuls SQS et S3 sont plus anciens qu’EC2
- Le principal élément qui distinguait « Classic » était l’architecture réseau
- En 2006, EC2 a démarré avec un immense réseau unique 10.0.0.0/8
- Toutes les instances s’exécutaient sur un réseau à plan unique partagé avec d’autres clients
- Il proposait des fonctionnalités comme les groupes de sécurité et l’adresse IP publique attribuée au lancement d’une instance
- La pile interne était très complexe, mais les utilisateurs pouvaient obtenir simplement la capacité de calcul dont ils avaient besoin
Évolution des performances des instances
- En 2006, lancer une instance m1.small donnait accès à la configuration suivante
- CPU virtuel équivalent à un processeur Xeon 1,7 GHz
- 1,75 Go de RAM
- 160 Go de disque local
- 250 Mb/s de bande passante réseau
- 0,10 $ de l’heure
- Par la suite, EC2 s’est étendu à des instances comme P3dn.24xlarge
- Débit réseau de 100 Gbps
- 96 vCPU
- 8 GPU NVIDIA v100 Tensor Core avec 32 Gio de mémoire
- 768 Gio de mémoire système
- 1,8 To de stockage SSD local
- EFA pour accélérer les workloads ML
- EC2-Classic a transformé le matériel en ressource programmable, permettant aux développeurs, fondateurs, startups et entreprises d’utiliser autant de calcul que nécessaire, au moment voulu
- La complexité de la gestion d’infrastructure, de l’achat de nouveau matériel, des mises à jour logicielles ou du remplacement de disques défectueux était abstraite
Transition vers VPC et support à long terme
- Ce blog a été migré vers m1.small peu après le lancement d’EC2, et exécutait Moveable Type avec une base de données locale
- Il a ensuite été remplacé par un service à haute disponibilité avec basculement RDS, entre autres
- Après le lancement en 2011 de la fonctionnalité Website d’Amazon S3, il a été migré vers une architecture basée sur S3
- Il a ensuite fonctionné en mode « serverless » pendant 12 ans
- À mesure que les besoins des clients augmentaient, Elastic IP, Auto Scaling, Load Balancing, CloudWatch et divers nouveaux types d’instances ont été ajoutés
- En 2013, l’activation de VPC a permis à chaque client AWS de gérer une zone cloud sécurisée, isolée et définie selon les besoins de son activité
- VPC est devenu le nouveau standard et a offert aux clients le niveau de contrôle nécessaire pour construire des systèmes plus complets dans le cloud
- Même après l’évolution d’EC2 vers une nouvelle plateforme de virtualisation appelée Nitro, Classic a été pris en charge pendant dix années supplémentaires en raison de son utilisation par les clients
- L’équipe EC2 a maintenu l’exploitation jusqu’à ce que toutes les instances Classic soient arrêtées ou migrées
- Tout au long du processus, de la documentation, des outils, ainsi que le support des équipes d’ingénierie et de gestion de comptes ont été fournis
- La fin d’EC2-Classic montre à quel point le cloud a changé depuis 2006, et rappelle qu’il faut construire des systèmes capables d’évoluer et réexaminer son architecture avec un regard ouvert
1 commentaires
Avis sur Hacker News
EC2-Classic avait quelque chose de magique
On avait enfin l’impression d’être arrivés dans un futur où le logiciel prenait en charge le réseau, et où l’on pouvait oublier l’ancienne complexité de l’époque où l’on construisait les réseaux avec des câbles
Plutôt que les sous-réseaux IP traditionnels, le cloud fonctionnait autour des groupes de sécurité ; avec seulement quelques fonctions supplémentaires, comme une structure hiérarchique, il aurait sans doute pu remplacer complètement le rôle des sous-réseaux du réseau traditionnel
Après avoir longtemps utilisé EC2-Classic, l’ingénierie réseau me semblait simple et amusante, alors que la nouvelle approche VPC est complexe, décourageante, et je ne vois pas bien si elle rend possible quelque chose qu’on ne pouvait pas exprimer avec des groupes de sécurité
J’ai déjà écrit là-dessus plus en détail, ou de façon plus véhémente selon mon humeur, mais le sentiment le plus fort que j’ai eu en quittant EC2-Classic, c’était la frustration de voir des gens rendre pire quelque chose qui fonctionnait très bien
https://news.ycombinator.com/item?id=36829190
https://news.ycombinator.com/item?id=33569889
https://news.ycombinator.com/item?id=27990847
https://news.ycombinator.com/item?id=25988915
En coulisses, AWS crée automatiquement un VPC et, tant que l’utilisateur ne touche pas à la configuration VPC en mode « briser la vitre », on peut l’utiliser presque comme l’ancien Classic
https://aws.amazon.com/vpc/lattice/
Cela dit, cela va plus loin qu’un simple réseau plat avec des groupes de sécurité par-dessus : chaque endpoint HTTP devient automatiquement une ressource IAM, tous les services se manipulent comme des services AWS natifs, et l’on peut utiliser les mêmes politiques IAM, ce qui est plutôt intéressant
On peut ajouter une entrée unique vers AWS dans la table de routage interne, sans passer par l’Internet public ; dans un réseau plat partagé, ce type de configuration pose problème
Je comprends qu’un VPC soit nécessaire pour l’intégration avec un réseau interne, un VPN, etc., mais en pratique il arrive souvent qu’un VPC complique excessivement les choses alors qu’il n’est pas du tout nécessaire
La notation IPv4 dans la citation prête à confusion
Il est écrit : « Quand nous avons lancé EC2 en 2006, c’était un immense réseau 10.2.0.0/8 » ; or, à ma compréhension, avec un /8 seul le premier octet est fixe, ce qui donne la plage 10.0.0.0 à 10.255.255.255
Dans ce cas, je ne vois pas pourquoi le 2 est important ici ; et s’il l’est, il me semble qu’il faudrait écrire /16
Vu la source et le fait que je ne sois pas totalement sûr de moi sur la notation, je me demande s’il existe un autre sens qu’un spécialiste lirait là-dedans ; si c’est juste une coquille, désolé de pinailler autant
Il fallait écrire 10.0.0.0/8 ; cela a été corrigé sur le blog, ainsi que la confusion concernant la mémoire du P3dn.24xlarge
Le plus grand sous-réseau que l’on puisse créer en partant de 10.2.0.0 est 10.2.0.0/15
Je me dis que ce n’est peut-être pas tant une coquille qu’une façon étrange d’écrire 10.0.0.0/8 en excluant 10.1.0.0/16
J’ai interprété cela comme voulant dire que les machines recevaient des adresses 10.2/16, mais qu’elles pouvaient aussi router vers des services ou machines AWS dans d’autres sous-réseaux 10/8, comme 10.1/16
« La complexité de la gestion de l’infrastructure, de l’achat de nouveau matériel, des mises à jour logicielles et du remplacement des disques défectueux a été abstraite », mais elle a simplement été remplacée par la complexité d’AWS
Même avant AWS, il n’était pas nécessaire d’acheter soi-même le matériel ni de remplacer soi-même les disques défectueux : les hébergeurs web s’en chargeaient
Bien sûr, on n’allait pas forcément soi-même dans le datacenter changer un disque, mais le processus était très différent de ce que l’on obtient avec AWS
Il existe encore beaucoup d’hébergeurs web qui fonctionnent à l’ancienne, mais il y a des raisons pour lesquelles les gens préfèrent des services comme AWS
Ce n’est pas comparable à la capacité de lancer un nouveau serveur sur du matériel séparé en quelques clics
Si tout ce qu’il faut est un VPS, alors il suffit d’utiliser un VPS, et personnellement je préfère Hetzner dans ce cas
Mais pour répondre aux besoins de grandes organisations, AWS est forcément complexe
Par ailleurs, l’interface de lancement EC2 dans la console AWS s’est vraiment beaucoup améliorée et prend en charge une bonne partie de cette complexité
Oracle, malgré toute sa réputation, continue elle aussi de générer des milliards de dollars
J’étais en train de lire la phrase « mettre fin à un service n’est pas quelque chose qu’on fait chez AWS, et c’est assez rare », justement pendant une pause au milieu d’un epic de migration de tout ce qu’on avait sur OpsWorks avant son arrêt en mai
Avant l’arrivée de Kubernetes et Terraform, j’avais créé plusieurs clusters avec OpsWorks
Cela dit, d’après ce que des gens d’AWS m’ont dit, il n’était pas très bien maintenu en interne et l’arrière-boutique était assez en vrac ; donc, vu à quel point le paysage technologique a changé depuis le lancement du service, son arrêt aujourd’hui n’est pas vraiment surprenant
RIP OpsWorks
Le titre dit « nous faisons X », mais le corps du texte se lit plutôt comme « nous ne faisons pas X ici », si bien qu’au début je ne comprenais pas vraiment ce que l’article voulait dire
Ce service est passé en « mode maintenance » et l’accès à la console a aussi été supprimé au début de l’année
Le passage disant « il y a 10 ans, lors de la keynote re:Invent 2013, nous disions vouloir prendre en charge à la fois les workloads d’aujourd’hui et ceux de demain, et notre engagement envers Classic en est la meilleure preuve » résume précisément pourquoi les entreprises font confiance à AWS
L’équipe EC2 a continué à faire fonctionner Classic correctement jusqu’à ce que toutes les instances soient arrêtées ou migrées, et je pense que c’est ce genre de choses qui crée la confiance
Je me souviens encore de l’époque où, chez Serif, nous avions besoin d’un hébergement web pour un nouveau site de réseau social qui devait s’intégrer à notre logiciel de scrapbooking de bureau
Comme toujours à l’époque, il y avait beaucoup de nouvelles technologies brillantes, dont Microsoft Silverlight ; nous avions implémenté « Deep Zoom » sur le site pour permettre aux utilisateurs de zoomer facilement dans les scrapbooks publiés et d’en voir les détails
Une autre nouveauté était AWS, et comme EC2 venait tout juste de sortir, c’était assez excitant de pouvoir lancer des instances aux États-Unis, en Irlande et à Amsterdam d’un simple clic, puis de recliquer pour en relancer une si elle mourait
Comme aujourd’hui, une grande complexité se cachait derrière une UI simple, et il fallait apprendre les différents types de stockage et lesquels étaient persistants
Les premières instances EC2 ne semblaient pas aussi stables qu’aujourd’hui ; nous en avons effectivement perdu une ou deux complètement et avons dû les recréer, donc nous faisions beaucoup de snapshots
Il n’y avait pas d’infrastructure as code ni de DevOps, mais nous avions construit notre propre cluster haute disponibilité, et un ingénieur avec qui je travaillais avait écrit en C++ un logiciel de zéro pour surveiller les bases de données sur plusieurs instances EC2 et maintenir le cluster en vie
À l’époque, il n’y avait pas non plus d’architectes cloud, donc nous ne savions pas vraiment ce que nous faisions ni ce qui était judicieux, mais la technologie fonctionnait très bien et, après les tâtonnements initiaux, nous avons créé une communauté Internet assez active
Le site était fait en PHP et MySQL ; du XML généré à partir des données relationnelles SQL était transformé en HTML avec XSLT, avec peu de JavaScript, essentiellement jQuery
Le déploiement consistait probablement à envoyer les fichiers avec FileZilla, puis le logiciel de cluster en C++ répliquait les fichiers téléversés vers les instances EC2 situées dans d’autres zones de disponibilité
Avec le recul, nous n’avions sans doute pas besoin de serveurs dans trois zones de disponibilité, mais c’était vraiment amusant à faire et c’était une excellente époque pour découvrir AWS
AWS n’avait pas de couche base de données, donc on utilisait des instances avec Elastic Block Store attaché pour la durabilité
Il ne manque plus que la possibilité d’autoriser réellement un budget fixe, au lieu du risque de voir sa carte bancaire exploser
Microsoft le fait, et il me semble que Google le faisait aussi ; je ne sais pas pourquoi Amazon ne le fait pas
J’attends ça depuis presque 20 ans, moi aussi
Personnellement, j’aurais aimé qu’AWS tranche simplement et ajoute IPv6 à Classic pour continuer comme ça
Ironiquement, le post-Classic ressemble à une régression et se rapproche beaucoup plus de l’infrastructure qu’il fallait gérer avant le cloud
Comme je mets désormais la plupart des nouvelles choses sur Cloudflare, je ne pense presque plus aux sous-réseaux, VPC, etc.
Comme elles doivent toutes s’intégrer à leurs réseaux internes, elles finissent par avoir besoin de VPC
Si j’ai bien compris, je me demande si toutes les instances Classic ont été migrées vers un type plus moderne sans intervention du titulaire du compte.
Je me demande aussi s’il y a eu un redémarrage pendant l’opération, ou si cela a été géré par migration à chaud.
Parce qu’il est difficile d’extraire de la migration à chaud d’une plateforme de virtualisation qui n’a pas été conçue pour ça au départ.
Je me demande aussi si la configuration réseau d’origine est encore émulée, ou si certaines applications clientes ont pu casser.
Les détails sont ici : https://aws.amazon.com/blogs/aws/ec2-classic-is-retiring-her...
AWS semble avoir consacré du temps, des personnes et de l’argent à faire sortir ses clients d’EC2-Classic, et a aussi fait pas mal d’efforts pour automatiser le processus et le rendre moins douloureux.
Exemple : https://repost.aws/knowledge-center/ssm-migrate-ec2classic-v...
Le réseau d’origine est passé d’un modèle où tout le monde était dans le même sous-réseau à un modèle où chacun reçoit son propre sous-réseau, donc les applications clientes pouvaient effectivement casser.
Comme lorsqu’on met des adresses IP en dur dans /etc/hosts quand les serveurs de noms tombent, puis qu’on oublie de revenir en arrière : les gens font parfois des choses peu intelligentes pour des raisons tout à fait valables.
Pour réussir ce genre de migration, il faut à la fois le bâton et la carotte.
Le bâton, c’est qu’au bout du compte le service sera arrêté et refusé ; la carotte, ce sont l’automatisation, les rappels répétés qu’une fenêtre de maintenance est nécessaire, des consignes claires, et surtout la volonté de réellement parler aux clients et de leur répondre.
Cela dit, AWS a laissé des années aux gens pour le faire et, si nécessaire, est allé aider tous les utilisateurs concernés.
Il y a peut-être eu des remises ou des menaces de fermeture.
Je trouve étonnant qu’il n’y ait pas eu une seule instance dont le propriétaire l’avait oubliée ou refusait d’agir ; je suis vraiment curieux de savoir comment cela a été possible.
L’expiration des cartes de crédit a peut-être joué un rôle clé, en désactivant probablement automatiquement la plupart des comptes oubliés.
C’était probablement un procédé similaire.
Les VM sont difficiles à déplacer automatiquement si elles n’ont pas été spécialement configurées pour être mobiles ; par exemple, l’ordre des périphériques sur le bus PCIe peut changer, et plusieurs identifiants machine comme l’adresse MAC peuvent aussi changer.
Si l’on ne garantit pas que la VM n’est pas affectée par ce type de changements, il y a de fortes chances que des problèmes apparaissent après le déplacement.
Ce niveau de support est celui que toutes les entreprises de logiciels devraient viser.
C’est exactement ce que les clients entreprise veulent voir, et ce pour quoi ils paient.