400 lý do nên tránh dùng Microsoft Azure
(azsh.it)- Tài khoản chia sẻ những điều kỳ quặc gặp phải mỗi ngày trên Microsoft Azure. Hiện đã vượt quá 400 ngày
- Day 403: Gần đây có #Microsoft Cloud for Sustainability Technical Summit. Nhưng trên thực tế, nó giống một hội nghị thượng đỉnh #Copilot có thêm chút tập trung vào tính bền vững hơn. (Ảnh chụp màn hình này chỉ được lấy từ ba phiên đầu tiên)
- Day 402: Tính năng #AI mới của Azure CLI đến nay đang hoạt động rất tuyệt vời (ảnh chụp màn hình lỗi)
- Day 401: Hình ảnh lỗi liên kết. Chỉ là một trong vô số ví dụ về các liên kết trong tài liệu #Azure trỏ tới những mục thậm chí còn không tồn tại
...
1 bình luận
Ý kiến trên Hacker News
Trước đây khi làm ở Mojang, sau khi bị Microsoft mua lại, chúng tôi đã thử chuyển từ AWS sang Azure
Nhìn bề ngoài thì điều đó có lý, vì chi phí AWS lúc đó là mức 6 chữ số đô la mỗi tháng, trong khi Azure thì có thể dùng miễn phí
Nhưng sau khoảng 1 năm, sau khi đội chúng tôi và các chuyên gia giải pháp mà tổ chức Azure cử sang đã bỏ ra vô số thời gian, tất cả đều đồng ý rằng chúng tôi nên tiếp tục duy trì khoản chi phí 6 chữ số trả cho một trong những đối thủ lớn của Microsoft
Từ đó về sau tôi không còn xem Azure là một nhà cung cấp cloud có thể dùng thực tế nữa; có thể một ngày nào đó tôi sẽ phải đánh giá lại, nhưng đây có lẽ cũng không phải lần đầu tôi sai
Nhìn chung thì ổn, nhưng vấn đề bắt đầu khi chúng tôi dùng CosmosDB, khi đó còn có tên là DocumentDB
DocumentDB thời kỳ đầu thật sự rất tệ; chi phí cực kỳ khó dự đoán, cuối tuần nào cũng xuất hiện những hóa đơn vô lý, còn .NET SDK được cung cấp thì đầy lỗi và kinh khủng
Tệ nhất là web UI dường như bị gắn trực tiếp với một instance CosmosDB cụ thể
Nếu cấp thiếu tài nguyên cho database thì nó chậm lại, và cả giao diện web cần dùng để tăng tài nguyên cũng bị trễ theo
Vì vậy có lúc chúng tôi phải tắt toàn bộ ứng dụng chỉ để tăng tài nguyên Cosmos, và Microsoft lúc đó trông hoàn toàn như dân nghiệp dư
Tôi hiểu là hiện nay Cosmos đã tốt hơn nhiều, nhưng dư vị khi đó quá tệ
Nếu có thứ gì đó như credit miễn phí thì tôi có thể thử lại Azure, nhưng hiện tại thì tuyệt đối không khuyến nghị
Việc chạy dịch vụ email lớn nhất thế giới trên stack Windows hẳn sẽ là một sự bảo chứng rất lớn, nhưng phải mất vài năm mới thành công
https://www.zdnet.com/article/ms-moving-hotmail-to-win2000-s...
https://jimbojones.livejournal.com/23143.html
Tôi đoán có thể là những tính năng riêng của AWS như cách AWS xử lý serverless nên không thể chuyển trực tiếp sang Azure, nhưng tôi luôn muốn học xem vì sao việc chuyển từ X sang Y lại thất bại
Có lẽ việc các công nghệ phía game đã hoàn thiện hơn trong thời gian đó cũng giúp ích
Sửa: AWS -> Azure :)
Khi đó có khoảng cách công nghệ vì AWS nhìn chung đi trước, và có vẻ sau này khoảng cách đó đã được lấp đầy
Không sao đâu, tuần sau Microsoft sẽ đổi tên và đại tu hoàn toàn UI quản trị cùng API thôi
Tên mới sẽ là Dynamics CoPilot OneAI 365 for Business OneCloud
live.com, một số làoutlook.com, rồi một số khác kiểusharepoint.com,msbinbows.comNhưng tài liệu và mọi tham chiếu khác vẫn sẽ tiếp tục giữ tên cũ
Theo kinh nghiệm của tôi, tôi đã thấy các tổ chức dùng đủ từ rack server on-premise đến Linode, AWS, Azure, và mức độ phàn nàn về hạ tầng cloud tỷ lệ thuận với mức sử dụng dịch vụ được quản lý
Những đội chủ yếu dựa vào máy ảo, nhiều lắm là thêm database quan hệ được quản lý, thì hầu như không phàn nàn
Đúng là phải duy trì thêm chút script, nhưng đó chỉ là bất tiện nhỏ so với việc vật lộn với các vấn đề và hành vi kỳ lạ của dịch vụ được quản lý
Đương nhiên máy ảo bình thường dễ bảo trì hơn dịch vụ được quản lý, và đó là lý do người ta trả nhiều tiền hơn cho nhà cung cấp cloud để dùng dịch vụ được quản lý nhằm khỏi phải tự làm
Vậy rốt cuộc ý là nỗ lực này về bản chất là vô nghĩa sao?
Vì lý do chính khiến nhiều công ty chuyển lên cloud là các dịch vụ được quản lý, nên khó có thể nói nhận định này hoàn toàn không gây tranh cãi
Một khách hàng cần tunnel IPsec vào VPC nơi có server production, và vì không muốn tự duy trì cấu hình đó chỉ vì một khách hàng, chúng tôi kiểm tra dịch vụ AWS cung cấp thì thấy có giải pháp IPsec được quản lý
Nhưng rồi khách hàng liên hệ nói tunnel đã bị ngắt, và cách xử lý là phía khách hàng phải restart để kết nối được thiết lập lại
Có thể bật logging S3 để xem lý do, nhưng theo phía AWS thì mọi thứ lẽ ra phải bình thường
Chỉ dùng EC2 thôi cũng có chuyện kỳ lạ xảy ra
Gần đây một instance EC2 ngừng phản hồi nhưng Auto Scaling Group không thay thế nó; làm thao tác gì cũng báo lỗi rằng instance không ở trạng thái đang chạy, nhưng trạng thái của nó lại là đang chạy
May là sếp tôi đồng ý, nhưng ông ấy không có toàn quyền
Vì vendor lock-in và khả năng tương thích API gần giống nhưng không hoàn toàn giống với open source, tôi càng lo khi càng nhiều đội áp dụng
Họ nói “nhưng nó dễ hơn mà!”, còn phải chờ xem
Trước khoảng năm 2014, AWS định kỳ hạ giá các dịch vụ chính, chuyển phần chi phí công nghệ giảm xuống cho khách hàng
Azure không thích điều đó nên bắt đầu bám theo giá của AWS, và lập tức theo cùng mức giảm cho cùng dịch vụ
Đây là một dạng định giá săn mồi, vì mục đích là khiến đối thủ dù giảm giá cũng không giành được thị phần, từ đó triệt tiêu động lực giảm giá
Tôi đã rất muốn thích Azure vì nó tích hợp tốt với các công cụ, nhưng cứ liên tục gặp giới hạn về tính sẵn có của máy ảo và những điểm kỳ quặc trong UX
Trên AWS, tôi chưa từng không kiếm được máy, hay phải nghi ngờ liệu thao tác mình làm có thực sự được áp dụng hay không
Tôi cũng đã vài lần cân nhắc FaaS của Azure, nhưng giờ thì dứt khoát nghiêng về phía “đừng dùng, chạy ngay đi”
Trải nghiệm quanh Azure Functions quá kỳ lạ nên không thể thấy thoải mái được, và việc truy cập log hay các artifact nhị phân khác cũng đau đớn khủng khiếp
Việc chạy bản build .NET tự chứa trên một máy ảo Windows/Linux trống quá dễ, nên chẳng có lý do gì để dính vào tất cả sự phức tạp bổ sung này
Ngoài ra còn có những hành vi phá vỡ tự động hóa, kiểu SQL Server gửi callback báo đang chạy dù thực ra phải 20 phút nữa mới sẵn sàng
Tôi nửa tin rằng
terraform time_sleepđược tạo riêng để chặn các vấn đề của AzureKhi function app cần nhiều hơn một hàm đơn giản, như thời gian chạy dài hơn hoặc không có độ trễ cold start, cuối cùng bạn cũng dùng chính dịch vụ đó
App Services mất thời gian để làm quen, nhưng về cơ bản là một container Win Server/IIS bị khóa, có FTPS tích hợp, endpoint kiểm tra trạng thái để tự chữa lỗi, triển khai bằng cách chỉ định kho lưu trữ, tùy chọn tự động mở rộng, và SLA 99,95%
Vài năm trước hiệu năng của nó không tốt lắm, nhưng các SKU Premium từ 2 vCPU trở lên trên CPU mới không có vấn đề gì
Nó đắt hơn máy ảo, nhưng xử lý bảo mật và cập nhật cho máy ảo web server là một khối lượng việc khổng lồ
Chúng tôi đã mua lại một công ty được host trên Azure
Họ dùng Postgres được host và các dịch vụ .NET trên Windows, hạ tầng thì nhỏ, khoảng 200~300 core và 1TB bộ nhớ
Cứ vài ngày Microsoft lại tùy tiện hạ ngẫu nhiên một instance với lý do bảo trì và cắt mạng hơn 10 phút
Postgres được host có hiệu năng thảm họa nên chúng tôi đã di chuyển, nhưng một chuyên gia ở Ấn Độ hướng dẫn dùng loại volume khác, và sau khi khởi động lại instance thì database không lên được do độ trễ I/O
Chuyên gia đó nói bận và né họp suốt 3 ngày liên tiếp, còn RCA thì là một tài liệu nửa vời có vẻ do LLM viết, nói rằng không phải lỗi của họ, nhưng biểu đồ lại kể câu chuyện khác
Điều duy nhất Azure thắng GCP và AWS là dashboard tải nhanh
Nhưng thật buồn là nếu chạy song song 2 tác vụ mạng tương tự nhau thì hoặc thất bại, hoặc mất lâu gấp 10 lần so với chạy tuần tự
Hãy chạy khỏi nó, đừng dùng
Trong tất cả nhà cung cấp PaaS, Azure có các tầng trừu tượng và dịch vụ tệ nhất
Điều đáng buồn là nhìn chung mọi người đều đồng ý tiêu thụ các dịch vụ kỳ quặc như vậy, và thế là sinh ra việc làm cho cloud architect và chuyên gia
Vì phải giữ cho các đối tác tiếp tục có liên quan, họ nuôi dưỡng thiết kế tệ và các kết nối lỏng lẻo
Thật ra đó cũng là suy nghĩ của tôi về toàn bộ IT doanh nghiệp
Tôi từng thừa hưởng một đống hỗn loạn Azure ở một công ty nhỏ khoảng 30 lập trình viên, rồi tạo trong công cụ phát triển các abstraction gần với chuẩn ngành hơn cho những dịch vụ cần thiết, và vài năm sau chuyển sang Hetzner
Các lập trình viên ở đây về cơ bản không thấy khác biệt
Công cụ của chúng tôi xử lý workflow và abstraction dịch vụ, những thứ này không nên thay đổi chỉ vì đổi nhà cung cấp
Hóa đơn hằng tháng giảm còn một phần mười, và chúng tôi dùng một phần số tiền đó để tạo ra trải nghiệm lập trình viên tốt nhất có thể tưởng tượng
Tôi thấy đó là một sự đánh đổi rất tốt
Chỉ có hai trường hợp đáng dùng các cloud lớn
Hoặc là quy mô MVP thật sự nhỏ, hoặc là môi trường phân tán toàn cầu khổng lồ cần tính đàn hồi
Với đa số công ty, cả hai gần như đều là ngoại lệ
Tôi nghĩ bất kỳ người dùng Azure nào cũng có thể lập danh sách 100 lý do không nên dùng Azure, và đa số phần mềm lớn cũng vậy
Ngay cả với tư cách người ít tiếp xúc với các cloud khác, tôi cũng dễ dàng thấy trải nghiệm người dùng của Azure không được quản lý tử tế và bị tụt hậu
Số trang mà thanh lọc chỉ hoạt động đúng sau khi bấm “xem thêm” giờ rõ ràng nên là 0
Đây là một pattern khách quan là tệ, đã tồn tại nhiều năm và “lẽ ra” phải dễ sửa, nhưng có lẽ sẽ không bao giờ thành ưu tiên
Rốt cuộc, trừ khi việc giải quyết những vấn đề như vậy là giá trị cốt lõi của tổ chức hoặc gây tác động rõ ràng đến doanh thu, chúng sẽ không được sửa
Với cộng đồng người dùng, tính công khai và khả năng nhìn thấy các vấn đề như vậy luôn quan trọng
Tôi dùng cả AWS lẫn Azure, và có một thứ tôi thực sự thích ở Azure là portal
Nó giống AWS 2.0: các thứ lặt vặt của cloud được trừu tượng hóa đi, chỉ còn lại những thiết lập thực sự cần thao tác và quan hệ giữa chúng
Tôi cũng thích AWS, nhưng mỗi lần bước vào một môi trường lạ và phải reverse engineer tất cả kết nối, xong việc là tôi cần uống rượu
Khi tôi dùng thử Azure vài ngày, portal thật sự rất đau đớn
Mỗi lần nhấp đều mất 5~10 giây mới phản hồi, và có lúc chỉ đổi thiết lập cơ bản cũng phải nhìn Ajax spinner hơn 2 phút
Làm sao có thể thích làm việc kiểu đó được?
Có cảm giác ai đó cố tình làm cho chúng rối rắm nhất có thể, nhưng mục đích thì tôi không đoán nổi
Tôi không nói ý kiến đó vô hiệu hay bạn nói dối, nhưng kể cả trong số những người sống từng giờ trong hệ sinh thái Azure, tôi chưa từng thấy ai thích Azure portal
Nếu không thì buồn cười thật
Tôi hoàn toàn ở phía ngược lại, nên chắc phải coi là mỗi người một gu
Tôi đã dùng cả hai khá nhiều, và dashboard Azure vẫn gây khó chịu, nhưng nếu chỉ xét khả năng sử dụng thì nó tốt hơn AWS rất nhiều
Hơn nữa Microsoft rõ ràng đầu tư thời gian và tiền bạc vào tài liệu, trong khi tài liệu AWS thì lúc nào cũng tệ
Nếu là một công ty nhỏ và không vận hành container thì Cloudflare là một đám mây bị đánh giá thấp rất nhiều
Tôi biết nó bị chỉ trích vì những lý do khác, nhưng nếu đã mệt mỏi với Big 3 hoặc 4, trải nghiệm dành cho nhà phát triển thật sự rất tuyệt
[1]: https://blog.cloudflare.com/container-platform-preview/
Tôi thích nó cho các site Svelte, nhưng bị trói vào một ngôn ngữ và các ràng buộc dựa trên request-response là một hạn chế rất lớn
Ít nhất phải có container và persistent volume thì tôi mới quan tâm
Tôi thật sự ghét Azure một cách mãnh liệt
Tôi thuộc một nhóm làm công cụ tự động hóa việc tạo project/account/subscription theo từng cloud provider
Nhà cung cấp chính là GCP, và phần triển khai khá dễ
Có vài cái bẫy nhỏ nhưng dễ vượt qua
Giờ chúng tôi phải hỗ trợ Azure để làm multicloud
Trước đây chúng tôi ở AWS nhưng đã rời khỏi 95%, và dù vẫn còn vài nhóm ở đó, gần như không làm công cụ gì ngoài các module Terraform
Nhưng Azure API, MS Graph API, và Go SDK của cả hai là đống rác lớn nhất mà tôi từng phải xử lý
Mọi thứ đều là pointer, thậm chí string literal cũng phải biến thành pointer, nhưng đôi khi lại không
Tài liệu thì không chính xác; có API chỉ nhận ID nhưng API khác lại nhận cả đường dẫn đầy đủ
Một số được ghi tài liệu, nhưng rất nhiều API ghi sai định dạng
Không API nào trả về ID của resource liên quan nên phải tìm kiếm tất cả, và có quá nhiều tìm kiếm dựa trên tên
Chúng tôi còn phải thêm cả một lớp cache ID để không phải truy vấn lặp lại cùng một resource trong lúc tạo
Chúng tôi dùng state machine cho việc tạo và có thể tiếp tục từ giữa chừng, nên cần rất nhiều code dựa trên kiểm tra và tiếp tục
Nhìn chung đây là cloud provider có thiết kế và triển khai tệ nhất; nếu có lựa chọn, tôi tuyệt đối sẽ không khuyến nghị hay chọn nó
Những thứ được viết bằng Go nội bộ thường rất tốt
Chúng tôi đã tự làm một cái trong công ty, nhưng cũng quan tâm đến các lựa chọn bên thứ ba
Tuy vậy, do các quy tắc nghiệp vụ nội bộ, có lẽ tự làm vẫn hợp lý hơn mua