Perpisahan dengan EC2-Classic, itu adalah masa yang luar biasa

 (allthingsdistributed.com)
1 poin oleh GN⁺ 2023-09-03 | 1 komentar | Bagikan ke WhatsApp
  • AWS mematikan instans terakhir EC2-Classic pada 15 Agustus 2023, menandai berakhirnya operasional model komputasi cloud awal yang dimulai saat EC2 diluncurkan pada 2006
  • Inti dari Classic adalah jaringan bidang tunggal 10.0.0.0/8, dan inovasi saat itu terletak pada penyederhanaan penyediaan komputasi sambil menyembunyikan implementasi internal yang kompleks
  • Pada 2006, m1.small menyediakan vCPU setara Xeon 1.7GHz, RAM 1.75GB, disk lokal 160GB, dan jaringan 250Mb/s dengan harga $0.10 per jam, dan setelah itu EC2 berkembang hingga instans besar seperti P3dn.24xlarge
  • Elastic IP, Auto Scaling, Load Balancing, CloudWatch, dan tipe instans baru ditambahkan, lalu pada 2013 VPC menjadi standar baru untuk area cloud yang dapat diisolasi dan didefinisikan per pelanggan
  • Classic tetap dipertahankan 10 tahun lebih lama bahkan setelah hadirnya platform virtualisasi baru seperti Nitro karena masih digunakan pelanggan, dan dokumentasi, alat, serta dukungan terus diberikan hingga semua instans dihentikan atau dimigrasikan

Penghentian EC2-Classic dan struktur awal

  • AWS telah lama berhati-hati saat menghentikan layanan yang menjadi sandaran bisnis pelanggan
    • SimpleDB masih terus ditawarkan bahkan setelah DynamoDB menjadi pilihan basis data “NoSQL” utama bagi pelanggan
  • Dua tahun setelah pengumuman Jeff Barr tentang penghentian EC2-Classic, instans terakhir Classic dimatikan pada 15 Agustus 2023
  • EC2 telah beroperasi hampir 17 tahun, dan di antara layanan AWS, hanya SQS dan S3 yang lebih tua daripada EC2
  • Faktor pembeda terbesar dari “Classic” adalah arsitektur jaringan
    • Pada 2006, EC2 dimulai sebagai satu jaringan raksasa 10.0.0.0/8
    • Semua instans berjalan dalam jaringan bidang tunggal yang dibagikan dengan pelanggan lain
    • Layanan ini menyediakan fitur seperti security group dan Public IP yang ditetapkan saat instans diluncurkan
  • Tumpukan internalnya sangat kompleks, tetapi pengguna dapat memperoleh komputasi yang dibutuhkan dengan cara yang sederhana

Perubahan kinerja instans

  • Saat menjalankan instans m1.small pada 2006, konfigurasi berikut tersedia
    • CPU virtual setara prosesor Xeon 1.7GHz
    • RAM 1.75GB
    • Disk lokal 160GB
    • Bandwidth jaringan 250Mb/s
    • $0.10 per jam
  • Setelah itu EC2 berkembang hingga mencakup instans seperti P3dn.24xlarge
    • Throughput jaringan 100Gbps
    • 96 vCPU
    • 8 GPU NVIDIA v100 Tensor Core dengan memori 32GiB
    • Memori sistem 768GiB
    • Penyimpanan SSD lokal 1.8TB
    • EFA untuk mempercepat workload ML
  • EC2-Classic mengubah perangkat keras menjadi sumber daya yang dapat diprogram, sehingga developer, pendiri, startup, dan enterprise dapat menggunakan komputasi sebanyak yang mereka perlukan saat mereka membutuhkannya
    • Kompleksitas seperti pengelolaan infrastruktur, pembelian perangkat keras baru, upgrade perangkat lunak, dan penggantian disk yang rusak diabstraksikan

