3.11 Kiến trúc đám mây

Tổng quan và động lực

Điện toán đám mây là thuê hạ tầng của người khác theo yêu cầu, qua mạng, tính phí theo mức dùng, và trả lại khi xong. Kiến trúc đám mây là kỷ luật thiết kế các hệ thống coi những tài nguyên thuê đó là ngôi nhà bản địa của chúng thay vì một bản sao thuê của trung tâm dữ liệu cũ của bạn. Sự phân biệt đó là toàn bộ ý nghĩa của chương này. Bạn có thể chuyển một ứng dụng cũ sang một nhà cung cấp đám mây mà không đổi gì về thiết kế, và bạn sẽ nhận một hóa đơn lớn hơn cùng sự mong manh gần như cũ. Hoặc bạn có thể thiết kế cho đám mây và có được tính co giãn, các dịch vụ được quản lý xóa sạch cả loại công việc không tạo khác biệt, và khả năng sống sót qua sự hỏng của cả một tòa nhà mà không phải gọi ai dậy. Điều này xây trực tiếp trên các nguyên lý cơ bản ở chương 3.1: kiến trúc đám mây là kiến trúc, với cùng các đánh đổi và thuộc tính chất lượng, áp dụng cho một nền bạn không sở hữu.

Với các đội lớn, rủi ro cao hơn vì đám mây nối lại ai làm gì. Khi một đội có thể cung cấp cơ sở dữ liệu, hàng đợi và bộ cân bằng tải toàn cầu trong vài phút, nút thắt thôi là mua sắm và trở thành quản trị: chi phí, bảo mật và sự nhất quán qua hàng chục đội làm việc này cùng lúc. Đám mây cho mỗi kỹ sư một chiếc thẻ tín dụng công ty và một nhà kho đầy công cụ điện, vừa tuyệt vời vừa nguy hiểm như nhau. Làm đúng kiến trúc nghĩa là nắm bắt phần lợi (tốc độ, co giãn, khả năng phục hồi) trong khi lắp đặt các lan can giữ chi tiêu, tư thế bảo mật và nơi lưu trữ dữ liệu dưới kiểm soát.

Doanh nghiệp và chính phủ cảm nhận cả hai lưỡi dao sắc bén. Doanh nghiệp đến với nhiều thập kỷ hệ thống hiện có, nên câu chuyện đám mây của họ thường là câu chuyện di chuyển, đầy kết nối lai và các quyết định mua-so-với-xây khó khăn. Chính phủ mang thêm sức nặng của chủ quyền, chế độ cấp phép, và dữ liệu công dân mà về mặt pháp lý không được rời một số biên giới. Các quyết định ở đây (mô hình dịch vụ nào, bao nhiêu nhà cung cấp, miền lỗi nằm đâu, cái gì chạy như dịch vụ được quản lý so với mã của chính bạn) định hình chi phí và rủi ro trong một thập kỷ.

Các nguyên tắc chính

Thiết kế cho đám mây, đừng chụp ảnh trung tâm dữ liệu của bạn. Tính co giãn, dịch vụ được quản lý và nhận thức về miền lỗi là lý do để ở đây; nhấc-và-đặt vứt bỏ chúng.
Mọi thứ được cung cấp dưới dạng mã. Nếu một con người bấm chuột để nó tồn tại, nó không có tài liệu, không lặp lại được và không kiểm toán được.
Thiết kế qua các miền lỗi có chủ đích. Vùng, vùng sẵn sàng và dịch vụ đều thất bại; kiến trúc của bạn quyết định đó là một cái nhún vai hay một sự cố.
Mô hình trách nhiệm chia sẻ là một hợp đồng, không phải khẩu hiệu. Biết chính xác ranh giới nào nhà cung cấp bảo mật và ranh giới nào bạn bảo mật.
Mua cái không tạo khác biệt, xây cái tạo khác biệt. Dịch vụ được quản lý đáng giá tiền thật cho hệ thống ống nước; hãy giữ lợi thế cạnh tranh trong tay bạn.
Khóa chặt là một chi phí cần định giá, không phải tội lỗi cần tránh. Tính di động có giá và đòn bẩy có giá trị; hãy quyết định có chủ đích thay vì theo phản xạ.
Chi phí là thuộc tính chất lượng hạng nhất. Trong đám mây, kiến trúc và hóa đơn là cùng một quyết định.

Khuyến nghị

Chọn mô hình dịch vụ có chủ đích, và mặc định là được quản lý

Các nhà cung cấp đám mây bán dọc theo một dải được nắm bắt bởi các mô hình như-một-dịch-vụ: Hạ tầng như một Dịch vụ (IaaS) cho thuê tính toán, lưu trữ và mạng thô; Nền tảng như một Dịch vụ (PaaS) cho thuê một môi trường chạy được quản lý để bạn triển khai mã mà không chăm máy chủ; Phần mềm như một Dịch vụ (SaaS) cho thuê ứng dụng hoàn chỉnh. Điện toán serverless, bao gồm hàm và dịch vụ hướng sự kiện được quản lý, đẩy xa hơn: bạn cung cấp mã hoặc cấu hình và nhà cung cấp xử lý mọi việc cung cấp tài nguyên, mở rộng về không khi rảnh. Mỗi bước lên trên dải này đánh đổi quyền kiểm soát lấy đòn bẩy, từ IaaS với nhiều kiểm soát nhất và gánh nặng vận hành nhiều nhất đến serverless với cả hai ít nhất.

