Ai cũng bảo hãy chuyển sang serverless. Chúng tôi vẫn giữ cụm Kubernetes phần lớn thời gian ngồi không

Lời khuyên đó ở khắp nơi và nghe có vẻ đúng hiển nhiên. Bạn chạy xác thực cho các tenant có lưu lượng lên xuống thất thường. Bạn trả tiền cho một cụm Kubernetes suốt ngày đêm. Azure Container Apps sẽ scale bạn về không và chỉ tính tiền những gì bạn dùng. Thôi trả tiền cho lúc ngồi không.

Chúng tôi đã xem xét nghiêm túc. Chúng tôi tính chi phí di trú sang Azure Container Apps, soi kỹ nó mang lại được gì cho mình, rồi vẫn ở lại AKS. Đây là lập luận, vì nó không phải lập luận bạn đoán ra từ biểu đồ mức sử dụng của cụm.

Lời khuyên đúng, nhưng cho một loại tải công việc mà chúng tôi không có

Container serverless rất hợp với việc xử lý yêu cầu phi trạng thái, dồn dập: mỗi yêu cầu độc lập, các instance là "gia súc", và không lưu lượng thì lẽ ra phải là không hóa đơn. Điều đó mô tả rất nhiều backend web.

Nó không mô tả một backplane xác thực. Cái của chúng tôi không ngồi không theo cách một ứng dụng phi trạng thái ngồi không. Nó nắm quyền lãnh đạo cụm và chạy lớp điều phối quyết định replica nào thực hiện công việc singleton, như quét retention và lượt chạy webhook. (Giờ chúng tôi bầu leader đó bằng một lease blob, không còn dùng gossip nữa, mà đó là một câu chuyện riêng.) Cụm yên tĩnh không có nghĩa là nó chẳng có gì để làm; nó có nghĩa là nó đang sẵn sàng xác thực token kế tiếp và tiếp tục làm leader. Yên tĩnh và ngồi không không phải cùng một trạng thái.

Chúng tôi xóa hóa đơn ngồi không mà không cần dời đi

Đây là phần quyết định: chi phí mà chúng tôi cố thoát khỏi có một cách khắc phục rẻ hơn nhiều so với đổi nền tảng.

Thứ ngốn tiền là các node chạy 24/7 trong khi lưu lượng dồn vào giờ làm việc. Vậy nên chúng tôi làm cho cụm dev tự giải phóng tài nguyên (deallocate) khi không ai dùng (tắt qua đêm và cuối tuần, bật lại theo yêu cầu) và chuyển node pool sang một SKU rẻ hơn. Việc đó cắt bỏ phần lớn khoản chi ngồi không mà serverless hứa sẽ loại bỏ, và nó chỉ tốn một thay đổi cấu hình chứ không phải một cuộc di trú. Khi khoản tiết kiệm bạn muốn có thể đạt được ngay tại chỗ, thì đổi nền tảng để đuổi theo cùng con số đó là rất nhiều rủi ro đổi lấy một khoản chênh lệch bạn đã nắm được rồi.

Bài học có thể khái quát hóa: hãy định giá cách khắc phục trước khi định giá đổi nền tảng. "Thôi trả tiền cho lúc ngồi không" là một mục tiêu, không phải một kiến trúc, và cách rẻ nhất để đạt được nó thường là một scheduler và một SKU, chứ không phải một runtime mới.

Scale-to-zero chống lại một backplane phải giữ một lease

Ngay cả khi gạt chi phí sang một bên, scale-to-zero vẫn hoàn toàn sai cho loại tải công việc này theo hai cách.

Thứ nhất, cold start rơi vào đúng con đường tệ nhất có thể. Yêu cầu phải trả "thuế" cold start là của một người đang cố đăng nhập, và "đăng nhập của bạn chậm vì dịch vụ xác thực của chúng tôi đang ngủ" không phải là câu bạn muốn đưa ra.

Thứ hai, quyền lãnh đạo và scale-to-zero xung đột trực tiếp. Bạn không thể giữ một lease từ một instance đã bị scale đi mất. Một backplane mà toàn bộ nhiệm vụ là luôn có đúng một leader sống không hề muốn một runtime mà toàn bộ nhiệm vụ là loại bỏ instance khi chúng trông có vẻ rảnh. Chúng tôi sẽ phải chống lại hành vi cốt lõi của nền tảng để bảo toàn hành vi của mình.