Transisi ke VPC dan dukungan jangka panjang

  • Blog ini dipindahkan ke m1.small segera setelah peluncuran EC2, dan menjalankan Moveable Type serta basis data lokal
    • Setelah itu, blog ini berubah menjadi layanan highly available dengan failover RDS dan lainnya
    • Setelah fitur Website Amazon S3 dirilis pada 2011, blog ini dipindahkan ke basis S3
    • Setelah itu, blog ini beroperasi dalam keadaan “serverless” selama 12 tahun
  • Seiring meningkatnya kebutuhan pelanggan, Elastic IP, Auto Scaling, Load Balancing, CloudWatch, dan berbagai tipe instans baru ditambahkan
  • Saat VPC diaktifkan pada 2013, tiap pelanggan AWS dapat mengelola area cloud yang aman, terisolasi, dan ditentukan sesuai kebutuhan bisnis mereka
    • VPC menjadi standar baru, dan memberikan tingkat kontrol yang memungkinkan pelanggan membangun sistem yang lebih komprehensif di cloud
  • Bahkan setelah EC2 berevolusi ke platform virtualisasi baru bernama Nitro, Classic tetap didukung 10 tahun lebih lama karena masih digunakan pelanggan
  • Tim EC2 mempertahankan operasional hingga semua instans Classic dihentikan atau dimigrasikan
    • Sepanjang proses, dokumentasi, alat, dukungan tim engineering, dan dukungan tim account management tetap disediakan
  • Berakhirnya EC2-Classic menunjukkan bahwa cloud telah banyak berubah sejak 2006, dan bahwa kita perlu membangun sistem yang dapat berevolusi serta meninjau ulang arsitektur dengan sudut pandang yang terbuka

Bacaan terkait

