Abschied von EC2-Classic – es war eine großartige Zeit
(allthingsdistributed.com)- AWS hat am 15. August 2023 die letzte Instanz von EC2-Classic abgeschaltet und damit den Betrieb des frühen Cloud-Computing-Modells beendet, das mit dem Start von EC2 im Jahr 2006 begann
- Das Herzstück von Classic war ein einheitliches Flat-Network 10.0.0.0/8; die damalige Innovation bestand darin, die komplexe interne Implementierung zu verbergen und die Bereitstellung von Compute stark zu vereinfachen
- 2006 bot
m1.smallzum Preis von 0,10 US-Dollar pro Stunde eine vCPU auf dem Niveau eines 1,7-GHz-Xeon, 1,75 GB RAM, 160 GB lokalen Speicher und 250 Mb/s Netzwerk; später skalierte EC2 bis zu großen Instanzen wieP3dn.24xlarge - Elastic IP, Auto Scaling, Load Balancing, CloudWatch und neue Instanztypen kamen hinzu, und 2013 wurde VPC zum neuen Standard für pro Kunde isolierte und definierbare Cloud-Bereiche
- Classic blieb trotz neuer Virtualisierungsplattformen wie Nitro weitere zehn Jahre bestehen, weil Kunden es noch nutzten; Dokumentation, Tools und Support wurden aufrechterhalten, bis alle Instanzen abgeschaltet oder migriert waren
Das Ende von EC2-Classic und die frühe Architektur
- AWS ist beim Abschalten von Diensten, von denen Kundengeschäfte abhängen, stets vorsichtig vorgegangen
- SimpleDB wird weiterhin angeboten, obwohl sich DynamoDB als „NoSQL“-Datenbankoption für Kunden etabliert hat
- Zwei Jahre nach Jeff Barrs Ankündigung zum Ende von EC2-Classic wurde am 15. August 2023 die letzte Instanz von Classic abgeschaltet
- EC2 war fast 17 Jahre in Betrieb, und unter den AWS-Diensten sind nur SQS und S3 älter als EC2
- Der wichtigste Unterschied von „Classic“ war die Netzwerkarchitektur
- EC2 startete 2006 als ein einziges riesiges Netzwerk mit 10.0.0.0/8
- Alle Instanzen liefen in einem einzigen Flat-Network, das mit anderen Kunden geteilt wurde
- Es bot Funktionen wie Security Groups und Public IPs, die beim Start einer Instanz zugewiesen wurden
- Der interne Stack war äußerst komplex, für Nutzer war es jedoch einfach, den benötigten Compute zu erhalten
Veränderungen bei der Instanzleistung
- Wer 2006 eine
m1.small-Instanz startete, bekam folgende Konfiguration- virtuelle CPU auf dem Niveau eines 1,7-GHz-Xeon-Prozessors
- 1,75 GB RAM
- 160 GB lokaler Speicher
- 250 Mb/s Netzwerkbandbreite
- 0,10 US-Dollar pro Stunde
- Später skalierte EC2 bis zu Instanzen wie
P3dn.24xlarge- 100 Gbit/s Netzwerkdurchsatz
- 96 vCPU
- 8 NVIDIA-v100-Tensor-Core-GPUs mit jeweils 32 GiB Speicher
- 768 GiB Systemspeicher
- 1,8 TB lokaler SSD-Speicher
- EFA zur Beschleunigung von ML-Workloads
- EC2-Classic machte Hardware zu einer programmierbaren Ressource, sodass Entwickler, Gründer, Startups und Unternehmen genau dann so viel Compute nutzen konnten, wie sie brauchten
- Komplexität wie Infrastrukturverwaltung, der Kauf neuer Hardware, Software-Upgrades oder der Austausch defekter Festplatten wurde abstrahiert
Umstellung auf VPC und langfristiger Support
- Dieser Blog wurde kurz nach dem Start von EC2 auf
m1.smallmigriert und betrieb Moveable Type sowie eine lokale Datenbank- Später wurde daraus ein hochverfügbarer Dienst mit unter anderem RDS-Failover
- Nach der Einführung der Amazon S3 Website-Funktion im Jahr 2011 erfolgte die Umstellung auf S3
- Seitdem wurde er 12 Jahre lang „serverless“ betrieben
- Mit steigenden Kundenanforderungen kamen Elastic IP, Auto Scaling, Load Balancing, CloudWatch und verschiedene neue Instanztypen hinzu
- Mit der Einführung von VPC im Jahr 2013 konnten AWS-Kunden sichere, isolierte und auf ihr Geschäft zugeschnittene Cloud-Bereiche verwalten
- VPC wurde zum neuen Standard und bot Kunden das nötige Maß an Kontrolle, um umfassendere Systeme in der Cloud aufzubauen
- Auch nachdem sich EC2 mit Nitro zu einer neuen Virtualisierungsplattform weiterentwickelt hatte, wurde Classic wegen der Kundennutzung noch zehn Jahre lang unterstützt
- Das EC2-Team hielt den Betrieb aufrecht, bis alle Classic-Instanzen abgeschaltet oder migriert waren
- Während des gesamten Prozesses wurden Dokumentation, Tools, Support durch Engineering-Teams und Unterstützung durch Account-Management-Teams bereitgestellt
- Das Ende von EC2-Classic zeigt, wie stark sich die Cloud seit 2006 verändert hat, und macht deutlich, dass man weiterentwickelbare Systeme bauen und Architekturen immer wieder mit offenem Blick überprüfen sollte
1 Kommentare
Hacker-News-Meinungen
EC2-Classic fühlte sich magisch an
Es war, als wäre man endlich in einer Zukunft angekommen, in der Software das Networking übernimmt und man die alte Komplexität aus der Zeit vergessen kann, als Netzwerke noch mit Kabeln gebaut wurden
Statt um klassische IP-Subnetze drehte sich die Cloud um Security Groups, und mit ein paar Funktionen wie Hierarchien hätte sie die Rolle traditioneller Networking-Subnetze wohl vollständig ersetzen können
Nachdem ich EC2-Classic lange genutzt hatte, war Network Engineering einfach und machte Spaß; der neue VPC-Ansatz ist dagegen kompliziert, nimmt mir die Motivation, und ich bin mir nicht einmal sicher, ob er irgendetwas ermöglicht, das sich nicht schon mit Security Groups ausdrücken ließ
Ich habe das früher schon ausführlicher, oder je nach Stimmung auch heftiger, beschrieben, aber das stärkste Gefühl beim Wechsel weg von EC2-Classic war die Frustration, wenn andere etwas Funktionierendes schlechter machen
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
Im Hintergrund erstellt AWS automatisch eine VPC, und solange der Nutzer nicht wie in einem „Break-glass“-Fall explizit an den VPC-Einstellungen herumdreht, lässt es sich fast genauso wie das alte Classic verwenden
https://aws.amazon.com/vpc/lattice/
Allerdings geht es über Security Groups auf einem flachen Netzwerk hinaus: Jeder HTTP-Endpunkt wird automatisch zu einer IAM-Ressource, alle Services lassen sich wie AWS-native Dienste behandeln, und dieselben IAM-Policies können genutzt werden; das ist ziemlich ordentlich
Man kann der internen Routing-Tabelle einen einzigen Eintrag Richtung AWS hinzufügen, ohne über das öffentliche Internet zu gehen; in einem gemeinsam genutzten flachen Netzwerk wäre eine solche Konfiguration problematisch
Ich verstehe, dass man VPCs für die Integration mit Unternehmensnetzwerken, VPNs usw. braucht, aber in der Praxis machen sie Dinge oft übermäßig kompliziert, obwohl man eigentlich gar keine VPC benötigt
Die IPv4-Notation im Zitat ist verwirrend
Dort steht: „Als EC2 2006 gestartet wurde, war es ein einziges riesiges Netzwerk 10.2.0.0/8“; nach meinem Verständnis ist bei /8 nur das erste Oktett fest, also der Bereich 10.0.0.0 bis 10.255.255.255
Dann verstehe ich nicht, warum die 2 hier wichtig ist; wenn die 2 wichtig ist, müsste es nicht /16 heißen?
Angesichts der Quelle und meiner Sicherheit bei der Notation vermute ich, dass Fachleute vielleicht eine andere Bedeutung herauslesen können, daher interessiert es mich; falls es nur ein Tippfehler ist, tut es mir leid, wenn das zu pedantisch wirkt
Es hätte 10.0.0.0/8 heißen müssen; ich habe es im Blog korrigiert und auch die Verwirrung zur Speicherausstattung des P3dn.24xlarge richtiggestellt
Das größte Subnetz, das bei 10.2.0.0 beginnen kann, ist 10.2.0.0/15
Ich könnte mir vorstellen, dass es weniger ein Tippfehler ist, sondern eine merkwürdige Art, 10.0.0.0/8 mit Ausnahme von 10.1.0.0/16 zu schreiben
Ich habe es so interpretiert, dass der Autor meinte: Maschinen bekamen Adressen aus 10.2/16, konnten aber auch zu AWS-Services oder Maschinen in anderen 10/8-Subnetzen wie 10.1/16 routen
Es heißt zwar, „die Komplexität von Infrastrukturverwaltung, Kauf neuer Hardware, Software-Upgrades und dem Austausch defekter Festplatten wurde abstrahiert“, aber an ihre Stelle trat lediglich die Komplexität von AWS
Auch vor AWS musste man Hardware nicht selbst kaufen oder defekte Festplatten selbst austauschen; das erledigten Webhosting-Anbieter
Natürlich ist man nicht selbst ins Rechenzentrum gegangen, um eine Festplatte zu tauschen, aber der Ablauf war ein ganz anderer als das, was man bei AWS bekommt
Auch heute gibt es viele Webhosting-Anbieter, die nach dem alten Modell arbeiten, aber es gibt Gründe, warum Menschen Dienste wie AWS bevorzugen
Das ist etwas anderes als die Fähigkeit, mit ein paar Klicks einen neuen Server auf separater Hardware hochzufahren
Wenn man nur einen VPS braucht, sollte man einen VPS verwenden; persönlich bevorzuge ich in diesem Fall Hetzner
Aber um die Anforderungen großer Organisationen zu erfüllen, muss AWS zwangsläufig komplex sein
Außerdem ist die EC2-Startoberfläche in der AWS-Konsole wirklich deutlich besser geworden und nimmt einem eine Menge Komplexität ab
Auch Oracle verdient trotz seines ganzen Rufs weiterhin Milliarden Dollar
Ich war gerade dabei, den Satz „Einen Dienst einzustellen ist nicht das, was AWS normalerweise tut, und es ist ziemlich selten“ zu lesen, und machte zufällig eine Pause von der epischen Aufgabe, unsere Sachen vor der Abschaltung im Mai aus OpsWorks herauszuziehen.
Vor Kubernetes und Terraform habe ich ein paar Cluster mit OpsWorks gebaut.
Allerdings habe ich von AWS-Leuten gehört, dass es intern nicht gut gewartet wurde und im Hintergrund ziemlich chaotisch war. Daher überrascht es nicht, dass der Dienst jetzt eingestellt wird, nachdem sich die Technologielandschaft seit seiner Einführung stark verändert hat.
RIP OpsWorks
Der Titel lautet „Wir tun X“, aber der Text liest sich wie „Wir tun X hier nicht“, deshalb war mir anfangs nicht klar, worauf der Beitrag hinauswill.
Dieser Dienst ist in den „Wartungsmodus“ gegangen, und Anfang dieses Jahres wurde auch der Konsolenzugriff entfernt.
Die Passage „Vor zehn Jahren haben wir in der re:Invent-Keynote 2013 gesagt, dass wir sowohl die Workloads von heute als auch die von morgen unterstützen wollen, und unser Commitment zu Classic ist der beste Beweis dafür“ ist genau der Grund, warum Unternehmen AWS vertrauen.
Das EC2-Team hat Classic zuverlässig weiterbetrieben, bis alle Instanzen beendet oder migriert waren, und ich denke, genau so entsteht Vertrauen.
Ich erinnere mich noch daran, als wir bei Serif Webhosting für eine neue Social-Media-Website brauchten, die in unsere Scrapbook-Desktopsoftware integriert werden sollte.
Damals gab es wie immer viele glänzende neue Technologien, eine davon war Microsoft Silverlight, und wir implementierten „Deep Zoom“ auf der Website, damit Nutzer veröffentlichte Scrapbooks einfach vergrößern und Details ansehen konnten.
Eine weitere neue Technologie war AWS, und EC2 war gerade erst gestartet. Es war ziemlich aufregend, per Knopfdruck Instanzen in den USA, Irland und Amsterdam hochfahren zu können und, wenn sie ausfielen, einfach erneut auf den Button zu drücken, um neue zu starten.
Wie heute steckte auch damals hinter der einfachen UI beträchtliche Komplexität, und wir mussten die verschiedenen Storage-Typen lernen und welche davon persistent waren.
Die frühen EC2-Instanzen waren, glaube ich, nicht so stabil wie heute; tatsächlich haben wir ein oder zwei komplett verloren und mussten sie neu erstellen, weshalb wir viele Snapshots machten.
Infrastructure as Code oder DevOps gab es nicht, aber wir bauten unseren eigenen Hochverfügbarkeits-Cluster, und ein Ingenieur, mit dem ich zusammenarbeitete, schrieb von Grund auf in C++ Software, die die Datenbanken auf mehreren EC2-Instanzen überwachte und den Cluster am Leben hielt.
Cloud-Architekten gab es damals auch nicht, daher wussten wir nicht wirklich, was wir taten oder was klug war, aber die Technik funktionierte sehr gut, und nachdem wir die anfänglichen Fehlversuche hinter uns hatten, bauten wir eine recht aktive Internet-Community auf.
Die Website wurde mit PHP und MySQL gebaut; aus relationalen SQL-Daten erzeugtes XML wurde per XSLT in HTML umgewandelt, JavaScript gab es nicht viel, höchstens etwas jQuery.
Deployments liefen vermutlich so, dass wir mit FileZilla hochgeladen haben und die C++-Cluster-Software die hochgeladenen Dateien auf die EC2-Instanzen in anderen Availability Zones replizierte.
Rückblickend hätten wir wahrscheinlich keine Server in drei Availability Zones gebraucht, aber die Arbeit hat wirklich Spaß gemacht, und es waren gute Zeiten, in denen ich AWS zum ersten Mal kennengelernt habe.
AWS hatte keine Datenbankschicht, also nutzten wir für Haltbarkeit Instanzen mit angehängtem Elastic Block Store.
Was jetzt noch nötig ist: tatsächlich ein festes Budget zuzulassen, statt die Möglichkeit, dass die Kreditkartenrechnung aus dem Ruder läuft.
Microsoft macht das, und ich meine, Google tat es auch; keine Ahnung, warum Amazon es nicht macht.
Darauf warte ich nun auch schon fast 20 Jahre.
Persönlich hätte ich mir gewünscht, dass AWS einfach eine Entscheidung trifft, IPv6 an Classic hängt und damit weitermacht.
Ironischerweise wirkt post-Classic wie ein Rückschritt und ist der Infrastruktur, mit der man vor der Cloud umgehen musste, viel ähnlicher geworden.
Die meisten neuen Dinge baue ich inzwischen auf Cloudflare auf, daher denke ich kaum noch über Subnetze, VPCs und Ähnliches nach.
Sie alle müssen sich in interne Netzwerke integrieren, daher brauchen sie VPC.
Wenn ich das richtig verstanden habe, frage ich mich, ob alle Classic-Instanzen ohne Eingreifen der Kontoinhaber auf modernere Typen migriert wurden.
Ich frage mich auch, ob es dabei Neustarts gab oder ob das per Live-Migration erledigt wurde.
Denn es ist schwierig, Live-Migration aus einer Virtualisierungsplattform herauszuholen, die dafür ursprünglich nicht vorgesehen war.
Ich frage mich auch, ob die ursprünglichen Netzwerkeinstellungen noch emuliert werden oder ob manche Kundenanwendungen dabei kaputtgegangen sein könnten.
Details gibt es hier: https://aws.amazon.com/blogs/aws/ec2-classic-is-retiring-her...
AWS scheint Zeit, Personal und Geld aufgewendet zu haben, um Kunden von EC2-Classic wegzubringen, und hat sich offenbar auch ziemlich bemüht, den Prozess zu automatisieren und weniger schmerzhaft zu machen.
Beispiel: https://repost.aws/knowledge-center/ssm-migrate-ec2classic-v...
Das ursprüngliche Netzwerkmodell änderte sich von „alle im selben Subnetz“ zu „jeder bekommt sein eigenes Subnetz“, daher konnten Kundenanwendungen tatsächlich kaputtgehen.
So wie Leute IP-Adressen in /etc/hosts hardcoden, wenn ein Nameserver ausfällt, und später vergessen, das wieder rückgängig zu machen, tun Menschen aus nachvollziehbaren Gründen manchmal ziemlich unkluge Dinge.
Um solche Migrationen gut hinzubekommen, braucht man sowohl Zuckerbrot als auch Peitsche.
Die Peitsche ist letztlich, dass der Dienst eingestellt und nicht mehr angeboten wird; das Zuckerbrot sind Automatisierung, wiederholte Erinnerungen daran, dass ein Wartungsfenster nötig ist, klare Anleitungen und vor allem die Bereitschaft, wirklich mit Kunden zu sprechen und auf sie einzugehen.
Allerdings hat AWS den Leuten über Jahre hinweg Zeit dafür gegeben und ist, wenn nötig, auf alle Nutzer zugegangen und hat geholfen.
Vielleicht gab es Rabatte oder die Drohung mit der Abschaltung.
Dass es keine einzige Instanz gab, deren Besitzer sie vergessen hatte oder die Arbeit verweigerte, ist erstaunlich; ich finde wirklich interessant, wie das möglich war.
Vielleicht waren abgelaufene Kreditkarten der entscheidende Punkt, da sie die meisten vergessenen Konten womöglich automatisch deaktiviert haben.
Vermutlich lief es ähnlich.
VMs sind schwer automatisch zu verschieben, wenn sie nicht speziell dafür konfiguriert sind; zum Beispiel kann sich die Reihenfolge der Geräte am PCIe-Bus ändern, und verschiedene Maschinen-IDs wie MAC-Adressen können sich ebenfalls ändern.
Wenn man nicht sicherstellt, dass die VM von solchen Änderungen unbeeinflusst bleibt, ist die Wahrscheinlichkeit groß, dass es nach dem Umzug Probleme gibt.
Dieses Maß an Support sollte jedes Softwareunternehmen anstreben.
Genau das wollen Unternehmenskunden sehen, und genau dafür zahlen sie.