Runtime đó sẽ lấy mất ba thứ chúng tôi đang dùng

Di trú không miễn phí ngay cả ở nơi nó chạy được; bạn thừa hưởng sandbox của runtime được quản lý, và cái của chúng tôi chặn những thứ mà chúng tôi phụ thuộc vào:

• Twingate. Chúng tôi tiếp cận các tài nguyên riêng tư qua một connector Twingate. Sandbox container được quản lý sẽ không chạy nó, nên chúng tôi sẽ phải phát minh lại quyền truy cập mạng riêng mà mình đã có.
• Đường build của chúng tôi. Một phần pipeline của chúng tôi dựa vào Docker-in-Docker và az acr build đối với một registry riêng, cả hai đều bị sandbox cấm. Đó là cả một hệ thống build phải dựng lại, không chỉ là một đích deploy phải đổi.
• Kiểm soát cross-cloud. Chúng tôi chạy một bản dự phòng (standby) trên AWS để xác thực các token do bản chính trên Azure phát ra, qua JWKS liên kết, với Cloudflare làm trọng tài failover. Việc đó cần quyền kiểm soát mạng và placement mà một runtime được quản lý cố tình giấu đi.

Mỗi thứ trong số này là một cách lách mà chúng tôi sẽ phải viết chỉ để quay về đúng nơi mình đang đứng. Chi phí thực sự của cuộc di trú không phải là việc chuyển đổi; mà là kiếm lại từng năng lực mà sandbox lấy mất.

Tiết kiệm chi phí có cái đuôi của nó, và chúng tôi đã trả nó

Ở lại cũng không phải là không có hệ quả, và nói thật mới là công bằng. Việc giải phóng node vào ban đêm gây ra một sự cố mà chúng tôi sẽ không bao giờ gặp trên một cụm luôn bật: một cuộc đua giành token ở lần pull image đầu tiên trên các node lạnh (chính là issue 4052 của AKS) thỉnh thoảng làm kẹt một pod đang khởi động sau khi cụm bật lại. Chúng tôi sửa nó bằng cách kéo dài timeout của rollout, và ở môi trường production, bằng cách không giải phóng node theo kiểu mà dev làm.

Đó mới là hình dạng thật của sự đánh đổi. Mọi con đường đều có cái đuôi gồm các kiểu hỏng hóc; câu hỏi là bạn có thấy và sửa được chúng hay không. Trên AKS, cuộc đua node lạnh có thể quan sát được và sửa được. Những kiểu kỳ quái mà bạn thừa hưởng từ ruột gan của một runtime được quản lý là loại mà bạn mở một ticket hỗ trợ rồi ngồi chờ.

Quy tắc chúng tôi rút ra

Hai điều, dùng lại được vượt ngoài chúng tôi. Đừng di trú để thoát khỏi một chi phí mà bạn có thể diệt ngay tại chỗ; hãy định giá cách khắc phục tại chỗ trước, vì một scheduler và một SKU rẻ hơn thắng một cuộc đổi nền tảng trong phần lớn trường hợp. Và hãy khớp runtime với hình dạng của tải công việc: serverless thưởng cho phi trạng thái và dồn dập còn phạt có trạng thái và luôn bật, và một lõi xác thực giữ khóa ký của bạn và quyền lãnh đạo cụm của bạn dứt khoát thuộc loại thứ hai.

Chúng tôi không phản đối serverless. Khá nhiều phần bề mặt phi trạng thái của chúng tôi sẽ ổn trên đó. Nhưng phần giữ khóa của bạn và quyết định ai chạy các job có sức tàn phá sẽ tiếp tục chạy trên hạ tầng nhàm chán, luôn bật, có thể quan sát được. Đôi khi cái cụm trông như ngồi không lại là lựa chọn rẻ, một khi bạn đếm hết mọi thứ bạn sẽ phải dựng lại để rời bỏ nó.

Hạ tầng luôn bật, có thể quan sát được nằm dưới các phiên đăng nhập của bạn là một tính năng, không phải một sơ suất. Đó chính xác là những gì bạn giao lại khi bạn chạy xác thực trên Authagonal thay vì tự vận hành backplane.