- Colin Percival, phụ trách bảo mật của FreeBSD và nhà sáng lập Tarsnap, đã nhìn lại theo dòng thời gian hành trình 20 năm từ lúc tạo tài khoản AWS đầu tiên năm 2006 đến nay, trong vai trò người đóng góp bên ngoài chứ không phải nhân viên chính thức, tham gia sâu rộng vào sự phát triển của AWS từ việc xây dựng hỗ trợ FreeBSD trên EC2, chủ động phát hiện và báo cáo lỗ hổng bảo mật, cho tới phản hồi về thiết kế dịch vụ
- AWS thời kỳ đầu yêu cầu kích hoạt riêng từng dịch vụ; những dịch vụ được bật mặc định đầu tiên là Amazon SQS và Amazon E-Commerce Service ít người biết đến
- Để chạy FreeBSD trên EC2, cần giải quyết nhiều trở ngại kỹ thuật kéo dài nhiều năm như tương thích phiên bản Xen, hỗ trợ PAE, chuyển sang HVM; và đến năm 2010 mới chạy thành công lần đầu trên t1.micro
- Ông đã chủ động phát hiện và báo cáo nhiều vấn đề bảo mật như lỗ hổng xung đột chuẩn hóa trong cơ chế ký yêu cầu AWS, rủi ro lộ thông tin xác thực qua IMDS (đã trở thành hiện thực trong vụ xâm phạm Capital One năm 2019), và vấn đề bảo mật của Seekable OCI
- Từ năm 2024, ông tiếp tục duy trì FreeBSD/EC2 nhờ tài trợ GitHub Sponsors từ Amazon; đây là một trường hợp cho thấy người đóng góp bên ngoài vẫn có thể đạt kết quả nhờ hợp tác với các kỹ sư Amazon dù không có quyền truy cập hệ thống nội bộ
Tạo tài khoản AWS và các dịch vụ ban đầu
- Ngày 10 tháng 4 năm 2006, sau khi thấy thông báo ra mắt Amazon S3, ông đã tạo tài khoản AWS đầu tiên; động lực là sự quan tâm tới dịch vụ lưu trữ trực tuyến, cùng với kinh nghiệm xây dựng web service dựa trên HTTP từ năm 1998
- AWS thời kỳ đầu yêu cầu gửi yêu cầu kích hoạt riêng cho từng dịch vụ trong tài khoản; các dịch vụ mặc định chỉ có Amazon SQS và Amazon E-Commerce Service (API danh mục sản phẩm dành cho đối tác liên kết Amazon)
- Amazon E-Commerce Service thực chất là dịch vụ AWS đầu tiên, nhưng hầu như không được biết đến và cũng bị l quietly removed khỏi lịch sử AWS
Mối quan tâm ban đầu về bảo mật và phản hồi
- Dựa trên kinh nghiệm làm Security Officer của FreeBSD, ông lập tức quan tâm tới cấu trúc bảo mật của AWS; ông chỉ ra rằng các yêu cầu AWS được ký bằng API key để đảm bảo xác thực và toàn vẹn, nhưng phản hồi thì không có chữ ký
- Khi đó, gửi yêu cầu AWS qua HTTP là chuyện phổ biến nên khả năng sửa đổi phản hồi là rủi ro thực tế; ngay cả sau khi chuyển sang TLS, ông vẫn giữ quan điểm rằng ký đầu-cuối tốt hơn bảo mật ở tầng truyền tải
FreeBSD trên EC2 — những thách thức ban đầu
- Ngay sau khi Amazon EC2 ra mắt, với mục tiêu chạy FreeBSD, ông được Jeff Barr kết nối với người phụ trách nội bộ của Amazon và đầu năm 2007 đã ký Amazon NDA đầu tiên
- Khi đó Amazon vẫn dùng fax, nhưng vì ông không có máy fax nên phải gửi bản gốc đã ký qua đường bưu điện, khiến buổi briefing đầu tiên bị chậm lại
- EC2 ban đầu được phát hành không hỗ trợ kernel tùy biến (tương tự cách AWS Lambda hoạt động hiện nay); đến tháng 11 năm 2007, tính năng này được bật cùng với hỗ trợ Red Hat, và tài khoản FreeBSD cũng được phép truy cập API nội bộ để “đăng Amazon Kernel Images”
Kiểm toán bảo mật Xen và cảnh báo về tấn công side-channel
- Tháng 3 năm 2007, ông đề xuất với phía Amazon rằng cần có kiểm toán bảo mật cho Xen; khi không biết ai phù hợp để kiểm toán, ông đã giới thiệu Tavis Ormandy
- Cùng năm đó, Tavis báo cáo 2 lỗ hổng Xen (CVE-2007-1320, CVE-2007-1321), nhưng không rõ có liên quan trực tiếp tới lời giới thiệu này hay không
- Tại buổi gặp gỡ người dùng AWS trong Second Life do Jeff Barr tổ chức, ông đề nghị có ổ đĩa gốc chỉ đọc và tính năng đảm bảo xóa sạch bộ nhớ khi khởi động lại; mục tiêu là phục vụ kịch bản chạy mã không đáng tin cậy (xây dựng package FreeBSD), và EC2 Instance Attestation chỉ xuất hiện sau đó 18 năm
- Tại re:Invent 2012, ông giải thích nghiên cứu đánh cắp khóa RSA bằng HyperThreading cho một Principal Engineer của EC2, đồng thời khuyến nghị mạnh mẽ rằng không nên chạy song song các instance EC2 trên hai luồng của cùng một lõi CPU
- Người ta cho rằng đây là lý do nhiều họ instance EC2 bỏ qua kích thước “medium” và bắt đầu luôn ở 2 vCPU (“large”)
Eventual Consistency và đề xuất mang tính lý thuyết
- Cuối năm 2007, trong một bài blog được đọc rộng rãi trong nội bộ Amazon, ông chỉ ra vấn đề của Eventual Consistency và đề xuất một mô hình mạnh hơn đôi chút là Eventually Known Consistency
- Đây là mô hình vẫn giữ nhánh “A” (availability) trong định lý CAP, nhưng có thể phơi bày trạng thái nội bộ để trong đường đi bình thường vẫn đạt được “C” (consistency)
- Về sau Amazon S3 đã chuyển từ tối ưu tính sẵn sàng sang tối ưu tính nhất quán, còn DynamoDB thì cho phép chọn đọc Eventual hoặc Strongly Consistent
Vấn đề tương thích Xen và FreeBSD không khởi động được
- Đầu năm 2008, Kip Macy viết kernel FreeBSD có hỗ trợ Xen PAE, nhưng phải mất vài tuần mới port xong các công cụ AMI nội bộ sang FreeBSD
- Ông cũng nhắc rằng cấu trúc Ruby script sinh ra rồi chạy bash script là điều nên xem xét lại về mặt lựa chọn ngôn ngữ
- AMI FreeBSD không khởi động được trên EC2; nguyên nhân là Xen 3.0 mà EC2 dùng có lỗi không hỗ trợ page table đệ quy trong mã VM của FreeBSD
- Xen 3.1 đã sửa lỗi này, nhưng vì không có ABI ổn định, Amazon chọn tiếp tục dùng Xen 3.0 để giữ tương thích với các AMI hiện có
Phát hiện và sửa lỗ hổng chữ ký AWS
- Tháng 4 năm 2008, khi dùng Amazon SimpleDB cho bản beta của Tarsnap, ông phát hiện xung đột chuẩn hóa trong cơ chế ký
- Khi đó Amazon chưa có kênh báo cáo vấn đề bảo mật, nên ông phải chuyển thông tin qua Jeff Barr
- Amazon đã nhờ ông xem lại thiết kế của Signature Version 2; sau khi sửa các điểm mơ hồ trong tài liệu, điều chỉnh quyết định thiết kế và thêm tài khoản vào allowlist, vấn đề được khắc phục vào tháng 12
Vấn đề vệ sinh bảo mật của NextToken trong SimpleDB
- Tháng 6 năm 2008, ông phát hiện giá trị NextToken của SimpleDB chỉ là đối tượng Java được serialize rồi mã hóa base64 đơn giản
- Ông báo rằng cần mã hóa để ngăn rò rỉ thông tin nội bộ và cần chữ ký để ngăn sửa đổi, nhưng không nhận được phản hồi
- Sáu tháng sau, ông báo lại thông qua một kỹ sư khác và vấn đề được ghi thành ticket nội bộ, nhưng sau đó vẫn không có phản hồi chính thức
Alpha test của EBS và thời điểm phản hồi thiết kế
- Tháng 3 năm 2008, Matt Garman từ nhóm EC2 đã mời ông tham gia alpha kín của Elastic Block Storage (nay là Elastic Block Store)
- Ông cho rằng thời điểm hữu ích nhất để đưa phản hồi cho một dịch vụ mới là giai đoạn thiết kế trước khi xây dựng; với nền tảng toán học và lý thuyết, việc xem tài liệu thiết kế hiệu quả hơn alpha test
Giai thoại phỏng vấn vào Amazon
- Năm 2008, theo gợi ý của Jeff Barr, ông từng cân nhắc gia nhập Amazon; trong buổi phỏng vấn điện thoại với Al Vermeulen, 30 trong số 45 phút được dành để tranh luận về ưu và nhược điểm của exceptions
- Ông vẫn giữ quan điểm rằng exception là cách xử lý lỗi về bản chất không phù hợp, vì rất dễ tạo ra lỗi khó phát hiện trong quá trình review code thông thường
IAM và access key bị giới hạn — hành trình tới SigV4
- Tháng 11 năm 2008, tại AWS Start-up Tour ở Seattle, ông trực tiếp trao đổi với các kỹ sư Amazon về nhu cầu có AWS access key bị giới hạn
- Ông ủng hộ cách dẫn xuất khóa bằng mật mã học: băm suy ra khóa theo từng dịch vụ từ master secret; phía Amazon lại thiên về thiết kế dựa trên quy tắc
- Tháng 1 năm 2010, ông được mời vào private beta của IAM; đến khi SigV4 ra mắt năm 2012, phương pháp khóa dẫn xuất đã được áp dụng
Vấn đề firewall của EC2 và Path MTU Discovery
- Năm 2009, ông phát hiện và báo cáo việc rule firewall mặc định của EC2 chặn thông điệp ICMP Destination Unreachable (Fragmentation Required), khiến Path MTU Discovery không hoạt động
- Tháng 12 năm 2009, một quản lý EC2 đồng ý với phương án sửa, nhưng phải đến khi ông nêu vấn đề công khai vào năm 2012 thì lỗi mới thực sự được khắc phục
Đi đường vòng qua NetBSD và chuyển sang HVM
- Đầu năm 2010, khi EC2 vẫn dùng Xen cũ, ông thử chuyển sang NetBSD; chỉ trong một tuần đã chạy được đến mức khởi động, mount filesystem, cấu hình mạng và chạy
sshd
- Tháng 7 năm 2010, instance Cluster Compute hỗ trợ HVM, mở ra hy vọng cho FreeBSD; lúc này đã rõ rằng PV (paravirtualization) là ngõ cụt về mặt kỹ thuật
Lần đầu FreeBSD/EC2 chạy được — t1.micro
- Họ instance t1.micro ra mắt tháng 9 năm 2010 thực chất chạy Xen 3.4.2, nhờ đó lỗi ngăn FreeBSD khởi động đã được giải quyết
- Giữa tháng 11 năm 2010, ông đăng nhập SSH thành công vào instance FreeBSD/EC2 t1.micro; ngày 13 tháng 12 công bố chính thức hỗ trợ FreeBSD EC2 t1.micro
Mở rộng loại instance và mánh “Defenestration”
- Một Solutions Architect của Amazon đã kết nối ông với người dùng FreeBSD cần instance lớn hơn, từ đó hiện thực hóa hỗ trợ Cluster Compute instance
- Tận dụng việc EC2 thực ra không biết hệ điều hành nào đang chạy, ông dùng defenestration (ngụy trang thành instance Windows) để cho phép dùng FreeBSD trên mọi loại instance 64-bit
- Cách này buộc phải trả “thuế Windows” và Amazon cũng không hài lòng, nhưng nó là cần thiết để đáp ứng nhu cầu khách hàng; đến tháng 7 năm 2014, khi instance T2 hoàn thiện hỗ trợ HVM “Linux”, mánh này không còn cần thiết nữa
Chẩn đoán lỗi phần cứng router của S3
- Tháng 4 năm 2012, nhiều yêu cầu tới một endpoint S3 cụ thể bị lỗi, bao gồm cả SignatureDoesNotMatch
- Từ việc thấy giá trị StringToSign trong phản hồi lỗi không khớp với giá trị đã gửi, ông xác định được mẫu stuck bit, rồi dùng traceroute và hàng triệu gói ping để khoanh vùng lỗi phần cứng ở một router trên đường đi
- Sau khi báo trên AWS Developer Forums, Amazon xác nhận sự cố trong vài ngày và thay phần cứng
re:Invent 2012 và cảnh báo tấn công side-channel
- re:Invent đầu tiên thiếu nội dung kỹ thuật và có nhiều người mặc vest, nhưng lại tạo cơ hội trao đổi trực tiếp với nhiều kỹ sư Amazon
- Sau khi một VP của Intel trình bày về “bảo mật máy ảo” trả lời rằng không biết về tấn công side-channel, ông đã trực tiếp giải thích nghiên cứu liên quan cho Principal Engineer ở gian hàng EC2
FreeBSD/EC2 trở thành chính thức và release engineering
- Tháng 4 năm 2015, quy trình build AMI của FreeBSD/EC2 được tích hợp vào cây mã nguồn FreeBSD src, chuyển việc build image sang nhóm FreeBSD Release Engineering, biến nó từ dự án cá nhân thành dự án FreeBSD chính thức
- Tháng 9 năm 2020, theo đề nghị của FreeBSD Release Engineering Lead Glen Barber, ông nhận vai trò Deputy Release Engineer
- Cuối năm 2022, Glen nhập viện vì viêm phổi; do di chứng kéo dài khiến khó quay lại công việc, ngày 17 tháng 11 năm 2023 ông chính thức tiếp quản vai trò FreeBSD Release Engineering Lead
- Ông xây dựng snapshot hằng tuần, siết chặt lịch trình, thiết lập chu kỳ phát hành nhanh và dễ dự đoán hơn, quản lý 4 đợt phát hành mỗi năm
Cảnh báo bảo mật IMDS và vụ xâm phạm Capital One
- Tháng 10 năm 2016, ông phân tích IAM Roles for Amazon EC2 và đăng blog cảnh báo rằng việc lộ thông tin xác thực qua IMDS là nguy hiểm, vì hệ thống này hoạt động qua HTTP không xác thực và tài liệu còn ghi rõ “không lưu dữ liệu nhạy cảm”
- Tháng 7 năm 2019, Capital One đã bị khai thác đúng rủi ro này, làm rò rỉ dữ liệu của 106 triệu khách hàng; sau cuộc gọi với Amazon vào tháng 11 cùng năm, IMDSv2 ra mắt chỉ hai tuần sau đó
- Theo ông, IMDSv2 chỉ là biện pháp giảm thiểu cho một số đường tấn công nhất định, chứ không giải quyết tận gốc vấn đề là thông tin xác thực bị lộ qua một giao diện vốn không phù hợp
Chương trình AWS Heroes
- Tháng 5 năm 2019, ông được mời tham gia AWS Heroes, chương trình ghi nhận những người không thuộc Amazon nhưng có đóng góp quan trọng cho AWS
- Đây là một lựa chọn khá khác thường vì chương trình chủ yếu hướng tới những người đóng góp cho giáo dục nhà phát triển (blog, YouTube, workshop); việc này được phê duyệt theo đề cử của Distinguished Engineer và Senior Principal Engineer
Khởi động UEFI và BootMode=uefi-preferred
- Tháng 3 năm 2021, EC2 bổ sung hỗ trợ khởi động UEFI cho instance x86; với FreeBSD, chuyển sang UEFI giúp không còn cần I/O ở chế độ 16-bit và rút ngắn 7 giây thời gian khởi động
- Không phải mọi loại instance đều hỗ trợ UEFI, nên ông đề nghị cấu hình BootMode=polyglot cho image có thể khởi động được cả BIOS cũ lẫn UEFI
- Tháng 3 năm 2023, tính năng này được triển khai với tên BootMode=uefi-preferred
Phát hiện vấn đề bảo mật của Seekable OCI và việc chậm sửa
- Tại Heroes Summit tháng 8 năm 2023, sau khi xem thiết kế của Seekable OCI, ông phát hiện trong một số trường hợp sử dụng nhất định, tuyên bố bảo mật của nó không đứng vững và đã báo cho đội AWS Security
- Dù nhận được cam kết sẽ sửa nội bộ, thực tế không có tiến triển; tại re:Invent 2024 ông tiếp tục yêu cầu xác nhận lại, và sau khi báo lại vào tháng 1 năm 2025, xác nhận rằng commit năm 2023 chỉ ngăn hỏng dữ liệu ngoài ý muốn chứ không chặn được tấn công có chủ đích
- Sau khi ông chỉ ra, phản ứng diễn ra nhanh chóng và tới cuối tháng 2 năm 2025, tính năng này đã bị vô hiệu hóa với phần lớn khách hàng, chờ một “major revision”
Mô hình hợp tác và tài trợ từ Amazon
- Tháng 4 năm 2024, ông thông báo với phía Amazon rằng mình không thể dành đủ thời gian cho việc bảo trì FreeBSD/EC2 và đề nghị hỗ trợ tài chính; chỉ vài tuần sau, Amazon xác nhận tài trợ 10 giờ mỗi tuần trong 1 năm qua GitHub Sponsors
- Sau khi xử lý nhiều vấn đề tồn đọng và trải qua 6 tháng gián đoạn (phần lớn là làm không lương để tập trung vào release engineering của FreeBSD 15.0), ông bắt đầu gói tài trợ 12 tháng thứ hai
- Ông nhấn mạnh rằng đóng góp suốt 20 năm không phải thành quả của riêng một mình mình; dù không có quyền truy cập hệ thống AWS nội bộ, các kỹ sư Amazon đã đóng vai trò “cánh tay từ xa” như tạo ticket, tìm đầu mối liên hệ nội bộ, điều tra log API và lấy tài liệu kỹ thuật
1 bình luận
Ý kiến trên Hacker News
Tác giả đùa rằng ‘Heroes về cơ bản là nhân viên Amazon không lương’, nhưng đó không phải trò đùa mà là thực tế
Tôi không công khai nghiên cứu cá nhân của mình. Vì tôi không muốn cung cấp R&D miễn phí cho một cỗ máy khai thác giá trị vốn đã đủ hiệu quả
Amazon đã phá vỡ tiền đề kinh tế của mã nguồn mở, và kết quả là nhiều dự án đang chuyển sang Business Source License
Những nhà phát triển này biết Amazon tham lam đến mức nào. Cuối cùng, đóng góp của cộng đồng biến thành lao động không công cho các siêu tập đoàn, còn Amazon thì hút người dùng vào dịch vụ được quản lý của mình, làm suy yếu hỗ trợ và cộng đồng của dự án gốc
Viết kiểu “bất kỳ ai ngoài Amazon đều có thể tự do sử dụng” thì Amazon sẽ không dùng vì rủi ro pháp lý
Tuy vậy, nếu thấy cần thiết, Amazon có thể sẽ tự làm một phiên bản riêng
Như trường hợp Redis, mức độ bảo hộ pháp lý đối với bề mặt API vẫn chưa rõ ràng
Tôi nhớ là trước đây án lệ Google v. Oracle từng định thiết lập sự bảo hộ đó nhưng rồi bị hoãn lại
Thực ra, các công ty chọn BSL có lẽ công khai mã chủ yếu để quản lý hình ảnh hay lấy thiện cảm từ nhà phát triển hơn là vì tinh thần mã nguồn mở thực sự
Dù vậy, tôi hoàn toàn đồng ý. Giờ mã tôi công khai sẽ либо là mã nguồn mở hoàn toàn, либо là đóng hoàn toàn
Nếu có khả năng ai đó sẽ kiếm tiền từ nó thì tôi sẽ không công khai
Tôi hiểu góc nhìn không muốn dành thời gian cho các tập đoàn lớn, nhưng tôi muốn đưa ra một quan điểm khác
Năm 2006 tôi có một dự án, đến năm 2012 một nhà phát triển khác muốn dùng cái tên đó nên tôi sẵn lòng nhường lại
Dự án đó chính là scrypt, và nhà phát triển là Colin
Sự tử tế trong cộng đồng như vậy, ngay cả khi không có kỳ vọng thương mại, vẫn tích lũy thành nghiệp tốt
Câu “buổi gặp mặt người dùng AWS của Jeff Barr được tổ chức trong Second Life” thật sự rất thú vị
Second Life là một trong những người dùng đầu tiên của AWS, và Jeff Bezos đã trực tiếp tham gia vòng đầu tư năm 2005
Nhờ vậy Jeff Barr đã tổ chức meetup AWS trong Second Life, và đó cũng là thời kỳ các nhóm như Reuters hay Jonathan Coulton bắt đầu tiến vào không gian ảo
Khi đó chúng tôi có gian hàng của Evolution Robotics để trình diễn robot ER1, và Second Life thật sự gây ấn tượng mạnh
Đó là một kỷ niệm đẹp
Tất nhiên, Second Life trên màn hình laptop và tai nghe VR là hai trải nghiệm hoàn toàn khác nhau
Cách đóng khung đây là “lao động miễn phí cho Amazon” đang bỏ lỡ trọng tâm
Colin không làm từ thiện; anh ấy cải thiện thứ đó vì Tarsnap phụ thuộc vào FreeBSD/EC2
Đây là mô hình lành mạnh nhất của mã nguồn mở — sửa nền tảng cho chính sản phẩm của mình, và kết quả đem lại lợi ích cho tất cả mọi người
Ngồi chờ đến khi Amazon tự quan tâm thì chẳng khác nào chờ mãi mãi
Tôi ngạc nhiên khi đọc rằng Amazon đã tài trợ 10 giờ mỗi tuần trong 1 năm thông qua GitHub Sponsors
$300 một giờ tức là ngang mức lương của kỹ sư Google L6
Hy vọng bây giờ ông ấy nhận được nhiều hơn
Ở khu vực châu Âu nói tiếng Đức, 120 euro là đã thuê được một kỹ sư rất giỏi. Đông Âu còn rẻ hơn nữa
Tôi không đồng ý với chỉ trích của tác giả về IAM Roles for EC2
IAM là tính năng cốt lõi cho phép quản lý thông tin xác thực dựa trên chính sách
Nó an toàn hơn Outlook, Slack hay Teams rất nhiều, và thậm chí còn có thể chứng minh bằng toán học rằng thành viên trong nhóm không thể nhìn thấy khóa ký
Azure cũng áp dụng khái niệm tương tự để xử lý quyền truy cập MSSQL rất gọn gàng
Trước đây tôi từng đề xuất truyền thông tin xác thực vào kernel qua XenStore. Nếu dựa trên Nitro thì giờ còn dễ triển khai hơn
Chỉ cần để kernel nhận thông tin xác thực rồi phơi bày chúng dưới dạng hệ thống tệp ảo nơi có thể thiết lập quyền sở hữu và quyền hạn
Điểm thú vị là chỉ những tiến trình có quyền CAP_NET_BIND_SERVICE mới truy cập được
Nếu dùng socket vsock(7) thì sẽ thành kiểu kết nối khó giả mạo hơn, nên an toàn hơn
Tiến thêm một bước, nếu đưa thông tin xác thực bootstrap vào dữ liệu DMI thì nó sẽ nằm trong thư mục sysfs mà chỉ root mới đọc được
Kiểm tra lại email năm 2007, đúng là thời kỳ đầu muốn truy cập dịch vụ AWS phải gửi yêu cầu riêng lẻ
Lúc đầu tôi chỉ được chấp thuận cho “Amazon E-Commerce Service”, sau đó mới lần lượt có quyền truy cập S3 và bản beta của EC2
Khi đó “Alexa Web Information Service” không phải trợ lý giọng nói mà là API tìm kiếm web. Thời đó thật thú vị
Đây thật sự là một tư liệu lịch sử công nghệ rất thú vị
Điều làm tôi ấn tượng là ngay cả một kỹ sư nổi tiếng như Tavis Ormandy cũng có thể sai sót khi phỏng vấn
Tôi rất thích những bài blog kể chuyện từ trải nghiệm thực tế như thế này
Việc trong hồi tưởng 20 năm này không hề nhắc đến Hetzner hay OVH cũng khá đáng suy ngẫm
Tôi dùng cả AWS, Hetzner và các đám mây nhỏ, và chênh lệch giá là cực lớn
AWS tốn $350 mỗi tháng, còn Hetzner chỉ 20~25 euro với cấu hình tương tự và kèm 20TB lưu lượng
Thứ AWS bán giờ đây không còn là compute, mà là mô hình IAM, hạ tầng toàn cầu và sự đồng thuận trong tổ chức
Nhận thức kiểu “chọn AWS thì sẽ không ai bị sa thải” mới là sản phẩm thật sự
Tôi muốn hỏi những ai gần đây đã chuyển workload khỏi AWS — phần nào đau đớn hơn dự kiến?