Mặc định nên là leo cao trên dải đó chừng nào yêu cầu của bạn còn cho phép. Một cơ sở dữ liệu được quản lý xử lý vá lỗi, sao lưu, chuyển đổi dự phòng và mở rộng hầu như luôn là cách dùng kỹ sư của bạn tốt hơn so với tự chạy. Dành IaaS cấp thấp hơn cho những trường hợp thực sự cần: phần cứng chuyên dụng, ranh giới tuân thủ khác thường, ràng buộc giấy phép, hoặc hiệu năng mà sản phẩm được quản lý không đáp ứng được. Hãy ghi lý do ra thành hồ sơ quyết định kiến trúc (chương 3.1), vì “chúng tôi tự chạy bộ môi giới thông điệp” là một tuyên bố nên được biện minh lại mỗi năm.

Thiết kế qua vùng và vùng sẵn sàng như các miền lỗi tường minh

Một vùng đám mây là một khu vực địa lý; bên trong nó, vùng sẵn sàng là các trung tâm dữ liệu tách biệt vật lý với điện, làm mát và mạng độc lập, đủ gần để sao chép độ trễ thấp nhưng đủ xa để một cái hỏng không kéo theo các cái khác. Đây là các đường nối dọc theo đó đám mây vỡ ra, nên kiến trúc của bạn phải coi chúng là hạng nhất. Đường cơ sở cho bất kỳ khối lượng công việc nghiêm túc nào là đa vùng sẵn sàng: trải tính toán và dữ liệu qua ít nhất hai, lý tưởng ba, vùng sẵn sàng để mất một cái làm giảm năng lực thay vì gây sự cố. Đây là bảo hiểm rẻ hiếm khi có lý do tốt để bỏ qua.

Đa vùng là một quyết định nặng hơn, gắn với các mục tiêu phục hồi và khôi phục của bạn (chương 3.5) và kế hoạch khôi phục thảm họa (chương 9.5). Trải qua nhiều vùng mua cho bạn sự sống sót trước sự hỏng của cả một vùng và có thể đặt dữ liệu gần người dùng hơn, nhưng nó đưa vào các vấn đề chi phí, độ trễ và nhất quán thực sự, vì sao chép đồng bộ xuyên vùng thì chậm và sao chép bất đồng bộ nghĩa là chấp nhận mất dữ liệu khi chuyển đổi dự phòng. Hãy quyết định dựa trên mục tiêu thời gian khôi phục và điểm khôi phục tường minh, không phải một ước muốn mơ hồ là “sẵn sàng cao.” Hầu hết các hệ thống cần đa vùng sẵn sàng vững và một đường khôi phục đa vùng đã kiểm thử; ít cái thực sự cần chủ động-chủ động xuyên vùng, và những cái xây nó mà không cần trả giá cho độ phức tạp mỗi ngày.

Coi mô hình trách nhiệm chia sẻ là một ranh giới kiến trúc

Bảo mật đám mây vận hành trên một mô hình trách nhiệm chia sẻ: nhà cung cấp bảo mật đám mây (cơ sở vật lý, hypervisor, phần bên trong dịch vụ được quản lý) và bạn bảo mật những gì bạn đặt trong đám mây (dữ liệu, kiểm soát truy cập, cấu hình mạng và mã của bạn). Ranh giới chính xác dịch chuyển khi bạn leo lên dải dịch vụ. Với IaaS bạn vá hệ điều hành; với cơ sở dữ liệu được quản lý bạn không, nhưng bạn vẫn sở hữu ai có thể kết nối và dữ liệu có được mã hóa không. Các sự cố đắt nhất đến từ đọc sai ranh giới này, nổi tiếng nhất là cái thùng lưu trữ mở làm rò rỉ hàng triệu bản ghi vì ai đó giả định nhà cung cấp đã đặt nó riêng tư theo mặc định.

Hãy làm ranh giới tường minh trong thiết kế của bạn và chuyển các chi tiết sang chương 4.3, bao quát sâu về bảo mật hạ tầng và đám mây. Về kiến trúc, các mệnh lệnh là không đổi: mã hóa dữ liệu khi lưu và khi truyền theo mặc định, cấp quyền tối thiểu qua danh tính thay vì vị trí mạng, giữ bán kính ảnh hưởng của bất kỳ thông tin xác thực đơn lẻ nào nhỏ, và giả định bất kỳ tài nguyên nào với tới được từ internet sẽ bị dò quét trong vài phút. Hãy đưa những điều này vào vùng hạ cánh của bạn để các đội thừa hưởng chúng.

Cung cấp mọi thứ dưới dạng mã, trong một vùng hạ cánh được quản trị

Trong một thực hành đám mây trưởng thành, không tài nguyên sản xuất nào tồn tại vì một người bấm vào bảng điều khiển. Mọi thứ được khai báo trong hạ tầng dưới dạng mã (chương 8.2), được quản lý phiên bản, rà soát và áp dụng qua một đường ống, để hạ tầng của bạn tái lập được, kiểm toán được và so sánh được. Đây là điều làm cho đa vùng sẵn sàng, đa vùng và khôi phục thảm họa thành thật thay vì khát vọng: bạn có thể dựng một môi trường y hệt ở vùng mới vì môi trường là một chương trình, không phải một ký ức.

