Tạm biệt EC2-Classic, đó là một quãng thời gian tuyệt vời
(allthingsdistributed.com)- AWS đã tắt instance cuối cùng của EC2-Classic vào ngày 15/8/2023, khép lại mô hình điện toán đám mây ban đầu đã bắt đầu từ khi EC2 ra mắt năm 2006
- Cốt lõi của Classic là mạng phẳng đơn 10.0.0.0/8, và điểm đổi mới vào thời điểm đó là giúp việc cấp phát compute trở nên đơn giản trong khi che giấu phần triển khai nội bộ phức tạp
- Năm 2006, m1.small cung cấp vCPU tương đương Xeon 1.7GHz, 1.75GB RAM, 160GB đĩa cục bộ, mạng 250Mb/s với giá $0.10 mỗi giờ; sau đó EC2 đã mở rộng tới các instance cỡ lớn như P3dn.24xlarge
- Elastic IP, Auto Scaling, Load Balancing, CloudWatch và các loại instance mới đã được bổ sung, và đến năm 2013 VPC trở thành tiêu chuẩn mới cho vùng đám mây có thể cô lập và định nghĩa theo từng khách hàng
- Classic vẫn được duy trì thêm 10 năm sau khi xuất hiện các nền tảng ảo hóa mới như Nitro vì khách hàng còn sử dụng, và tài liệu, công cụ cũng như hỗ trợ vẫn được cung cấp cho tới khi mọi instance được tắt hoặc di chuyển
EC2-Classic kết thúc và cấu trúc ban đầu
- AWS từ lâu đã tiếp cận rất thận trọng khi ngừng các dịch vụ mà hoạt động kinh doanh của khách hàng đang phụ thuộc
- SimpleDB vẫn tiếp tục được cung cấp ngay cả sau khi DynamoDB đã trở thành lựa chọn cơ sở dữ liệu “NoSQL” của khách hàng
- Hai năm sau thông báo nghỉ hưu EC2-Classic của Jeff Barr, instance cuối cùng của Classic đã bị tắt vào ngày 15/8/2023
- EC2 đã vận hành gần 17 năm, và trong số các dịch vụ AWS chỉ có SQS và S3 là lâu đời hơn EC2
- Yếu tố phân biệt lớn nhất của “Classic” là kiến trúc mạng
- Năm 2006, EC2 bắt đầu với một mạng khổng lồ duy nhất là 10.0.0.0/8
- Mọi instance chạy trong một mạng phẳng đơn được chia sẻ với khách hàng khác
- Nó cung cấp các tính năng như security group và Public IP được gán khi khởi chạy instance
- Ngăn xếp nội bộ rất phức tạp, nhưng người dùng có thể cấp phát compute cần thiết một cách đơn giản
Sự thay đổi về hiệu năng instance
- Năm 2006, khi chạy instance m1.small, bạn có thể dùng cấu hình sau
- CPU ảo tương đương bộ xử lý Xeon 1.7GHz
- 1.75GB RAM
- 160GB đĩa cục bộ
- Băng thông mạng 250Mb/s
- $0.10 mỗi giờ
- Sau đó EC2 đã mở rộng tới các instance như P3dn.24xlarge
- Thông lượng mạng 100Gbps
- 96 vCPU
- 8 GPU NVIDIA v100 Tensor Core với 32GiB bộ nhớ mỗi GPU
- 768GiB bộ nhớ hệ thống
- 1.8TB lưu trữ SSD cục bộ
- EFA để tăng tốc workload ML
- EC2-Classic đã biến phần cứng thành tài nguyên có thể lập trình, cho phép nhà phát triển, nhà sáng lập, startup và doanh nghiệp sử dụng lượng compute họ muốn khi cần
- Những phức tạp như quản lý hạ tầng, mua phần cứng mới, nâng cấp phần mềm, thay ổ đĩa hỏng đã được trừu tượng hóa
Chuyển đổi sang VPC và hỗ trợ dài hạn
- Blog này đã được chuyển sang m1.small ngay sau khi EC2 ra mắt, chạy Moveable Type và cơ sở dữ liệu cục bộ
- Sau đó nó được chuyển thành dịch vụ có tính sẵn sàng cao với các tính năng như RDS failover
- Sau khi tính năng Website của Amazon S3 ra mắt năm 2011, nó đã được chuyển sang nền tảng S3
- Sau đó nó đã vận hành ở trạng thái “serverless” trong 12 năm
- Khi nhu cầu khách hàng tăng lên, Elastic IP, Auto Scaling, Load Balancing, CloudWatch và nhiều loại instance mới đã được bổ sung
- Năm 2013, VPC được kích hoạt, cho phép mỗi khách hàng AWS quản lý một vùng đám mây an toàn, cô lập và được định nghĩa phù hợp với doanh nghiệp của họ
- VPC trở thành tiêu chuẩn mới, cung cấp mức độ kiểm soát để khách hàng xây dựng các hệ thống toàn diện hơn trên đám mây
- Ngay cả sau khi EC2 tiến hóa sang nền tảng ảo hóa mới là Nitro, Classic vẫn được hỗ trợ thêm 10 năm vì khách hàng còn sử dụng
- Đội ngũ EC2 duy trì vận hành cho tới khi mọi instance Classic được tắt hoặc di chuyển xong
- Trong suốt quá trình đó, tài liệu, công cụ, hỗ trợ từ đội ngũ kỹ sư và hỗ trợ từ đội quản lý tài khoản đều được cung cấp
- Việc EC2-Classic kết thúc cho thấy đám mây đã thay đổi rất nhiều kể từ năm 2006, đồng thời nhắc rằng cần xây dựng các hệ thống có thể tiến hóa và xem lại kiến trúc với góc nhìn cởi mở
1 bình luận
Các ý kiến trên Hacker News
EC2-Classic từng như phép màu
Cuối cùng cũng có cảm giác ta đã đến một tương lai nơi phần mềm chịu trách nhiệm về networking, và có thể quên đi sự phức tạp cũ kỹ của thời phải tạo mạng bằng dây cáp
So với subnet IP truyền thống, cloud vận hành xoay quanh security group; nếu có thêm vài tính năng như cấu trúc phân cấp, có lẽ nó đã có thể thay thế hoàn toàn vai trò subnet trong networking truyền thống
Dùng EC2-Classic lâu rồi thì thấy network engineering dễ và thú vị, còn cách VPC mới thì phức tạp đến mức làm mất hứng, và cũng không rõ nó cho phép làm được điều gì mà security group không biểu đạt được
Trước đây tôi từng viết chi tiết hơn, hoặc tùy tâm trạng mà gay gắt hơn, nhưng cảm xúc lớn nhất khi chuyển khỏi EC2-Classic là sự thất vọng khi người khác làm một thứ đang ổn trở nên tệ hơn
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
Ở phía sau AWS tự tạo VPC cho bạn, và cho đến khi người dùng cố ý “đập kính khi khẩn cấp” để đụng vào cấu hình VPC, bạn có thể dùng gần như giống Classic cũ
https://aws.amazon.com/vpc/lattice/
Tuy nhiên nó tiến xa hơn việc chỉ đặt security group lên một mạng phẳng: mỗi HTTP endpoint tự động trở thành một tài nguyên IAM, mọi service được xử lý như AWS native và có thể dùng cùng IAM policy, nên cũng khá ổn
Có thể thêm một mục duy nhất trong bảng định tuyến nội bộ để đi tới AWS mà không phải qua Internet công cộng; cấu hình kiểu này sẽ có vấn đề trên một mạng phẳng dùng chung
Tôi hiểu là cần VPC khi tích hợp với mạng nội bộ, VPN, v.v., nhưng trên thực tế thường có những trường hợp không cần VPC chút nào mà nó vẫn làm mọi thứ phức tạp quá mức
Cách ghi IPv4 trong đoạn trích hơi gây nhầm lẫn
Có câu “khi ra mắt EC2 năm 2006, đó là một mạng khổng lồ 10.2.0.0/8”; theo tôi hiểu, /8 nghĩa là chỉ octet đầu cố định, tức phạm vi 10.0.0.0~10.255.255.255
Vậy thì không hiểu số 2 ở đây quan trọng ở điểm nào, và nếu số 2 quan trọng thì chẳng phải nên viết là /16 sao
Xét nguồn và mức độ chắc chắn của tôi về ký pháp này, tôi cũng tò mò liệu có ý nghĩa nào khác mà chuyên gia sẽ đọc ra được không; nếu chỉ là lỗi đánh máy thì xin lỗi vì đã bắt bẻ quá kỹ
Đáng ra phải là 10.0.0.0/8; tôi đã sửa trên blog, đồng thời cũng chỉnh lại nhầm lẫn liên quan đến bộ nhớ của P3dn.24xlarge
Subnet lớn nhất có thể tạo bắt đầu từ 10.2.0.0 là 10.2.0.0/15
Tôi nghĩ có thể không hẳn là lỗi đánh máy, mà là một cách viết kỳ lạ cho 10.0.0.0/8 ngoại trừ 10.1.0.0/16
Tôi diễn giải ý tác giả là các máy nhận địa chỉ 10.2/16, nhưng vẫn có thể định tuyến tới các AWS service hoặc máy ở những subnet 10/8 khác như 10.1/16
“Sự phức tạp của quản lý hạ tầng, mua phần cứng mới, nâng cấp phần mềm, thay đĩa hỏng đã được trừu tượng hóa”, nhưng chỗ đó chỉ được thay bằng sự phức tạp của AWS mà thôi
Ngay cả trước AWS, ta cũng không cần tự mua phần cứng hay tự thay đĩa hỏng; các công ty web hosting làm việc đó
Tất nhiên bạn không trực tiếp vào data center để thay đĩa, nhưng quy trình đó rất khác với cách bạn có được trên AWS
Ngay cả hiện nay vẫn có nhiều công ty web hosting vận hành theo cách cũ, nhưng có lý do khiến mọi người chuộng các dịch vụ như AWS
Điều đó rất khác với khả năng bấm vài nút để dựng một server mới trên phần cứng riêng
Nếu chỉ cần VPS thì dùng VPS là được, và cá nhân tôi thích Hetzner hơn trong trường hợp đó
Nhưng để xử lý nhu cầu của các tổ chức lớn, AWS buộc phải phức tạp
Ngoài ra, giao diện khởi tạo EC2 trên AWS console đã tốt lên rất nhiều và xử lý thay bạn một lượng phức tạp đáng kể
Oracle, bất chấp đủ loại tiếng xấu, vẫn đang kiếm hàng chục tỷ USD
Tôi đang đọc đến câu “Việc ngừng một dịch vụ không phải là điều AWS hay làm, và khá hiếm gặp”, đúng lúc đang nghỉ giữa một epic chuyển đồ của chúng tôi khỏi OpsWorks trước khi dịch vụ này ngừng vào tháng 5
Trước khi Kubernetes và Terraform xuất hiện, tôi đã tạo vài cụm bằng OpsWorks
Tuy vậy, theo những gì tôi nghe từ người của AWS, nội bộ dịch vụ này không được bảo trì tốt và phần phía sau khá lộn xộn, nên cũng không quá ngạc nhiên khi nó bị ngừng trong bối cảnh cục diện công nghệ đã thay đổi rất nhiều so với lúc dịch vụ mới ra mắt
RIP OpsWorks
Tiêu đề là “Chúng tôi làm X”, nhưng phần nội dung lại đọc như “Chúng tôi không làm X ở đây”, nên ban đầu tôi không hiểu rõ bài viết muốn nói gì
Dịch vụ đó đã vào “chế độ bảo trì” và hồi đầu năm nay quyền truy cập console cũng bị gỡ bỏ
Đoạn “Trong keynote re:Invent năm 2013, 10 năm trước, chúng tôi nói muốn hỗ trợ cả workload của hôm nay lẫn workload của ngày mai, và cam kết với Classic là minh chứng rõ nhất cho điều đó” chính là lý do các doanh nghiệp tin tưởng AWS
Đội EC2 đã tiếp tục vận hành Classic thật tốt cho đến khi mọi instance được chấm dứt hoặc di trú, và tôi nghĩ những việc như thế tạo nên niềm tin
Tôi vẫn nhớ hồi làm ở Serif, khi chúng tôi cần web hosting cho một trang mạng xã hội mới sẽ tích hợp với phần mềm scrapbook trên desktop
Khi đó, như mọi khi, có rất nhiều công nghệ mới bóng bẩy, một trong số đó là Microsoft Silverlight, và chúng tôi đã triển khai “Deep Zoom” trên website để người dùng có thể dễ dàng phóng to các scrapbook đã đăng và xem chi tiết
Một công nghệ mới khác là AWS; EC2 vừa mới ra mắt, nên việc có thể bấm một nút để dựng instance ở Mỹ, Ireland, Amsterdam, rồi nếu nó chết thì lại bấm nút để dựng cái mới, thật khá phấn khích
Cũng như bây giờ, đằng sau UI đơn giản khi ấy là rất nhiều độ phức tạp, và chúng tôi phải học về nhiều loại storage cũng như loại nào là persistent
Các instance EC2 thời đầu có vẻ không ổn định như bây giờ, và thực tế chúng tôi đã mất hẳn một hai instance và phải tạo lại, nên đã chụp rất nhiều snapshot
Khi đó chưa có infrastructure as code hay DevOps, nhưng chúng tôi đã tự tạo cụm high availability; một kỹ sư làm cùng đã viết từ đầu bằng C++ để giám sát database trên nhiều instance EC2 và giữ cho cụm sống sót
Thời đó cũng chưa có cloud architect, nên chúng tôi không thật sự biết mình đang làm gì hay điều gì là khôn ngoan, nhưng công nghệ hoạt động rất tốt, và sau những thử-sai ban đầu, chúng tôi đã xây được một cộng đồng Internet khá sôi động
Website được làm bằng PHP và MySQL; XML tạo từ dữ liệu quan hệ trong SQL được chuyển thành HTML bằng XSLT; JavaScript không nhiều, chủ yếu chỉ dùng jQuery
Việc deploy có lẽ là upload bằng FileZilla, rồi phần mềm cluster C++ sẽ sao chép các file đã upload sang những instance EC2 ở các availability zone khác
Nhìn lại thì có lẽ chúng tôi không cần đặt server ở ba availability zone, nhưng công việc đó thật sự rất vui và đó là quãng thời gian tốt đẹp giúp tôi lần đầu tiếp xúc với AWS
AWS chưa có tầng database, nên để có độ bền dữ liệu, chúng tôi dùng instance gắn Elastic Block Store
Giờ điều cần thiết chỉ là thực sự cho phép có ngân sách cố định, thay vì khả năng hóa đơn thẻ tín dụng tăng vọt
Microsoft đang làm vậy và tôi nhớ Google cũng từng làm, nhưng không hiểu vì sao Amazon không làm
Tôi cũng đã chờ chuyện này gần 20 năm rồi
Cá nhân tôi thì ước gì AWS cứ quyết đoán và gắn IPv6 cho Classic rồi tiếp tục duy trì nó
Trớ trêu là post-Classic trông như một bước lùi, và trở nên giống hơn nhiều với hạ tầng mà chúng ta từng phải xử lý trước thời cloud
Hầu hết những thứ mới tôi xây đều đặt trên Cloudflare, nên giờ gần như không còn nghĩ nhiều đến subnet, VPC nữa
Tất cả những doanh nghiệp này đều phải tích hợp với mạng nội bộ, vì vậy họ cần VPC
Nếu tôi hiểu đúng, tôi thắc mắc liệu tất cả các instance Classic đã được chuyển sang loại hiện đại hơn mà không cần sự can thiệp của chủ tài khoản hay không
Tôi cũng tò mò trong quá trình đó có phải reboot không, hay được xử lý bằng live migration
Vì rất khó để rút live migration ra từ một nền tảng ảo hóa vốn không được thiết kế với điều đó trong đầu
Tôi cũng thắc mắc liệu cấu hình mạng ban đầu vẫn còn được giả lập, hay một số ứng dụng của khách hàng có thể đã bị hỏng
Chi tiết ở đây: https://aws.amazon.com/blogs/aws/ec2-classic-is-retiring-her...
Có vẻ AWS đã bỏ thời gian, nhân lực và tiền bạc để chuyển khách hàng khỏi EC2-Classic, và cũng nỗ lực khá nhiều để tự động hóa quy trình, làm nó đỡ đau đớn hơn
Ví dụ: https://repost.aws/knowledge-center/ssm-migrate-ec2classic-v...
Mạng ban đầu đã chuyển từ mô hình mọi người ở cùng một subnet sang mô hình mỗi người có subnet riêng, nên ứng dụng của khách hàng thực sự có thể bị hỏng
Kiểu như khi nameserver chết thì hardcode địa chỉ IP vào /etc/hosts rồi sau đó quên hoàn tác; con người đôi khi làm những việc không mấy khôn ngoan vì những lý do đủ chính đáng
Muốn làm tốt kiểu migration này thì cần cả cây gậy lẫn củ cà rốt
Cây gậy là cuối cùng sẽ ngừng dịch vụ và từ chối cung cấp nữa, còn củ cà rốt là tự động hóa, nhắc đi nhắc lại rằng cần có maintenance window, hướng dẫn rõ ràng, và hơn hết là thiện chí thực sự nói chuyện với khách hàng và phản hồi họ
Tuy vậy AWS đã cho mọi người nhiều năm để làm việc đó, và nếu cần thì họ tìm đến từng người dùng để hỗ trợ
Có thể đã có giảm giá hoặc đe dọa chấm dứt dịch vụ
Điều đáng ngạc nhiên là không có dù chỉ một instance nào bị chủ sở hữu quên hoặc từ chối xử lý, nên tôi thật sự thấy thú vị là họ đã làm được điều đó như thế nào
Việc thẻ tín dụng hết hạn có thể là điểm then chốt, vì có khả năng phần lớn các tài khoản bị bỏ quên đã tự động bị vô hiệu hóa
Có lẽ cách làm cũng tương tự
VM rất khó tự động di chuyển nếu không được cấu hình đặc biệt để có thể di chuyển; ví dụ thứ tự thiết bị trên bus PCIe có thể thay đổi, và nhiều ID máy như địa chỉ MAC cũng có thể đổi
Nếu không đảm bảo VM không bị ảnh hưởng bởi những thay đổi này, khả năng cao là sau khi di chuyển sẽ phát sinh vấn đề
Mức độ hỗ trợ như thế này là điều mọi công ty phần mềm nên hướng tới
Đây chính là thứ khách hàng doanh nghiệp muốn thấy, và cũng là thứ họ sẵn sàng trả tiền