1 komentar

 
GN⁺ 2023-09-03
Opini Hacker News

  • EC2-Classic terasa seperti sihir
    Rasanya akhirnya kami tiba di masa depan ketika software mengambil alih urusan networking, dan kami bisa melupakan kerumitan lama dari era ketika jaringan dibangun dengan kabel
    Dibanding subnet IP tradisional, cloud bekerja dengan berpusat pada security group, dan seandainya ada beberapa fitur seperti struktur hierarkis, rasanya itu bisa sepenuhnya menggantikan peran subnet dalam networking tradisional
    Setelah lama memakai EC2-Classic, rekayasa jaringan terasa mudah dan menyenangkan, tetapi cara VPC baru begitu rumit sampai mematahkan semangat, dan saya juga tidak yakin apakah itu memungkinkan sesuatu yang sebelumnya tidak bisa diekspresikan dengan security group
    Sebelumnya saya juga pernah menulis lebih detail, atau lebih keras tergantung suasana hati, tetapi emosi terbesar saat beralih dari EC2-Classic adalah rasa frustrasi ketika orang lain membuat sesuatu yang baik-baik saja menjadi lebih buruk
    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

    • Jika membuat akun baru, pada praktiknya ia berperilaku seperti EC2-Classic dulu
      Di belakang layar AWS membuatkan VPC secara otomatis, dan sampai pengguna merasa perlu “memecahkan kaca darurat” lalu menyentuh pengaturan VPC, itu bisa dipakai hampir sama seperti Classic lama
    • VPC Lattice yang baru-baru ini keluar pada dasarnya mendekati “networking EC2 Classic”, tetapi kini dalam bentuk berbayar
      https://aws.amazon.com/vpc/lattice/
      Namun ini lebih maju daripada sekadar menaruh security group di atas jaringan datar: setiap endpoint HTTP otomatis menjadi resource IAM, semua service diperlakukan seperti native AWS, dan bisa memakai kebijakan IAM yang sama, jadi cukup bagus
    • VPC jelas memungkinkan hal-hal yang tidak bisa dilakukan Classic
      Tanpa melewati internet publik, kita bisa menambahkan satu entri menuju AWS di tabel routing internal perusahaan, dan konfigurasi seperti ini bermasalah pada jaringan datar yang dibagi bersama
    • Salah satu startup pertama tempat saya bekerja seluruhnya berjalan di atas EC2-Classic, dan kesederhanaannya memang enak
      Saya paham VPC diperlukan saat berintegrasi dengan jaringan internal, VPN, dan semacamnya, tetapi dalam praktiknya sering kali pekerjaan dibuat terlalu rumit padahal VPC sama sekali tidak dibutuhkan

  • Notasi IPv4 dalam kutipan itu membingungkan
    Tertulis, “ketika EC2 diluncurkan pada 2006, itu adalah satu jaringan raksasa 10.2.0.0/8”, tetapi setahu saya /8 berarti hanya oktet pertama yang tetap, sehingga rentangnya 10.0.0.0–10.255.255.255
    Kalau begitu saya tidak tahu kenapa angka 2 penting di sini, dan kalau angka 2 memang penting, bukankah seharusnya ditulis /16
    Mengingat sumbernya dan keyakinan saya soal notasi ini, saya penasaran apakah ada makna lain yang bisa ditangkap para ahli; kalau ini cuma salah ketik, maaf kalau saya terlalu rewel

    • Itu poin yang benar dan memang salah ketik
      Seharusnya 10.0.0.0/8, dan sudah saya perbaiki di blog; kebingungan terkait memori P3dn.24xlarge juga saya luruskan sekaligus
    • Mungkin memang salah ketik, tetapi bisa juga mesin EC2-Classic hanya dialokasikan dari 10.2.0.0–10.2.255.255 di dalam subnet 10.0.0.0–10.255.255.255, sementara 10.x.0.0–10.x.255.255 dicadangkan untuk layanan lain
    • 10.2.0.0/8 bukan subnet mask yang valid, jadi besar kemungkinan itu salah ketik
      Subnet terbesar yang bisa dibuat mulai dari 10.2.0.0 adalah 10.2.0.0/15
    • Benar, /8 adalah 10.0.0.0/8
      Saya jadi berpikir mungkin itu bukan sekadar salah ketik, melainkan cara yang aneh untuk menuliskan 10.0.0.0/8 dengan pengecualian 10.1.0.0/16
    • Saya melihat 10.2.0.0/16 pada dasarnya sebagai bagian dari rentang alamat jaringan privat 10.0.0.0/8
      Saya menafsirkan penulisnya bermaksud bahwa mesin mendapat alamat 10.2/16, tetapi tetap bisa dirutekan ke layanan atau mesin AWS di subnet 10/8 lain seperti 10.1/16

  • “Kerumitan mengelola infrastruktur, membeli hardware baru, upgrade software, dan mengganti disk yang rusak diabstraksikan,” tetapi yang masuk menggantikannya hanyalah kerumitan AWS
    Bahkan sebelum AWS pun kita tidak harus membeli hardware sendiri atau mengganti disk rusak sendiri; penyedia web hosting yang melakukannya

    • Pernyataan “penyedia web hosting yang melakukannya” terlalu menyederhanakan
      Tentu saja kita tidak masuk sendiri ke data center untuk mengganti disk, tetapi prosesnya sangat berbeda dari cara yang didapat di AWS
      Sampai sekarang pun ada banyak penyedia web hosting yang beroperasi dengan cara lama, tetapi ada alasan orang lebih memilih layanan seperti AWS
    • Benar, tetapi biasanya kita harus a) mendeteksi dan mendiagnosis sendiri, dan b) menunggu penyedia hosting setuju lalu menggantinya, yang bisa memakan waktu dari beberapa jam sampai beberapa minggu
      Itu sangat berbeda dari kemampuan menyalakan server baru di hardware terpisah hanya dengan beberapa klik
    • Jika kebutuhannya tidak besar, AWS tidak harus rumit; bisa memakai sesuatu seperti Lightsail
      Kalau yang dibutuhkan hanya VPS, pakai saja VPS, dan secara pribadi untuk kasus itu saya lebih suka Hetzner
      Namun untuk menangani kebutuhan organisasi besar, AWS memang mau tidak mau menjadi rumit
      Selain itu, interface peluncuran EC2 di konsol AWS benar-benar sudah jauh membaik dan menangani cukup banyak kerumitan untuk kita
    • Melihat tidak ada satu pun penyedia web hosting tunggal yang tumbuh sebesar AWS atau Azure, cukup jelas kerumitan macam apa yang bersedia ditanggung industri
      Oracle juga, terlepas dari segala reputasinya, masih menghasilkan miliaran dolar

  • Saat sedang membaca kalimat “menghentikan layanan bukanlah sesuatu yang dilakukan AWS, dan itu cukup jarang,” kebetulan saya sedang beristirahat dari pekerjaan epik memindahkan hal-hal kami dari OpsWorks sebelum penutupannya pada Mei

    • OpsWorks, menurut pengalaman saya, adalah layanan yang sangat bagus, dan penutupannya benar-benar disayangkan
      Sebelum Kubernetes dan Terraform muncul, saya membuat beberapa klaster dengan OpsWorks
      Namun dari yang saya dengar dari orang-orang AWS, secara internal pemeliharaannya tidak berjalan baik dan bagian belakangnya cukup berantakan, jadi tidak mengejutkan layanan ini dihentikan sekarang, ketika lanskap teknologi sudah sangat berubah dibanding saat layanan itu pertama muncul
      RIP OpsWorks
    • Bagian ini terasa cukup canggung
      Judulnya “kami melakukan X,” tetapi isi tulisannya terbaca seperti “kami tidak melakukan X di sini,” jadi awalnya saya tidak begitu paham tulisan itu mau mengatakan apa
    • Saya juga merasakan hal yang sama karena sedang menangani dampak dari memindahkan sesuatu dari AWS Data Pipeline
      Layanan itu masuk ke “mode pemeliharaan,” dan akses konsolnya juga dihapus awal tahun ini

  • Bagian yang mengatakan “10 tahun lalu, di keynote re:Invent 2013, kami mengatakan ingin mendukung baik workload hari ini maupun workload besok, dan komitmen kami pada Classic adalah bukti terbaiknya” persis menunjukkan alasan perusahaan memercayai AWS
    Tim EC2 terus menjalankan Classic dengan baik sampai semua instance dihentikan atau dimigrasikan, dan menurut saya hal seperti inilah yang membangun kepercayaan

  • Saya masih ingat ketika bekerja di Serif, saat kami membutuhkan web hosting untuk situs web media sosial baru yang akan diintegrasikan dengan perangkat lunak desktop scrapbook
    Saat itu, seperti biasanya, ada banyak teknologi baru yang berkilau, salah satunya Microsoft Silverlight, dan kami mengimplementasikan “Deep Zoom” di situs web agar pengguna bisa memperbesar scrapbook yang dipublikasikan dengan mudah dan melihat detailnya
    Teknologi baru lainnya adalah AWS, dan karena EC2 baru saja diluncurkan, cukup mengasyikkan bahwa dengan satu tombol kami bisa menjalankan instance di AS, Irlandia, dan Amsterdam, lalu jika mati cukup menekan tombol lagi untuk membuat yang baru
    Sama seperti sekarang, saat itu pun di balik UI yang sederhana tersembunyi kompleksitas yang cukup besar, dan kami harus mempelajari berbagai jenis storage serta mana yang persisten
    Instance EC2 awal rasanya tidak sestabil sekarang, dan memang kami pernah kehilangan satu atau dua instance sepenuhnya sehingga harus membuat ulang, jadi kami banyak membuat snapshot
    Tidak ada infrastructure as code atau DevOps, tetapi kami membuat klaster high availability sendiri, dan seorang engineer yang bekerja bersama kami menulis dari nol dalam C++ untuk memantau database di beberapa instance EC2 dan menjaga klaster tetap hidup
    Saat itu juga belum ada cloud architect, jadi kami tidak benar-benar tahu apa yang kami lakukan atau apa yang bijak, tetapi teknologinya bekerja sangat baik, dan setelah melewati trial and error awal, kami membangun komunitas internet yang cukup aktif
    Situs webnya dibuat dengan PHP dan MySQL, XML yang dibuat dari data relasional SQL diubah menjadi HTML dengan XSLT, dan JavaScript tidak banyak dipakai selain kira-kira jQuery
    Deployment mungkin dilakukan dengan mengunggah lewat FileZilla, lalu perangkat lunak klaster C++ mereplikasi file yang diunggah ke instance EC2 lain di availability zone berbeda
    Kalau dipikir lagi, mungkin tidak perlu menaruh server di tiga availability zone, tetapi pekerjaan itu benar-benar menyenangkan dan merupakan masa yang baik yang memperkenalkan saya pada AWS

    • Saya ingat masa itu
      AWS belum punya lapisan database, jadi untuk durabilitas kami memakai instance yang dipasangi Elastic Block Store

  • Sekarang yang dibutuhkan hanyalah benar-benar mengizinkan anggaran tetap, alih-alih kemungkinan tagihan kartu kredit meledak
    Microsoft melakukannya, dan seingat saya Google juga begitu, tetapi saya tidak tahu kenapa Amazon tidak melakukannya
    Saya juga sudah menunggu hal ini hampir 20 tahun

    • Kalau begitu, ekosistem konsultan optimasi biaya cloud mahal yang nyaris tidak melakukan apa pun selain menyalakan beberapa switch di konsol AWS akan runtuh
    • Jika melakukan itu, mereka akan menghasilkan lebih sedikit uang, dan pelanggan AWS tidak terlalu sensitif terhadap harga
    • Tidak persis sama, tetapi Anda bisa mengatur alarm penagihan dan notifikasi anggaran

  • Secara pribadi, saya berharap AWS mengambil keputusan saja dan memasang IPv6 pada Classic lalu terus melanjutkannya
    Ironisnya, post-Classic terlihat seperti kemunduran, dan jauh lebih mirip dengan infrastruktur yang harus kami tangani sebelum cloud
    Sebagian besar hal baru yang saya buat sekarang berjalan di atas Cloudflare, jadi saya hampir tidak memikirkan subnet, VPC, dan semacamnya lagi

    • Cara mengembangkan bisnis EC2 bukan hanya dengan menarik startup baru, tetapi juga membawa perusahaan lama ke cloud
      Mereka semua perlu terintegrasi dengan jaringan internal, sehingga VPC menjadi diperlukan

  • Kalau pemahaman saya benar, saya penasaran apakah semua instance Classic dipindahkan ke tipe yang lebih modern tanpa campur tangan pemilik akun
    Saya juga penasaran apakah dalam proses itu ada reboot, atau ditangani dengan live migration
    Karena sulit menambahkan live migration pada platform virtualisasi yang awalnya tidak dirancang untuk itu
    Saya juga penasaran apakah konfigurasi jaringan lama masih diemulasikan, atau apakah sebagian aplikasi pelanggan mungkin jadi rusak

    • Tidak, migrasi membutuhkan campur tangan pemilik akun
      Detailnya ada di sini: https://aws.amazon.com/blogs/aws/ec2-classic-is-retiring-her...
      AWS tampaknya menghabiskan waktu, tenaga, dan uang untuk memindahkan pelanggan dari EC2-Classic, dan juga cukup banyak berupaya mengotomatiskan prosesnya serta membuatnya tidak terlalu menyakitkan
      Contoh: https://repost.aws/knowledge-center/ssm-migrate-ec2classic-v...
      Jaringan lama berubah dari model semua orang berada di subnet yang sama menjadi model masing-masing mendapatkan subnet sendiri, jadi aplikasi pelanggan memang bisa rusak
      Seperti ketika nameserver mati lalu orang meng-hardcode alamat IP di /etc/hosts dan lupa mengembalikannya kemudian; orang terkadang melakukan hal-hal yang tidak terlalu cerdas karena alasan yang cukup masuk akal
      Untuk melakukan migrasi seperti ini dengan baik, perlu ada cambuk dan wortel
      Cambuknya adalah bahwa pada akhirnya layanan akan dihentikan dan penyediaannya ditolak, sedangkan wortelnya adalah otomasi, pengingat berulang bahwa jendela pemeliharaan diperlukan, panduan yang jelas, dan terutama kemauan untuk benar-benar berbicara dengan pelanggan serta merespons mereka
    • Bukan hanya perlu restart, tetapi juga harus melakukan rekonfigurasi jaringan
      Namun AWS memberi orang waktu bertahun-tahun untuk melakukannya, dan jika perlu mendatangi semua pengguna serta membantu mereka
    • Tidak sepenuhnya jelas, tetapi menurut interpretasi saya AWS menghubungi semua pemilik akun, meyakinkan mereka agar bermigrasi dengan satu atau lain cara, lalu setelah semuanya pindah barulah menutupnya
      Mungkin ada diskon atau ancaman penghentian
      Mengejutkan bahwa tidak ada satu pun instance yang pemiliknya lupa atau menolak melakukan pekerjaan itu, jadi saya benar-benar tertarik bagaimana ini bisa terjadi
      Kedaluwarsanya kartu kredit mungkin menjadi kuncinya; kemungkinan besar sebagian besar akun yang terlupakan dinonaktifkan secara otomatis
    • Saya tidak tahu detail migrasi khusus ini, tetapi dulu saya pernah menjalankan VM tier murah selama beberapa tahun, dan akhirnya AWS mengirim email bahwa mereka akan menghentikannya karena alasan pemeliharaan
      Mungkin caranya mirip
      VM sulit dipindahkan secara otomatis kecuali dikonfigurasi khusus agar dapat dipindahkan; misalnya urutan perangkat pada bus PCIe bisa berubah, dan berbagai ID mesin seperti alamat MAC juga bisa berubah
      Jika tidak dipastikan bahwa VM tidak terpengaruh oleh perubahan seperti ini, kemungkinan besar akan muncul masalah setelah dipindahkan

  • Tingkat dukungan seperti ini seharusnya menjadi tujuan semua perusahaan perangkat lunak
    Inilah yang ingin dilihat pelanggan enterprise, dan inilah yang mereka bayar

    • Alasan perusahaan-perusahaan tempat saya bekerja terus memilih AWS bukan karena fitur yang disediakan lebih baik, melainkan karena dukungannya jauh lebih unggul