Hãy bọc mã đó trong một vùng hạ cánh: một nền tảng dựng sẵn, được quản trị gồm tài khoản (hoặc đăng ký hay dự án), mạng, danh tính, ghi nhật ký và lan can mà mọi đội xây dựng trên đó. Dùng các tài khoản riêng làm ranh giới bán kính ảnh hưởng và thanh toán, để sai lầm của một đội không với tới dữ liệu của đội khác và mỗi đồng đều truy được về một chủ sở hữu. Thực thi lan can dưới dạng chính sách-dưới-dạng-mã ngăn các cấu hình bị cấm (cơ sở dữ liệu công khai, ổ không mã hóa, tài nguyên ở vùng không được phép) thay vì dựa vào rà soát sau sự việc. Một đội nền tảng trung tâm thường sở hữu vùng hạ cánh, nối chương này với kỹ thuật nền tảng (chương 8.4) và với container cùng môi trường chạy bản địa đám mây (chương 8.3).

Định giá khóa chặt một cách trung thực, và hoài nghi về đa đám mây

Khóa chặt nhà cung cấp là chi phí chuyển đổi nhà cung cấp, và nó là một dải liên tục, không phải nhị phân. Dùng hàng đợi được quản lý của một nhà cung cấp tạo ra một ít khóa chặt; dùng nền tảng học máy độc quyền của họ tạo ra nhiều. Nỗi sợ phản xạ về nó khiến các đội hy sinh đòn bẩy thực (các dịch vụ được quản lý làm cho đám mây đáng dùng) để bảo toàn một tính di động mà họ sẽ không bao giờ dùng đến. Bước đi trung thực là định giá nó: với mỗi phụ thuộc đáng kể, ước tính rời đi thực sự sẽ tốn bao nhiêu và cân nhắc nó so với những gì dịch vụ tiết kiệm cho bạn bây giờ. Trừu tượng hóa một dịch vụ được quản lý để giữ tính di động thường tốn hơn, vĩnh viễn, so với cuộc di chuyển mà bạn đang bảo hiểm.

Đây là lý do đa đám mây thực sự (chạy cùng một khối lượng công việc qua hai nhà cung cấp) thường là sùng bái hình thức hơn là chiến lược. Nó ép bạn xuống mẫu số chung thấp nhất, nhân đôi bề mặt vận hành, và nhân lên chuyên môn mà các đội phải nắm, tất cả để phòng ngừa một rủi ro hiếm khi xảy ra. Có những lý do chính đáng để chạm vào nhiều hơn một nhà cung cấp: một SaaS tốt nhất trong loại từ nhà cung cấp thứ hai, yêu cầu về khả năng phục hồi từ cơ quan quản lý, hoặc một yêu cầu chủ quyền có chủ đích (chương 10.11). Đám mây lai, giữ một số hệ thống tại chỗ kết nối với đám mây, thường không thể tránh trong quá trình di chuyển doanh nghiệp và với dữ liệu mà về mặt pháp lý không thể di chuyển. Hãy chọn những điều này với đôi mắt tỉnh táo và một lý do bằng văn bản, không phải vì một bộ slide nói “đa đám mây.”

Kiến trúc cho chi phí, và áp dụng tư duy được kiến trúc tốt

Trong đám mây, một quyết định kiến trúc là một quyết định chi tiêu: cấp thừa “phòng khi” hiện ra trên hóa đơn tháng sau. Hãy coi chi phí là thuộc tính chất lượng bạn thiết kế cho, và áp dụng thực hành FinOps, kỷ luật chia sẻ trách nhiệm tài chính cho chi tiêu đám mây (chương 9.4), để kỹ thuật, tài chính và sản phẩm cùng sở hữu hóa đơn. Gắn thẻ mọi tài nguyên với một chủ sở hữu, làm chi phí hiển thị theo đội và theo dịch vụ, liên tục định cỡ phù hợp, dùng tự động mở rộng để bạn trả theo tải thay vì theo đỉnh, và khai thác các đòn bẩy giá (giảm giá cam kết sử dụng, năng lực spot cho công việc có thể bị gián đoạn) mà đám mây cung cấp.

Ngoài chi phí, hãy dùng một khung được kiến trúc tốt làm danh sách kiểm tra rà soát. Các nhà cung cấp lớn mỗi bên đều công bố một khung, và chúng hội tụ về cùng các trụ cột: độ tin cậy, bảo mật, tối ưu chi phí, hiệu quả hiệu năng, xuất sắc vận hành và tính bền vững. Chạy một đợt rà soát nhẹ lúc thiết kế và định kỳ sau đó, chấm điểm hệ thống theo từng trụ cột và ghi các khoảng trống thành công việc được theo dõi. Đó là cách rẻ để bắt được đánh đổi bạn không để ý.

Đánh đổi: ưu và nhược điểm

Cách tiếp cận	Ưu điểm	Nhược điểm
Nhấc-và-đặt (rehost)	Nhanh, công sức ban đầu thấp, rời trung tâm dữ liệu nhanh	Giữ sự mong manh cũ, bỏ lỡ tính co giãn và dịch vụ được quản lý, thường tốn hơn
Thiết kế lại bản địa đám mây	Co giãn đầy đủ, khả năng phục hồi, đòn bẩy dịch vụ được quản lý	Công sức và kỹ năng ban đầu cao hơn; thay đổi lớn hơn để tiếp nhận
Một đám mây, tích hợp sâu	Đơn giản, đòn bẩy tối đa, bề mặt vận hành thấp hơn	Khóa chặt tập trung và rủi ro nhà cung cấp
Đa đám mây (cùng khối lượng công việc, hai nhà cung cấp)	Phòng ngừa hỏng nhà cung cấp, đòn bẩy thương lượng	Thiết kế mẫu số chung thấp nhất, nhân đôi vận hành và chuyên môn
Lai (đám mây cộng tại chỗ)	Đáp ứng ràng buộc nơi lưu trữ dữ liệu và hệ thống cũ, di chuyển theo giai đoạn	Độ phức tạp mạng, hai mô hình vận hành phải chạy cùng lúc
Serverless / được quản lý cao	Công việc nặng nhọc tối thiểu, mở rộng về không, phân phối nhanh	Ít kiểm soát hơn, đặc thù nhà cung cấp, giới hạn khởi động lạnh và hạn ngạch

