Hạt nhân của sự tùy chọn của đám mây

Một trong những thỏa thuận đám mây doanh nghiệp thú vị nhất năm 2020 phải kể đến việc Zoom mở rộng đám mây với Oracle Cloud Infrastructure , trong đó ba nhà cung cấp "siêu đám mây" chính (AWS, Azure và GCP) đã hoàn toàn bị bỏ qua để ủng hộ một kẻ yếu thế không ngờ tới. Đương nhiên, suy đoán về lý do tại sao Zoom đưa ra lựa chọn này sẽ đưa bạn đến nhiều hướng khác nhau. Kevin Xu đã viết một bài viết tuyệt vời nêu chi tiết ba lý do riêng biệt tại sao Zoom có ​​thể thấy OCI có lợi . Tất cả những lý do đó đều rất có lý.

Tuy nhiên, theo tôi, lời giải thích tốt nhất là một số liệu được Corey Quinn đề cập : chi phí băng thông mạng truyền đi. Chi phí băng thông của Oracle rẻ hơn AWS 10 lần và sức mạnh đàm phán tương đối của Zoom với Oracle so với AWS có thể có nghĩa là mức chiết khấu tốt hơn nhiều cho mức giá đó. Sự chủ quan về cách các nhà phát triển có thể cảm thấy về Oracle có thể tóm gọn lại như sau: "Sử dụng OCI tốn nhiều giờ làm việc của nhà phát triển hơn so với sử dụng AWS". Mặc dù điều này có thể đúng ở một mức độ nào đó, nhưng tôi nghi ngờ rằng nó biện minh cho việc tiết kiệm hàng triệu đô la mỗi tháng có thể tạo nên hoặc phá vỡ khả năng trả lương và tiền thuê nhà của một công ty trong khi vẫn có lãi.

Khả năng đạt được các thỏa thuận tốt của Zoom phụ thuộc vào khả năng cân nhắc các thỏa thuận tốt. Bạn càng có thể lựa chọn nhiều nhà cung cấp, bạn càng có nhiều đòn bẩy đàm phán, vì bạn có thể đơn giản từ chối một thỏa thuận mà bạn không thích và chọn một nhà cung cấp khác. Vì mỗi nhà cung cấp đám mây cung cấp một đề xuất giá trị khác nhau, bao gồm các dịch vụ đám mây khác nhau, nên việc xây dựng một giải pháp có thể triển khai trên nhiều đám mây khác nhau đòi hỏi sự chuẩn bị chu đáo, toàn diện ở cấp độ thiết kế hệ thống. Đó là lý do tại sao việc lưu ý đến các dịch vụ đám mây mà bạn sử dụng khi xây dựng ngăn xếp công nghệ của mình lại quan trọng đến vậy.

Sử dụng dịch vụ đám mây có thể đưa ra những sự đánh đổi khó khăn. Các dịch vụ được quản lý có thể tiết kiệm nhiều giờ lao động quý báu trong quá trình khám phá và thay đổi sản phẩm. Thật không may, chúng cũng có thể đưa ra các hộp đen không chỉ ảnh hưởng đến cách bạn được lập hóa đơn mà còn ảnh hưởng đến các lựa chọn bạn có về việc lập hóa đơn trong tương lai, cùng với những mối quan tâm khác. Hãy xem cuộc trò chuyện này về giá Google Kubernetes của  GCP làm ví dụ, trong đó một người dùng than thở về tác động của giá đối với kiến ​​trúc hệ thống tối ưu.

Tôi thấy một số quy tắc cơ bản hữu ích. Đầu tiên, bạn thiết kế càng thấp cho ngăn xếp, thì tính phổ biến giữa các dịch vụ của nhà cung cấp càng cao. Nhiều công ty nhắm mục tiêu vào một kiến ​​trúc máy tính cụ thể hơn là nhắm mục tiêu vào một API dành riêng cho ứng dụng vì tại một thời điểm nào đó, mọi người đều phải sử dụng cùng một nguyên mẫu. Ví dụ, nếu bạn thích ăn bất kỳ loại thịt đỏ nào, bạn có thể mua hàng tạp hóa ở hầu hết mọi siêu thị. Tuy nhiên, nếu bạn phải nhập thịt bò wagyu để ăn tối, thì các lựa chọn của bạn sẽ bị hạn chế hơn nhiều. Vì mọi người đều phải xây dựng các dịch vụ từ các nguyên mẫu, nên dịch vụ được nhà cung cấp phát hành càng sớm thì càng bám sát vào các nguyên tắc cơ bản đầu tiên có sẵn cho mọi người. Do đó, có khả năng cao hơn là các nhà cung cấp đám mây khác cũng đã thực hiện theo hướng sản phẩm đó.

