Accueil Cloud computing Adieu EC2-Classic, ça a été chouette

Adieu EC2-Classic, ça a été chouette

0
Adieu EC2-Classic, ça a été chouette


EC2-Classic dans une galerie de musée

La suppression de services n’est pas quelque chose que nous faisons chez AWS. C’est assez rare. Les entreprises comptent sur nos offres – leurs activités vivent littéralement de ces services – et c’est quelque chose que nous prenons au sérieux. Par exemple, SimpleDB existe toujours, même si DynamoDB est la base de données « NoSQL » de choix pour nos clients.

Alors, il y a deux ans, quand Jeff Barr a annoncé que nous fermerions EC2-Classicje suis sûr qu’il y en avait au moins quelques-uns d’entre vous qui ne croyait pas que nous allions réellement appuyer sur l’interrupteur – que nous le laisserions fonctionner pour toujours. Eh bien, ce jour est venu. Le 15 août 2023, nous avons arrêté la dernière instance de Classic. Et avec toute l’histoire ici, je pense qu’il vaut la peine de célébrer la version originale de l’un des services qui ont lancé ce que nous appelons aujourd’hui le cloud computing.

EC2 existe depuis un bon moment, près de 17 ans. Seuls SQS et S3 sont plus anciens. Donc, je ne vous en voudrais pas si vous vous demandiez ce qui rend une instance EC2 « classique ». En termes simples, il s’agit de l’architecture du réseau. Lorsque nous avons lancé EC2 en 2006, il s’agissait d’un réseau géant de 10.0.0.0/8. Toutes les instances fonctionnaient sur un réseau unique et plat partagé avec d’autres clients. Il a exposé une poignée de fonctionnalités, telles que les groupes de sécurité et les adresses IP publiques attribuées lors du démarrage d’une instance. Classic a rendu le processus d’acquisition de calcul extrêmement simple, même si la pile exécutée en coulisses était incroyablement complexe. « Inventer et simplifier » est l’un des Principes de leadership d’Amazon après tout…

Si vous aviez lancé une instance en 2006, une m1.small, vous auriez obtenu un processeur virtuel équivalent à un processeur Xeon 1,7 GHz avec 1,75 Go de RAM, 160 Go de disque local et 250 Mo/seconde de bande passante réseau. Et cela n’aurait coûté que 0,10 $ par heure pointée. C’est assez incroyable où est passé le cloud computing depuis lors, avec un P3dn.24xlarge fournissant 100 Gbit/s de débit réseau, 96 vCPU, 8 GPU NVIDIA v100 Tensor Core avec 32 Go de mémoire chacun, 768 Go de mémoire système totale et 1,8 To de mémoire. stockage SSD local, sans parler d’un EFA pour accélérer les charges de travail de ML.

Mais 2006 était une autre époque, et ce réseau plat et cette petite collection d’instances, comme le m1.small, étaient « classiques ». Et à l’époque, c’était vraiment révolutionnaire. Le matériel était devenu une ressource programmable que vous pouviez augmenter ou réduire à tout moment. Chaque développeur, entrepreneur, startup et entreprise avait désormais accès à autant de calcul qu’il le souhaitait, quand il le souhaitait. Les complexités liées à la gestion de l’infrastructure, à l’achat de nouveau matériel, à la mise à niveau des logiciels et au remplacement des disques défectueux ont été supprimées. Et cela a changé la façon dont nous concevons et construisons tous des applications.

Bien sûr, la première chose que j’ai faite lors du lancement d’EC2 a été de déplacer ce blog vers un m1.small. Il courait Type mobile et cette instance était suffisante pour exécuter le serveur et la base de données locale (pas encore de RDS). Finalement, je l’ai transformé en un service hautement disponible avec basculement RDS, etc., et il a fonctionné pendant plus de 5 ans jusqu’à ce que le Fonctionnalité du site Web Amazon S3 a été publié en 2011. Le blog est désormais « sans serveur » depuis 12 ans.

Comme nous le faisons avec tous nos services, nous avons écouté ce dont nos clients avaient ensuite besoin. Cela nous a amené à ajouter des fonctionnalités telles que les adresses IP Elastic, Auto Scaling, Load Balancing, CloudWatch et divers nouveaux types d’instances qui conviendraient mieux aux différentes charges de travail. En 2013, nous avions activé le VPC, qui permettait à chaque client AWS de gérer sa propre tranche de cloud, sécurisée, isolée et définie pour son entreprise. Et c’est devenu la nouvelle norme. Cela a simplement donné aux clients un nouveau niveau de contrôle qui leur a permis de créer des systèmes encore plus complets dans le cloud.

Nous avons continué à prendre en charge Classic pendant la décennie suivante, même si EC2 évoluait et que nous implémentions une toute nouvelle plate-forme de virtualisation, Nitro – parce que nos clients l’utilisaient.

Il y a dix ans, lors de mon discours d’ouverture à re:Invent en 2013, je vous ai dit que nous voulions « prendre en charge les charges de travail d’aujourd’hui ainsi que celles de demain », et notre engagement envers Classic en est la meilleure preuve. Je n’ai pas perdu de vue la quantité de travail nécessaire à un effort comme celui-ci, mais c’est exactement ce type de travail qui renforce la confiance, et je suis fier de la façon dont il a été géré. Pour moi, cela incarne ce que signifie être obsédé par le client. L’équipe EC2 a permis à Classic de fonctionner (et de fonctionner correctement) jusqu’à ce que chaque instance soit arrêtée ou migrée. Fournir de la documentation, des outils et le soutien des équipes d’ingénierie et de gestion de compte tout au long du processus.

C’est doux-amer de dire au revoir à l’une de nos offres originales. Mais nous avons parcouru un long chemin depuis 2006 et nous n’avons pas fini d’innover pour nos clients. C’est un rappel que construire des systèmes évolutifs est une stratégie et que revisiter vos architectures avec un esprit ouvert est un must. Alors adieu Classic, ça a été chouette. Vive EC2.

Certificat de réussite

Maintenant, allez construire !

Articles recommandés

LAISSER UN COMMENTAIRE

S'il vous plaît entrez votre commentaire!
S'il vous plaît entrez votre nom ici