Căng thẳng trung tâm là kiểm soát so với đòn bẩy, và nó chạy qua mọi hàng. Bạn giao càng nhiều cho nhà cung cấp, bạn di chuyển càng nhanh và vận hành càng ít, với cái giá là liên kết sâu hơn. Cách giải quyết không phải chọn một cực mà là đặt từng khối lượng công việc một cách có chủ đích: leo cao trên dải được quản lý cho hệ thống ống nước hàng hóa, ở thấp hơn nơi kiểm soát thực sự xứng đáng, và định giá khóa chặt theo cả hai hướng thay vì coi tính di động là miễn phí và sự phụ thuộc là tội lỗi. Các tổ chức lớn gặp rắc rối khi họ để nỗi sợ (khóa chặt, đám mây, chi phí) đưa ra lựa chọn này theo phản xạ thay vì theo phân tích.

Câu hỏi để thảo luận với đội của bạn

Khối lượng công việc nào của chúng ta được nhấc-và-đặt, và chúng ta có đang trả giá đám mây cho kiến trúc trung tâm dữ liệu không? Phổ biến là di chuyển dưới hạn chót, rehost mọi thứ như cũ, và tuyên bố chiến thắng, rồi phát hiện hóa đơn cao hơn trung tâm dữ liệu và không lợi ích nào về khả năng phục hồi hay co giãn thành hiện thực. Cuộc kiểm toán trung thực là liệt kê các khối lượng công việc chính của bạn và đánh dấu từng cái là được rehost, tái nền tảng, hay thực sự được thiết kế lại, rồi xem cái nào vẫn chạy trên dấu chân cỡ cố định, luôn bật, một vùng sẵn sàng. Một số nhấc-và-đặt là bước đầu chính đáng, nên câu hỏi không phải bạn có làm không mà là bạn có kế hoạch và mốc thời gian để đi xa hơn không. Hãy mang chi phí theo khối lượng công việc và lịch sử sự cố, vì những khối lượng công việc vừa đắt vừa mong manh là nơi thiết kế lại hoàn vốn nhanh nhất. Nếu mọi thứ vẫn có hình dạng của trung tâm dữ liệu cũ một năm sau di chuyển, bạn đã mua một trung tâm dữ liệu đắt hơn.
Khi một vùng sẵn sàng hay cả một vùng hỏng, điều gì thực sự xảy ra, và chúng ta đã kiểm thử chưa? Nhiều đội tin rằng họ phục hồi tốt vì đã triển khai lên đám mây, mà chưa thiết kế miền lỗi của mình hay từng rút phích cắm để kiểm tra. Phiên bản cụ thể: với mỗi hệ thống quan trọng, nó trải qua bao nhiêu vùng sẵn sàng, mục tiêu thời gian khôi phục và điểm khôi phục được lập tài liệu là gì, và lần cuối chúng ta chạy một ngày diễn tập làm hỏng một vùng sẵn sàng hay diễn tập khôi phục một vùng là khi nào? Đa vùng sẵn sàng nên là đường cơ sở không đáng nói, nên bất kỳ khối lượng công việc quan trọng một vùng sẵn sàng nào cũng là một phát hiện; đa vùng là quyết định nặng hơn, tốn hơn gắn với các mục tiêu khôi phục tường minh, không được áp dụng theo mặc định. Hãy mang sơ đồ phụ thuộc của bạn, vì thất bại gây đau thường là một dịch vụ dùng chung (cơ sở dữ liệu, nhà cung cấp danh tính) mà miền lỗi của nó không ai vẽ ra. Khả năng phục hồi bạn chưa bao giờ kiểm thử là một giả thuyết, không phải một thuộc tính.
Với các phụ thuộc nhà cung cấp lớn nhất của chúng ta, rời đi thực sự tốn bao nhiêu, và đó có phải cái giá đáng trả để tránh không? Các cuộc tranh luận về khóa chặt có xu hướng chạy theo ý thức hệ thay vì con số, với một phe trừu tượng hóa mọi dịch vụ được quản lý để giữ tính di động và phe khác phớt lờ hoàn toàn rủi ro tập trung. Hãy cụ thể hóa: chọn ba phụ thuộc sâu nhất của bạn, ước tính chi phí kỹ thuật và thời gian trôi qua thực để thay thế từng cái, và cân nhắc điều đó so với những gì dịch vụ tiết kiệm cho bạn hôm nay và khả năng bạn từng chuyển đổi. Thêm vào các rủi ro mà tính di động không sửa được, như cơ quan quản lý yêu cầu nguồn thứ hai hoặc quy tắc chủ quyền về nơi dữ liệu được phép cư trú, vì chúng có thể biện minh cho đa đám mây hoặc lai ngay cả khi kinh tế thuần túy không. Mục tiêu là một lập trường có chủ đích, bằng văn bản cho từng phụ thuộc, không phải một chính sách chung. Khi bạn định giá nó, hầu hết khóa chặt đáng sợ hóa ra rẻ để chấp nhận hơn tầng trừu tượng xây để tránh nó.
Chúng ta đang tự chạy những dịch vụ nào mà nhà cung cấp sẵn lòng vận hành giúp, và lựa chọn đó đang tốn bao nhiêu giờ kỹ sư? Toàn bộ đòn bẩy của đám mây là giao việc vá lỗi, sao lưu, chuyển đổi dự phòng và mở rộng cho người mà công việc toàn thời gian là những việc đó, vậy mà các đội thường xuyên giữ cơ sở dữ liệu, bộ môi giới thông điệp hay cụm tìm kiếm tự chạy vì thói quen hoặc lòng tự hào đặt sai chỗ. Với một tổ chức lớn chi phí không phải là công việc nặng nhọc của một đội mà là cùng những vận hành không tạo khác biệt được phát minh lại ở cả chục góc, mỗi cái là một vòng trực ca và một nguồn trôi dạt. Cân nhắc đối lập là có thật: phần cứng chuyên dụng, điều khoản giấy phép, ranh giới tuân thủ khác thường, hoặc hiệu năng mà sản phẩm được quản lý không đáp ứng được có thể biện minh việc ở thấp hơn trên dải, nên câu trả lời là theo từng dịch vụ chứ không chung. Hãy mang bản kiểm kê các dịch vụ tự vận hành, số giờ kỹ sư mỗi cái tiêu tốn cho bảo trì và sự cố, và giá của phương án được quản lý thay thế, và yêu cầu một hồ sơ quyết định kiến trúc cho mọi “chúng tôi tự chạy” được biện minh lại hằng năm. Trong bối cảnh doanh nghiệp và chính phủ, hãy thêm liệu lựa chọn tự chạy có thực sự là ràng buộc tuân thủ hay giấy phép hay chỉ là quán tính khoác áo đó, vì kiểm toán viên và chủ ngân sách sẽ hỏi cùng một câu.
Chúng ta có thể thấy mỗi đội và dịch vụ tốn bao nhiêu tháng này không, và có người được nêu tên cảm thấy chịu trách nhiệm về con số đó không? Chi tiêu đám mây phình lên trong im lặng vì cùng sự tự phục vụ cho phép một kỹ sư cung cấp một cơ sở dữ liệu toàn cầu trong vài phút cũng cho phép họ để nó chạy ở cỡ đỉnh mãi mãi, và không dòng hóa đơn đơn lẻ nào trông đáng báo động. Trong một tổ chức lớn không có khả năng nhìn chi phí theo đội và theo dịch vụ, tài chính phát hiện vấn đề muộn nhiều tháng và phản ứng là một lệnh đóng băng cùn trừng phạt người có kỷ luật cùng với người lãng phí. Căng thẳng là thật: đuổi theo từng đồng làm chậm phân phối, nên mục tiêu là trách nhiệm giải trình và định cỡ phù hợp, không phải thắt lưng buộc bụng, với chi phí được coi là thuộc tính chất lượng bạn thiết kế cho thay vì báo cáo bạn đọc sau sự việc. Hãy mang bảng phân tích chi phí theo đội, tỷ lệ chi tiêu chưa gắn thẻ hoặc không quy được, mức sử dụng hiện tại so với năng lực được cung cấp, và nơi giảm giá cam kết sử dụng hoặc năng lực spot đang bị bỏ lỡ. Với doanh nghiệp và cơ quan chính phủ, hãy gắn điều này với thực hành FinOps và sự soi xét chi tiêu công, vì một tài nguyên chưa gắn thẻ không chỉ là lãng phí mà còn là một phát hiện kiểm toán đang chờ.
Một đội có thể dựng một kho dữ liệu công khai, một ổ không mã hóa, hay một tài nguyên ở vùng bị cấm ngay bây giờ không, và chúng ta có biết không? Hầu hết các sự cố đám mây đắt đỏ là cấu hình sai, không phải vi phạm nhà cung cấp, và mô hình trách nhiệm chia sẻ nghĩa là cái thùng lưu trữ rò rỉ hay cơ sở dữ liệu mở ra internet nằm trọn bên phía ranh giới của bạn. Ngăn điều này ở quy mô nhiều đội là một câu hỏi về vùng hạ cánh: lan can được thực thi dưới dạng chính sách-dưới-dạng-mã chặn các cấu hình bị cấm trước khi chúng tồn tại, thay vì rà soát sau sự việc chỉ tìm thấy chúng khi hồ sơ đã rò rỉ. Áp lực đối lập là quyền tự chủ của lập trình viên, vì lan can quá chặt đẩy các đội vào tài khoản bóng tối, nên thiết kế phải ngăn điều thực sự nguy hiểm trong khi vẫn để chỗ di chuyển. Hãy mang bản kiểm kê các lan can thực sự được thực thi, một nỗ lực trung thực cung cấp một tài nguyên không tuân thủ trong một tài khoản thật, và độ trễ phát hiện khi phòng ngừa thất bại. Trong bối cảnh chịu quy định và chính phủ, hãy kết nối điều này với nơi lưu trữ dữ liệu và chế độ cấp phép, vì một tài nguyên ở vùng không được phép không phải vi phạm phong cách mà là vi phạm pháp lý mà kiểm toán viên sẽ coi là sự kiện phải báo cáo.