Một bài tập cuối cùng là hỏi giải pháp thay thế tại chỗ cho giải pháp này có thể là gì. Theo kinh nghiệm của tôi, ngăn xếp dựa trên đám mây tùy chọn bao gồm việc quản lý lớp mạng, VM và kho lưu trữ đối tượng của riêng bạn, trên AWS được ánh xạ tới VPC + EC2 + S3 . Sau đây là những gì tôi thấy có giá trị để biết về từng dịch vụ này.

VPC

Ấn tượng của tôi về lợi ích lớn đằng sau việc quản lý VPC của riêng bạn là bạn có thể kiểm soát bảo mật của riêng mình theo cách có thể sao chép bên ngoài bất kỳ nhà cung cấp đám mây nào. Theo cách xấp xỉ bậc nhất, bạn có thể thiết lập dịch vụ trong mạng con riêng với bảng định tuyến và cổng NAT và do cách thức hoạt động của internet, không có yêu cầu nào từ internet có thể đến được với bạn. Kiểu thiết lập này khá mạnh mẽ, đặc biệt là khi triển khai các dịch vụ nội bộ không cần phải lắng nghe Internet nhưng vẫn phải lấy các bản cập nhật từ máy chủ từ xa. Vì bạn không bao giờ muốn triển khai bảo mật của riêng mình , nên việc thiết lập VPC có thể là một giải pháp thay thế hữu ích cho các sản phẩm bảo mật trả phí và dành riêng cho nhà cung cấp, mặc dù logic và lựa chọn bảo mật cấp ứng dụng có thể khác nhau.

VPC là một bộ chuyển mạch gói tin ảo hóa, trong trường hợp đó, giải pháp thay thế nguồn mở có thể là thứ gì đó giống như Open vSwitch của  VMWare . Các dịch vụ VPC dựa trên đám mây cực kỳ phổ biến và được chuẩn hóa cao. Trong một ngành công nghiệp đầy rẫy những biệt danh, AWS, GCP và Azure đều gọi dịch vụ ảo hóa mạng của họ là "VPC".

Tôi quản lý VPC của mình trên AWS bằng AWS CloudFormation và thấy bài viết này rất hữu ích về mặt thực hiện cho người mới bắt đầu.

EC2

VM vẫn là chìa khóa cho đám mây vì nó không chỉ phân tách số lượng phiên bản tính toán bạn có thể chạy trên máy chủ cơ bản mà còn có thể chạy bất kỳ loại phần mềm nào trên phần cứng cơ bản. Điều này làm tăng đáng kể tính tùy chọn của bạn, vì nếu bạn xác định thiết kế hệ thống của mình ở cấp EC2, tất cả những gì bạn cần để chuyển sang một nền tảng khác là cập nhật các đường ống xây dựng của mình để nhắm mục tiêu vào nền tảng đó. Bạn có thể nhắm mục tiêu vào khách hàng doanh nghiệp tích hợp với Windows Server 2003 cho các giao dịch doanh nghiệp lớn và bạn nhận được các bản vá lỗi hạt nhân mới nhất từ ​​Linux thượng nguồn để có được sự đảm bảo bảo mật cấp hệ điều hành tốt nhất.

Chìa khóa của máy ảo là trình quản lý ảo, đây là lớp ảo hóa cơ sở hạ tầng tách biệt VM và hệ điều hành máy chủ. Trình quản lý ảo ảo hóa trình điều khiển thiết bị cơ bản của bạn. Nếu bạn cần các thiết bị chuyên dụng, như GPU hoặc FPGA để chuyển mã video hoặc AI/ML, hãy tìm hiểu về trình quản lý ảo có thể là một lựa chọn tốt để tìm ra hiệu suất hoặc độ tin cậy khó khăn và tránh các giải pháp AI/ML được quản lý tốn kém. Có nhiều trình quản lý ảo khác nhau và một số trình quản lý ảo tốt nhất là mã nguồn mở. KVM là một trình quản lý ảo như vậy thường được sử dụng trên toàn bộ hệ thống, cho phép nhân Linux hoạt động như một trình quản lý ảo và được tích hợp vào chính nhân Linux. Cá nhân tôi không thấy nhiều nguy cơ bị khóa nhà cung cấp ở cấp độ trình quản lý ảo. Trên thực tế, AWS gần đây đã chuyển sang KVM cho một phần dịch vụ EC2 của mình .

