EC2-Classic’e Veda: Harika Bir Dönemdi
(allthingsdistributed.com)- AWS, 15 Ağustos 2023’te EC2-Classic’in son instance’ını kapatarak, 2006’da EC2’nin çıkışıyla başlayan erken dönem bulut bilişim modelinin işletimini sona erdirdi
- Classic’in özü 10.0.0.0/8 tek düzlemli ağdı; karmaşık iç uygulamayı gizleyip compute kapasitesi edinmeyi basitleştirmesi o dönem için bir inovasyondu
- 2006’da m1.small, saat başına $0.10 karşılığında 1.7GHz Xeon’a denk vCPU, 1.75GB RAM, 160GB yerel disk ve 250Mb/s ağ sunuyordu; EC2 daha sonra P3dn.24xlarge gibi büyük instance’lara genişledi
- Elastic IP, Auto Scaling, Load Balancing, CloudWatch ve yeni instance tipleri eklendi; 2013’te VPC, müşteri bazında izole ve tanımlanabilir bulut alanları için yeni standart haline geldi
- Classic, Nitro gibi yeni sanallaştırma platformlarından sonra bile müşteri kullanımı nedeniyle 10 yıl daha sürdürüldü; tüm instance’lar kapatılana veya migrate edilene kadar dokümantasyon, araçlar ve destek devam etti
EC2-Classic’in Sona Ermesi ve İlk Mimari
- AWS, müşteri işlerinin bağlı olduğu hizmetleri sonlandırırken her zaman temkinli bir yaklaşım izledi
- SimpleDB, DynamoDB müşterilerin “NoSQL” DB seçenekleri arasında yerini aldıktan sonra bile sunulmaya devam ediyor
- Jeff Barr’ın EC2-Classic’in sona ereceğini duyuran yazısından 2 yıl sonra, 15 Ağustos 2023’te Classic’in son instance’ı kapatıldı
- EC2 neredeyse 17 yıl boyunca çalıştı; AWS servisleri arasında yalnızca SQS ve S3, EC2’den daha eski
- “Classic”i ayıran en büyük unsur ağ mimarisiydi
- 2006’da EC2, 10.0.0.0/8’den oluşan devasa tek bir ağ olarak başladı
- Tüm instance’lar, diğer müşterilerle paylaşılan tek düzlemli bir ağ üzerinde çalışıyordu
- Security group’lar ve instance başlatılırken atanan Public IP gibi özellikler sağlıyordu
- İç stack son derece karmaşıktı, ancak kullanıcılar ihtiyaç duydukları compute kapasitesini basitçe elde edebiliyordu
Instance Performansındaki Değişim
- 2006’da bir m1.small instance çalıştırdığınızda şu yapılandırmayı kullanabiliyordunuz
- 1.7GHz Xeon işlemciye denk sanal CPU
- 1.75GB RAM
- 160GB yerel disk
- 250Mb/s ağ bant genişliği
- Saat başına $0.10
- Daha sonra EC2, P3dn.24xlarge gibi instance’lara genişledi
- 100Gbps ağ throughput’u
- 96 vCPU
- 32GiB belleğe sahip 8 adet NVIDIA v100 Tensor Core GPU
- 768GiB sistem belleği
- 1.8TB yerel SSD depolama
- ML iş yüklerini hızlandırmak için EFA
- EC2-Classic, donanımı programlanabilir bir kaynağa dönüştürerek geliştiricilerin, girişimcilerin, startup’ların ve enterprise’ların ihtiyaç duydukları anda istedikleri kadar compute kullanabilmesini sağladı
- Altyapı yönetimi, yeni donanım satın alma, yazılım yükseltmeleri ve arızalı disk değiştirme gibi karmaşıklıklar soyutlandı
VPC’ye Geçiş ve Uzun Vadeli Destek
- Bu blog, EC2’nin çıkışından kısa süre sonra m1.small’a taşındı ve Moveable Type ile yerel bir veritabanı çalıştırdı
- Daha sonra RDS failover gibi özelliklere sahip yüksek erişilebilirlikli bir servise dönüştü
- 2011’de Amazon S3 Website özelliği yayımlandıktan sonra S3 tabanlı yapıya geçti
- Sonraki 12 yıl boyunca “serverless” olarak çalıştı
- Müşteri ihtiyaçları arttıkça Elastic IP, Auto Scaling, Load Balancing, CloudWatch ve çeşitli yeni instance tipleri eklendi
- 2013’te VPC etkinleşti ve her AWS müşterisi güvenli, izole ve işine göre tanımlanmış bir bulut alanını yönetebilir hale geldi
- VPC yeni standart oldu ve müşterilere bulutta daha kapsamlı sistemler kurabilmeleri için gerekli kontrol seviyesini sundu
- EC2, Nitro adlı yeni sanallaştırma platformuna evrildikten sonra bile Classic, müşteri kullanımı nedeniyle 10 yıl daha desteklendi
- EC2 ekibi, tüm Classic instance’lar kapatılana veya migrate edilene kadar operasyonu sürdürdü
- Süreç boyunca dokümantasyon, araçlar, mühendislik ekiplerinden destek ve hesap yönetimi ekiplerinden destek sağlandı
- EC2-Classic’in sona ermesi, bulutun 2006’dan bu yana büyük ölçüde değiştiğini gösteriyor; evrilebilir sistemler kurmak ve mimariyi açık bir bakışla yeniden değerlendirmek gerekiyor
1 yorum
Hacker News yorumları
EC2-Classic sihir gibiydi
Sonunda yazılımın ağ işini üstlendiği, kablolarla ağ kurulan dönemlerin eski karmaşıklığını unutabileceğimiz geleceğe gelmişiz gibi hissettiriyordu
Bulut, geleneksel IP alt ağlarından ziyade güvenlik grupları etrafında çalışıyordu; hiyerarşi gibi birkaç özellik daha olsaydı, geleneksel ağlardaki alt ağ rolünü tamamen ikame edebilirdi gibi geliyordu
EC2-Classic’i uzun süre kullanınca ağ mühendisliği kolay ve eğlenceliydi; yeni VPC yaklaşımı ise karmaşık, insanın hevesini kırıyor ve güvenlik gruplarıyla ifade edilemeyen neyi mümkün kıldığını da pek anlayamıyorum
Daha önce de daha ayrıntılı, hatta ruh hâlime göre daha sert yazmıştım; ama EC2-Classic’ten geçerken en baskın his, başkaları sapasağlam çalışan bir şeyi daha kötü hâle getirdiğinde duyulan hayal kırıklığıydı
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
Arka planda AWS VPC’yi kendisi oluşturuyor ve kullanıcı, “camı kırma” türü acil bir müdahale gibi VPC ayarlarına özellikle dokunmadığı sürece eski Classic’e neredeyse aynı şekilde kullanılabiliyor
https://aws.amazon.com/vpc/lattice/
Ancak düz bir ağın üstüne güvenlik grupları koymaktan daha ileri gidiyor: her HTTP endpoint’i otomatik olarak bir IAM kaynağı oluyor, tüm servisler AWS yerel servisleri gibi ele alınıyor ve aynı IAM politikaları kullanılabiliyor; bu açıdan oldukça iyi
Genel internete çıkmadan, şirket içi yönlendirme tablosuna AWS’ye giden tek bir kayıt ekleyebiliyorsunuz; paylaşımlı düz bir ağda böyle bir kurulum sorun olurdu
Şirket içi ağ, VPN vb. ile entegrasyon yaparken VPC’ye ihtiyaç olduğunu anlıyorum; ama pratikte VPC’ye hiç gerek olmadığı hâlde işleri sık sık gereğinden fazla karmaşıklaştırıyor
Alıntıdaki IPv4 gösterimi kafa karıştırıcı
“2006’da EC2’yi başlattığımızda 10.2.0.0/8 şeklinde tek dev bir ağdı” deniyor; benim anladığım kadarıyla /8 ise yalnızca ilk oktet sabit olur ve aralık 10.0.0.0–10.255.255.255 olur
Öyleyse buradaki 2’nin neden önemli olduğunu bilmiyorum; 2 önemliyse /16 olarak yazılması gerekmez mi diye düşünüyorum
Kaynak ve notasyona dair kendi eminliğimi düşününce, uzmanların buradan çıkaracağı başka bir anlam olabilir diye merak ediyorum; eğer basit bir yazım hatasıysa fazla didiklemiş gibi olduysam kusura bakmayın
10.0.0.0/8 olmalıydı; blogda düzelttik, P3dn.24xlarge’ın belleğiyle ilgili karışıklığı da birlikte giderdik
10.2.0.0’dan başlayarak oluşturulabilecek en büyük alt ağ 10.2.0.0/15’tir
Yazım hatasından ziyade, 10.1.0.0/16 hariç 10.0.0.0/8’i garip bir şekilde yazmış olabilir diye düşünüyorum
Yazarın, makinelerin 10.2/16 adresi aldığını ama 10.1/16 gibi diğer 10/8 alt ağlarındaki AWS servislerine veya makinelere de yönlendirme yapılabildiğini kastettiği şeklinde yorumladım
“Altyapı yönetimi, yeni donanım satın alma, yazılım yükseltmeleri, arızalı diskleri değiştirme karmaşıklığı soyutlandı” deniyor; ama bunun yerine sadece AWS’nin karmaşıklığı geldi
AWS’den önce de donanımı bizzat satın almak ya da bozulan diski kendiniz değiştirmek zorunda değildiniz; web hosting şirketleri bunu yapıyordu
Elbette veri merkezine bizzat girip disk değiştirmiyordunuz; ama süreç, AWS’de elde ettiğiniz yöntemden çok farklıydı
Bugün hâlâ eski yöntemle çalışan birçok web hosting şirketi var, ama insanların AWS gibi servisleri tercih etmesinin bir nedeni var
Birkaç düğmeyle ayrı donanımda yeni bir sunucu ayağa kaldırabilme yeteneğiyle arasında büyük fark var
İhtiyacınız olan tek şey VPS ise VPS kullanırsınız; kişisel olarak bu durumda Hetzner’i daha çok seviyorum
Ama büyük organizasyonların ihtiyaçlarını karşılamak için AWS’nin karmaşık olması kaçınılmaz
Ayrıca AWS konsolundaki EC2 başlatma arayüzü gerçekten çok gelişti ve ciddi miktarda karmaşıklığı sizin yerinize yönetiyor
Oracle da onca itibar sorununa rağmen hâlâ milyarlarca dolar kazanıyor
“Bir servisi kapatmak AWS’nin yaptığı bir şey değildir ve oldukça nadirdir” cümlesini okuyordum; tam da mayıstaki kapanıştan önce OpsWorks’ten bizim şeyleri taşımaya yönelik epik bir işi yaparken mola vermiştim
Kubernetes ve Terraform ortaya çıkmadan önce birkaç cluster’ı OpsWorks ile kurmuştum
Ancak AWS çalışanlarından duyduğuma göre içeride bakımı pek iyi yapılmıyormuş ve arka tarafı epey dağınıkmış; bu yüzden servis ilk çıktığındaki dönemle teknoloji ortamının ciddi biçimde değiştiği bugün kapatılması şaşırtıcı değil
RIP OpsWorks
Başlık “X yapıyoruz” diyor ama metin “burada X yapmıyoruz” gibi okunuyor; bu yüzden başta yazının ne anlatmaya çalıştığını pek anlayamadım
O servis “bakım modu”na alındı ve bu yılın başında konsol erişimi de kaldırıldı
“10 yıl önce, 2013 re:Invent keynote’unda bugünün iş yüklerini de yarının iş yüklerini de desteklemek istediğimizi söylemiştik; Classic’e bağlılığımız bunun en iyi kanıtı” kısmı, şirketlerin AWS’ye güvenmesinin nedeni tam da bu
EC2 ekibi tüm instance’lar kapatılana veya migrate edilene kadar Classic’i düzgün biçimde çalıştırmaya devam etti; bence güven böyle şeylerle oluşuyor
Serif’te çalışırken, scrapbook masaüstü yazılımıyla entegre olacak yeni bir sosyal medya sitesi için web hosting’e ihtiyaç duyduğumuz zamanı hâlâ hatırlıyorum
O dönem her zamanki gibi parlayan birçok yeni teknoloji vardı; bunlardan biri Microsoft Silverlight’tı ve kullanıcıların yayımlanmış scrapbook’ları kolayca yakınlaştırıp ayrıntıları görebilmesi için web sitesinde “Deep Zoom”u uygulamıştık
Bir başka yeni teknoloji de AWS’ydi; EC2 daha yeni çıkmıştı ve tek bir düğmeyle ABD, İrlanda ve Amsterdam’da instance ayağa kaldırabilmek, ölürse tekrar düğmeye basıp yenisini açabilmek oldukça heyecan vericiydi
Bugün olduğu gibi o zaman da basit bir UI’ın arkasında ciddi bir karmaşıklık gizliydi; farklı depolama türlerini ve hangilerinin kalıcı olduğunu öğrenmemiz gerekiyordu
İlk dönem EC2 instance’ları sanırım bugünkü kadar stabil değildi; gerçekten de bir veya ikisini tamamen kaybedip yeniden oluşturmamız gerekti, bu yüzden bol bol snapshot aldık
Infrastructure as Code ya da DevOps yoktu ama kendi yüksek erişilebilirlik cluster’ımızı kurduk; birlikte çalıştığım bir mühendis C++ ile sıfırdan bir şey yazıp birden fazla EC2 instance’ındaki veritabanlarını izliyor ve cluster’ın ayakta kalmasını sağlıyordu
O zamanlar cloud architect de yoktu; ne yaptığımızı, neyin akıllıca olduğunu pek bilmiyorduk ama teknoloji çok iyi çalıştı ve ilk deneme-yanılmaları atlattıktan sonra oldukça hareketli bir internet topluluğu oluşturduk
Web sitesi PHP ve MySQL ile yapılmıştı; SQL’deki ilişkisel veriden üretilen XML’i XSLT ile HTML’e dönüştürüyorduk, JavaScript çok yoktu, en fazla jQuery kullanıyorduk
Dağıtımı muhtemelen FileZilla ile yükleyerek yapıyorduk; ardından C++ cluster yazılımı yüklenen dosyaları diğer availability zone’lardaki EC2 instance’larına kopyalıyordu
Geriye bakınca üç availability zone’da sunucu bulundurmamıza gerek olmayabilirdi ama iş gerçekten çok eğlenceliydi ve AWS ile ilk tanışmamı sağlayan güzel zamanlardı
AWS’de veritabanı katmanı yoktu, bu yüzden dayanıklılık için Elastic Block Store bağlı instance’lar kullanıyorduk
Artık gereken tek şey, kredi kartı faturasının kontrolden çıkması ihtimali yerine sabit bütçeye gerçekten izin vermeleri
Microsoft bunu yapıyor, Google’ın da yaptığını hatırlıyorum; Amazon neden yapmıyor bilmiyorum
Bunu da neredeyse 20 yıldır bekliyorum
Şahsen AWS’nin kararlı davranıp Classic’e IPv6 ekleyerek devam etmesini isterdim
İronik biçimde post-Classic geriye gidiş gibi görünüyor ve buluttan önce uğraşmak zorunda olduğumuz altyapıya çok daha fazla benziyor
Yeni yaptıklarımın çoğunu Cloudflare üzerinde çalıştırdığım için artık subnet, VPC gibi şeyleri neredeyse hiç düşünmüyorum
Bunların hepsinin şirket içi ağlarıyla entegre olması gerektiğinden VPC gerekli hâle geliyor
Doğru anladıysam, tüm Classic instance’ların hesap sahibinin müdahalesi olmadan daha modern bir türe taşınıp taşınmadığını merak ediyorum
Bu süreçte yeniden başlatma olup olmadığını, yoksa canlı migrasyonla mı halledildiğini de merak ediyorum
Çünkü başlangıçta böyle bir şey düşünülmemiş bir sanallaştırma platformundan canlı migrasyonu çıkarmak zordur
Eski ağ ayarlarının hâlâ emüle edilip edilmediğini, yoksa bazı müşteri uygulamalarının bozulmuş olabileceğini de merak ediyorum
Ayrıntılar burada: https://aws.amazon.com/blogs/aws/ec2-classic-is-retiring-her...
AWS’nin müşterileri EC2-Classic’ten taşımak için zaman, insan gücü ve para harcadığı anlaşılıyor; süreci otomatikleştirmek ve daha az sancılı hâle getirmek için de epey çaba göstermiş
Örn: https://repost.aws/knowledge-center/ssm-migrate-ec2classic-v...
Eski ağ modeli herkesin aynı alt ağda olduğu modelden, herkesin kendi alt ağını aldığı modele dönüştüğü için müşteri uygulamaları gerçekten bozulabilirdi
Nameserver öldüğünde IP adreslerini /etc/hosts’a sabitleyip sonra geri almayı unutmak gibi, insanlar yeterli sebeplerle pek de akıllıca olmayan şeyler yapabiliyor
Böyle migrasyonları iyi yapmak için hem sopa hem havuç gerekir
Sopa, sonunda hizmeti durdurup sağlamayı reddedecek olmanızdır; havuç ise otomasyon, bakım penceresi gerektiğine dair yinelenen hatırlatmalar, net talimatlar ve her şeyden önemlisi müşteriyle gerçekten konuşup yanıt vermeye istekli olmaktır
Ancak AWS insanlara bunu yapmaları için yıllar verdi ve gerektiğinde tüm kullanıcıların peşine düşüp yardımcı oldu
İndirimler ya da kapatma tehdidi olmuş olabilir
Sahibinin unuttuğu ya da işlem yapmayı reddettiği tek bir instance bile olmaması şaşırtıcı; bunun nasıl mümkün olduğu gerçekten ilginç
Kredi kartı süresinin dolması kilit nokta olmuş olabilir; unutulmuş hesapların çoğunu otomatik olarak devre dışı bırakmış olmaları mümkün
Muhtemelen benzer bir yöntemdi
VM’ler taşınabilir olacak şekilde özel olarak yapılandırılmadıysa otomatik taşınmaları zordur; örneğin PCIe veri yolundaki cihazların sırası değişebilir ve MAC adresi gibi çeşitli makine kimlikleri de değişebilir
VM’in bu tür değişikliklerden etkilenmeyeceği garanti edilmezse, taşındıktan sonra sorun çıkma olasılığı yüksektir
Bu düzeyde destek seviyesi, tüm yazılım şirketlerinin hedeflemesi gereken şey
Kurumsal müşterilerin görmek istediği ve para ödediği şey tam olarak bu