Góc nhìn theo lĩnh vực

Công ty khởi nghiệp. Hãy đi bản địa đám mây trên một nhà cung cấp duy nhất từ ngày đầu và chấp nhận khóa chặt một cách có chủ đích. Chạy trên serverless và dịch vụ được quản lý mở rộng về không và để hai kỹ sư sở hữu toàn bộ nền tảng, vì nguồn lực khan hiếm nhất của bạn là sự chú ý, không phải tính di động. Hãy giới hạn chi tiêu chặt, giữ mọi thứ trong hạ tầng-dưới-dạng-mã để một khoảnh khắc lan truyền không biến thành sự cố, và ghi quyết định khóa chặt có chủ đích ra để xem lại ở quy mô lớn hơn thay vì giả vờ nó là tạm thời.

Doanh nghiệp nhỏ. Không có kỹ sư nền tảng và ngân sách eo hẹp, hãy coi đám mây là thứ bạn tiêu thụ chứ không vận hành. Ưu tiên SaaS và dịch vụ được quản lý hoàn toàn hơn bất cứ thứ gì bạn tự chạy, dựa vào mặc định an toàn của nhà cung cấp, và để cơ sở dữ liệu được quản lý xử lý sao lưu và chuyển đổi dự phòng để không ai phải làm. Hãy đóng khung lựa chọn là mua-so-với-xây với ngón tay cái mạnh về phía mua, đặt cảnh báo thanh toán để một tài nguyên bị quên không rút cạn tháng, và với tới một lựa chọn ít mã hoặc được quản lý trước khi bạn dựng các máy chủ bạn không thể bố trí nhân sự.