Một công cụ mà tôi hối tiếc vì đã không sử dụng nhiều hơn trong hành trình DevOps của mình là Packer , được Justin Menga mô tả trong Docker trên AWS . Packer định nghĩa "Hình ảnh máy tự động" hoặc AMI, bằng cách sử dụng dữ liệu như tệp JSON, tại các thời điểm khác nhau trong vòng đời của AMI (trước + sau khi xử lý). Bạn có thể định nghĩa trước AMI và gửi hình ảnh giống như bạn có thể làm với tệp ISO, xuất bản nó lên sổ đăng ký và kéo xuống trong thời gian tạo EC2. Biết rằng bạn thậm chí không cần truy cập Internet để đảm bảo VM của mình được cập nhật sẽ giúp bạn tránh được rất nhiều rắc rối. Ngược lại, tôi chỉ định nghĩa cấu hình AMI trực tiếp trong CloudFormation, hiện không cho phép nhập tệp cấu hình tương đối trực tiếp và chỉ có thể kiểm tra trạng thái AMI trong thời gian chạy khi được đóng gói với các tài nguyên đám mây khác.

S3

S3 là "mờ" nhất trong bộ ba này. Đây là dịch vụ được quản lý dành riêng cho nhà cung cấp mà không có giải pháp thay thế tại chỗ rõ ràng nào. Nhưng có một lý do chính đáng khiến bạn vẫn nên áp dụng nó hoặc một cái gì đó tương tự như vậy, như một phần của ngăn xếp của bạn. Đầu tiên, các hệ thống dựa trên UNIX xử lý tệp khác với quy trình. Thứ hai, tệp nói chung mang lại nhiều tính linh hoạt hơn so với quy trình trực tiếp; bạn có thể tưởng tượng việc sao chép tệp ít căng thẳng hơn so với sao chép quy trình, với các yêu cầu trạng thái của nó. Cuối cùng, và có lẽ quan trọng nhất, dữ liệu phục hồi vẫn rất quan trọng đối với khả năng duy trì hoạt động kinh doanh của công ty và việc trả phí bảo hiểm cho các đảm bảo phục hồi là xứng đáng. Việc thiết kế đảm bảo này đi kèm với các yêu cầu thiết kế khác nhau và các tiêu chuẩn nghiêm ngặt hơn nhiều đối với một số số liệu nhất định. Lượng công việc cần thiết để đạt được các số liệu đó là không khả thi đối với SMB trung bình của bạn. Tôi biết rằng tôi không thể tự mình làm được.

Tin tốt là không thiếu các dịch vụ lưu trữ đối tượng, nghĩa là giá cả phải cạnh tranh. Giá của S3 là một trong những mức giá thấp nhất trong số tất cả các dịch vụ AWS, không phải vì nó là sản phẩm lỗ mà vì nó được xây dựng hiệu quả và vì nguồn cung của các nhà cung cấp buộc giá thị trường phải giảm xuống.

Thậm chí còn tốt hơn, với tư cách là một dịch vụ dựa trên HTTP, S3 chỉ là nguồn dữ liệu của những gì có thể trở thành một đường ống lớn hơn. Cá nhân tôi sử dụng S3 làm nguồn truy xuất cho các CDN như AWS CloudFront cho bất kỳ số lượng máy khách web front-end nào. Không chỉ có nhiều dịch vụ CDN khác nhau trên thị trường, mà còn rẻ hơn nhiều so với việc có một máy chủ chuyên dụng để lưu trữ tệp của bạn, vì mỗi CDN sẽ ghép kênh nhiều yêu cầu từ nhiều người dùng khác nhau, giúp khấu hao chi phí máy chủ. Bạn có được điều tốt nhất của cả hai thế giới: khả năng sẵn sàng trên quy mô đám mây và bạn có thể thương mại hóa các phần bổ sung của mình.