Doanh nghiệp lớn. Câu chuyện đám mây của bạn là câu chuyện di chuyển qua nhiều đội, nên kiến trúc thực ra là một vấn đề quản trị. Hãy dựng một vùng hạ cánh được quản trị với các tài khoản theo đơn vị làm ranh giới bán kính ảnh hưởng và thanh toán, lan can mã hóa-theo-mặc định, và chính sách-dưới-dạng-mã chặn các kho dữ liệu công khai, và để một đội nền tảng trung tâm sở hữu nền móng đó. Chạy FinOps với showback theo đội, kiểm soát các thiết kế quan trọng bằng một đợt rà soát được kiến trúc tốt, và quản lý kết nối lai đến các hệ thống ghi nhận cũ sẽ không di chuyển trong nhiều năm.

Chính phủ. Quy tắc mua sắm, minh bạch và chủ quyền định hình mọi quyết định. Hãy triển khai vào một vùng đám mây được cấp phép hoặc của chính phủ, lập tài liệu ranh giới trách nhiệm chia sẻ từng dòng một cho kiểm toán viên, và ghim lưu trữ cùng xử lý vào các vùng trong nước bằng chính sách-dưới-dạng-mã chặn bất kỳ tài nguyên nào ở vùng không được phép. Theo đuổi chế độ cấp phép bắt buộc, giữ bằng chứng kiểm toán dưới dạng lịch sử git thay vì cuộc chạy vạy, và ưu tiên các dịch vụ được quản lý mà nhà cung cấp sẽ xác nhận tư thế tuân thủ hơn hạ tầng làm riêng mà bạn phải tự chứng nhận.

Ví dụ

Công ty khởi nghiệp. Một công ty khởi nghiệp mười hai người xây dựng bản địa đám mây từ ngày đầu trên một nhà cung cấp duy nhất và không cảm thấy tội lỗi về điều đó. API chạy trên các hàm serverless mở rộng về không qua đêm, dữ liệu sống trong một Postgres được quản lý với sao lưu tự động và chuyển đổi dự phòng đa vùng sẵn sàng, và các công việc nền chạy trên một hàng đợi được quản lý. Tất cả được định nghĩa trong hạ tầng-dưới-dạng-mã, và hai kỹ sư sở hữu toàn bộ nền tảng vì nhà cung cấp vận hành những phần khó. Khi một khoảnh khắc lan truyền làm lưu lượng tăng năm mươi lần trong một giờ, tự động mở rộng hấp thụ nó và hóa đơn tăng tỷ lệ với mức dùng thực, rồi giảm lại. Những người sáng lập chủ ý chấp nhận khóa chặt như cái giá của việc di chuyển nhanh với một đội nhỏ xíu, và họ ghi quyết định đó ra để xem lại ở quy mô lớn hơn.

Doanh nghiệp lớn. Một công ty bảo hiểm đa quốc gia với ba trăm ứng dụng cũ chạy một cuộc di chuyển nhiều năm được điều chỉnh bởi “6 R” (rehost, re-platform, repurchase, refactor, retire, retain). Các ứng dụng hàng hóa giá trị thấp được rehost nhanh để rời hai trung tâm dữ liệu đúng hạn; nền tảng hợp đồng lõi được tái cấu trúc để bản địa đám mây; các công cụ tự chế được mua lại dưới dạng SaaS; và các hệ thống lỗi thời được loại bỏ. Một đội nền tảng trung tâm sở hữu một vùng hạ cánh với các tài khoản theo đơn vị kinh doanh, lan can mã hóa-theo-mặc định, và chính sách-dưới-dạng-mã chặn các kho dữ liệu công khai, trong khi kết nối lai nối đám mây với các hệ thống ghi nhận máy tính lớn sẽ không di chuyển trong nhiều năm. Chi phí được quản trị qua thực hành FinOps với showback theo đơn vị, và một đợt rà soát được kiến trúc tốt kiểm soát việc ra mắt sản xuất của mỗi ứng dụng.

Chính phủ. Một cơ quan quốc gia cung cấp dịch vụ trợ cấp cho công dân bị luật yêu cầu giữ dữ liệu cư dân trong biên giới quốc gia và chạy trên hạ tầng được cấp phép. Họ triển khai vào vùng đám mây chính phủ của nhà cung cấp và theo đuổi một sự cấp phép theo một chế độ như FedRAMP ở Hoa Kỳ (với công việc tuân thủ trong chương 4.6), lập tài liệu ranh giới trách nhiệm chia sẻ từng dòng một cho kiểm toán viên. Nơi lưu trữ dữ liệu và các mối quan tâm chủ quyền rộng hơn (chương 10.11) thúc đẩy một kiến trúc ghim lưu trữ và xử lý vào các vùng trong nước và chặn, qua chính sách-dưới-dạng-mã, bất kỳ tài nguyên nào ở vùng không được phép. Hệ thống trải qua ba vùng sẵn sàng với một kế hoạch khôi phục xuyên vùng sẵn sàng đã kiểm thử và cung cấp mọi thứ dưới dạng mã, nên bằng chứng kiểm toán là một lịch sử git thay vì một cuộc chạy vạy.

Luận chứng kinh doanh: động lực, ROI và TCO

Lời hứa nổi bật của đám mây là biến chi tiêu vốn thành chi tiêu vận hành: thay vì mua máy chủ trước nhu cầu nhiều năm và chạy chúng ở mức sử dụng thấp, bạn trả cho những gì bạn dùng và mở rộng theo doanh nghiệp. Điều đó là thật, nhưng lợi tức sâu hơn là tốc độ và sự tập trung. Một dịch vụ được quản lý xóa vá lỗi, sao lưu và chuyển đổi dự phòng trả những giờ kỹ sư đó về công việc sản phẩm, và cung cấp trong vài phút thay vì vài tháng nén thời gian từ ý tưởng đến sản xuất. Tính co giãn nghĩa là bạn thôi trả tiền cho năng lực đỉnh bạn dùng hai lần một năm. Khi kiến trúc đúng, những điều này cộng dồn thành một tổng chi phí sở hữu thắng trung tâm dữ liệu cả về chi phí lẫn năng lực.

Chi phí của việc làm sai cũng thật như vậy, nên luận chứng kinh doanh phải trung thực. Nhấc-và-đặt không thiết kế lại thường làm tăng chi phí mà không mang lại lợi ích nào, và chi tiêu không được quản trị có thể phình lên trong im lặng qua hàng chục đội cho đến khi tài chính báo động. Hãy đóng khung lập luận với ban lãnh đạo quanh ba đòn bẩy: tốc độ (phân phối nhanh hơn và cung cấp ngắn hơn), khả năng phục hồi (ít sự cố lớn hơn và ngắn hơn), và tính tùy chọn (vào một thị trường hay vùng mới mà không cần dự án trung tâm dữ liệu). Hãy đặt con số lên đợt làm mới trung tâm dữ liệu được tránh, biên chế giảm cho hạ tầng hàng hóa, và số phút ngừng hoạt động được ngăn chặn, và đặt chúng đối chiếu với chi phí di chuyển và khoản đầu tư FinOps cùng nền tảng liên tục. Lập luận mạnh nhất hiếm khi là tiết kiệm chi phí thuần túy; mà là giá trị tùy chọn của việc di chuyển nhanh hơn các đối thủ vẫn đang chờ phần cứng.

Phản mẫu và cạm bẫy

Nhấc-và-đặt rồi gọi là “đám mây.” Rehost một thiết kế trung tâm dữ liệu lên hạ tầng thuê nắm được chi phí mà không có lợi ích nào.
Hạ tầng bấm chuột. Tài nguyên tạo bằng tay không lặp lại được, không có tài liệu, và không thể khôi phục hay kiểm toán; hãy coi bất kỳ thay đổi sản xuất thủ công nào là khiếm khuyết.
Đa đám mây sùng bái hình thức. Chạy cùng một khối lượng công việc qua hai nhà cung cấp để phòng ngừa một rủi ro hiếm, trả giá bằng độ phức tạp và thiết kế mẫu số chung thấp nhất mỗi ngày.
“Sẵn sàng cao” một vùng sẵn sàng. Tin rằng đám mây phục hồi tốt theo mặc định trong khi chạy các khối lượng công việc quan trọng trong một vùng sẵn sàng không có chuyển đổi dự phòng đã kiểm thử.
Đọc sai trách nhiệm chia sẻ. Giả định nhà cung cấp bảo mật những gì bạn thực sự sở hữu, con đường kinh điển dẫn đến một cái thùng công khai làm rò rỉ hàng triệu bản ghi.
Chi phí như chuyện nghĩ sau. Thiết kế mà không để ý đến chi tiêu, rồi phát hiện hóa đơn đã đưa ra các quyết định kiến trúc của bạn.

Mô hình trưởng thành