Tôi không chắc liệu có giải pháp thay thế nguồn mở khả thi nào cho S3 không. Giải pháp gần nhất mà tôi biết có thể là OpenStack Swift , nhưng nếu đó chỉ là 1 phần trăm công sức mà AWS bỏ ra cho S3, tôi sẽ rất ngạc nhiên.

Nói như vậy, tôi nghĩ điều quan trọng là phải đề cập đến một số dịch vụ mà tôi sẽ tránh hoặc thay thế khi có thể. Cá  nhân tôi thích máy chủ hơn không có máy chủ, vì tôi muốn biết rõ chu kỳ thanh toán của mình sẽ như thế nào trước thời hạn thay vì thanh toán theo từng lần chạy chức năng và vì tôi duy trì môi trường nơi mọi thứ của mình chạy. Đối với các quy trình công việc phức tạp hơn, chẳng hạn như triển khai cơ sở dữ liệu của riêng bạn, không có máy chủ vẫn chưa phải là tùy chọn mà tôi có thể cân nhắc cho các tác vụ có trạng thái như cung cấp lưu trữ. Có một vị trí cho không có máy chủ; Tôi sử dụng nó để xác thực trang web tĩnh và tôi thích cách RDS sử dụng không có máy chủ để tự động xoay vòng bí mật. Tuy nhiên, về cơ bản, máy chủ đánh bại không có máy chủ khi nói đến việc có nhiều tùy chọn hơn. Hãy cân nhắc triển khai Firecracker để cung cấp dịch vụ chức năng tự quản lý dưới dạng dịch vụ.

Một mối quan tâm đáng ngạc nhiên mà tôi có là chạy container trên đám mây. Tôi thích container vì nó đóng gói mã ứng dụng cho một thời gian chạy hoàn chỉnh, điều này thực sự quan trọng đối với những thứ như vận chuyển dự án một cách nhất quán tùy thuộc vào các ràng buộc xuyên ngôn ngữ cơ bản. Tuy nhiên, theo kinh nghiệm vận hành của tôi, container đã thêm một số mức độ sai lệch. Là một người thích tính bảo mật của nocode , container cũng thêm một lớp trừu tượng khác lên trên VM, nơi mọi thứ có thể xảy ra sai sót. Cuối cùng, container có thể không có cùng mức hỗ trợ trình điều khiển như VM và đưa ra một tập hợp các đánh đổi khác nhau trong các lĩnh vực như bảo mật ứng dụng. Tôi sử dụng container vì mục đích tiện lợi, nhưng tôi đánh giá cao cách chúng có thể giảm các tùy chọn của tôi.

Cuối cùng, tôi nghĩ nếu có một cuộc tranh luận giữa các nền tảng cơ sở hạ tầng dưới dạng mã như Terraform so với CloudFormation, thì nó hơi cường điệu. Cá nhân tôi sử dụng CloudFormation vì hiện tại tôi đang sử dụng AWS, nó có GUI đẹp để quản lý các ngăn xếp trong quá trình sản xuất và tích hợp tốt với bộ phận hỗ trợ nhà phát triển của AWS. Tuy nhiên, cuối cùng thì nó chỉ là dữ liệu và dữ liệu mở dễ quản lý hơn nhiều so với bất kỳ dịch vụ đám mây cụ thể nào. Nó cũng không loại trừ lẫn nhau; nếu cần, Terraform có thể triển khai các ngăn xếp CloudFormation .

Hầu hết các kỹ sư phần mềm đều phục vụ nhu cầu của người khác, và chúng ta càng có thể mang lại sự linh hoạt cho bàn thảo luận, chúng ta càng có thể hy vọng thấy được sự thống nhất. Kinh nghiệm của tôi với DevOps đã dạy cho tôi rằng thiết kế hệ thống là một phần quan trọng để đạt được sự linh hoạt đó. Việc gắn bó với các dịch vụ được hiểu rõ thay vì lựa chọn một tùy chọn dễ dàng hơn sẽ dẫn đến nhiều đau đớn hơn lúc đầu nhưng có thể giúp hiện thực hóa các khả năng lâu dài. Tôi thích nghĩ rằng mình là người coi trọng các giá trị của sự độc lập và làm việc chăm chỉ. Vì mục đích đó, tôi thấy rằng việc đạt được sự tùy chọn này rất đáng để xem xét, và tôi không nghĩ mình là người duy nhất trong vấn đề đó.