Mức 1, Khởi đầu: Việc dùng đám mây là tùy nghi và phản ứng. Các đội bấm chuột để tạo tài nguyên trong các tài khoản dùng chung, khối lượng công việc được nhấc-và-đặt, và không có vùng hạ cánh, không có khả năng nhìn chi phí, và khả năng phục hồi được giả định thay vì thiết kế. Sự cố nghiêm trọng đầu tiên hay cú sốc hóa đơn là một bất ngờ.
Mức 2, Phát triển: Các thực hành cơ bản xuất hiện nhưng khác nhau theo đội. Một số hạ tầng lõi được cung cấp dưới dạng mã và một số khối lượng công việc chạy đa vùng sẵn sàng, một vài tài khoản được tách ra, nhưng độ bao phủ không đồng đều: lựa chọn mô hình dịch vụ và khóa chặt được đưa ra theo thói quen, chi phí được theo dõi sau sự việc, lan can không nhất quán, và khôi phục đa vùng chưa được kiểm thử.
Mức 3, Chuẩn hóa: Một vùng hạ cánh được quản trị với lan can chính sách-dưới-dạng-mã được lập tài liệu và thực thi toàn tổ chức. Một đội nền tảng sở hữu nền móng, mọi thứ sản xuất được cung cấp dưới dạng mã, các đợt rà soát được kiến trúc tốt kiểm soát các thiết kế quan trọng, và các quyết định mua-so-với-xây cùng miền lỗi là có chủ đích và được ghi lại nhất quán ở mọi đội.
Mức 4, Quản lý: Hệ sinh thái được đo và kiểm soát theo các đường cơ sở. Chi phí theo đội và theo dịch vụ được theo dõi qua FinOps theo mục tiêu, mục tiêu thời gian khôi phục và điểm khôi phục được xác minh thay vì khẳng định, vi phạm lan can và trôi cấu hình được phơi bày dưới dạng chỉ số, định cỡ phù hợp được dẫn dắt bởi dữ liệu sử dụng, và mỗi quyết định đi hay không đi được hậu thuẫn bởi bằng chứng từ bảng điều khiển chi phí, độ tin cậy và bảo mật.
Mức 5, Điều phối: Kiến trúc đám mây được cải thiện liên tục và tích hợp với hoạch định kinh doanh và rủi ro. Các miền lỗi được thực hành qua các ngày diễn tập thường lệ, định cỡ phù hợp và định giá được tự động hóa, chủ quyền và nơi lưu trữ được thực thi bằng chính sách, các lập trường về mô hình dịch vụ và khóa chặt được định giá lại theo nhịp đều đặn, và danh mục khối lượng công việc được cân bằng lại thích ứng khi thị trường, giá cả và bức tranh rủi ro dịch chuyển.

Ý tưởng để thảo luận

Mỗi khối lượng công việc chính của bạn nằm ở đâu trên dải từ IaaS đến serverless, và cái nào có thể leo cao hơn để bỏ bớt công việc nặng nhọc vận hành mà không mất kiểm soát bạn thực sự cần?
Nếu nhà cung cấp chính của bạn tăng giá mạnh hoặc chịu một sự cố vùng kéo dài nhiều ngày, kế hoạch thật của bạn là gì, và nó có biện minh cho độ phức tạp đa đám mây hay lai nào bạn đang mang không?
Ai sở hữu vùng hạ cánh và lan can của bạn, và một đội có thể phát hành một tài nguyên không tuân thủ (kho dữ liệu công khai, ổ không mã hóa, vùng không được phép) hôm nay không?
Với một khối lượng công việc chịu quy định hoặc chủ quyền, bạn có thể đưa ra ranh giới trách nhiệm chia sẻ và cấu hình được cấp phép làm bằng chứng mà không cần một cuộc chạy vạy không?

Những điểm cần ghi nhớ

Thiết kế cho đám mây thay vì chụp ảnh trung tâm dữ liệu của bạn; tính co giãn, dịch vụ được quản lý và nhận thức về miền lỗi là lý do để ở đây.
Leo lên dải mô hình dịch vụ về phía được quản lý và serverless cho công việc hàng hóa, và chỉ giữ kiểm soát ở mức thấp hơn nơi nó thực sự xứng đáng với chi phí.
Biến vùng và vùng sẵn sàng thành các miền lỗi tường minh: đa vùng sẵn sàng làm đường cơ sở, đa vùng gắn với các mục tiêu khôi phục đã kiểm thử.
Cung cấp mọi thứ dưới dạng mã trong một vùng hạ cánh được quản trị với lan can chính sách-dưới-dạng-mã, tài khoản riêng, và một đội nền tảng sở hữu nền móng.
Định giá khóa chặt nhà cung cấp một cách trung thực theo cả hai hướng, và hoài nghi về đa đám mây trừ khi một lý do quy định, chủ quyền hoặc tốt-nhất-trong-loại cụ thể đòi hỏi.
Coi chi phí là thuộc tính chất lượng hạng nhất qua FinOps, và chạy các đợt rà soát được kiến trúc tốt để bắt những đánh đổi bạn bỏ sót.

Tài liệu tham khảo và đọc thêm

Peter Mell và Timothy Grance, The NIST Definition of Cloud Computing (NIST Special Publication 800-145)
Amazon Web Services, AWS Well-Architected Framework
Microsoft, Azure Well-Architected Framework và Cloud Adoption Framework
Google Cloud, Google Cloud Architecture Framework
Stephen Orban, Ahead in the Cloud: Best Practices for Navigating the Future of Enterprise IT (và các chiến lược di chuyển “6 R”)
J.R. Storment và Mike Fuller, Cloud FinOps: Collaborative, Real-Time Cloud Financial Management
Gregor Hohpe, Cloud Strategy: A Decision-Based Approach to Successful Cloud Migration
Cơ quan Dịch vụ Tổng hợp Hoa Kỳ, tài liệu chương trình FedRAMP và các đường cơ sở bảo mật
Cloud Security Alliance, Security Guidance for Critical Areas of Focus in Cloud Computing