Tương lai của WebAssembly qua con mắt của một kỹ sư Kubernetes kỳ cựu

Tại chặng Pasadena của Ngày cộng đồng Kubernetes (cùng địa điểm với SCaLE 20x), tôi đã có cơ hội nói chuyện với khoảng 100 người đam mê Kubernetes , để đưa ra quan điểm của tôi về WebAssembly, qua lăng kính của một Kubernetes kỳ cựu.

Tôi nên đủ điều kiện này bằng cách nói rằng tôi có da trong trò chơi cụ thể này. Tôi đã tham gia Kubernetes ngay từ đầu - bắt đầu sớm với Docker (0.6-ish) và làm việc với Kubernetes từ 1.2 - xây dựng các nền tảng Kubernetes trước khi chúng ra đời. Tôi là người duy trì cốt lõi của Helm trong 4 năm và là đồng tác giả của Bindle và Krustlet - một nỗ lực ban đầu để làm cho WebAssugging hoạt động tốt với Kubernetes. Nói một cách dài dòng là tôi hoàn toàn hiểu, tôi hiểu điểm mạnh và điểm yếu của container và Kubernetes.

Tôi cũng đến từ không gian WebAssugging, đã tham gia sâu trong khoảng 3 năm qua. Với cả hai phe, đây là quan điểm của tôi về lợi ích của hai sáng kiến ​​mở này và giao lộ có thể - và nên - trông như thế nào.

Kubernetes và Docker là những yếu tố thay đổi cuộc chơi vì chúng cho phép các kỹ sư và nhà phát triển nền tảng chia nhỏ nguyên khối thành các dịch vụ và ứng dụng siêu nhỏ, có thể quản lý tách biệt với phần còn lại của cơ sở hạ tầng. WebAssugging đi sâu hơn một cấp độ, cho phép chúng tôi tách các ứng dụng riêng lẻ thành các thành phần có thể kết hợp được, có thể hoán đổi nóng, quản lý và định cấu hình riêng biệt với môi trường xung quanh. Về cơ bản, Wasm là mọi thứ chúng tôi muốn trong mã phía máy chủ: bảo mật theo mặc định, di động, đa ngôn ngữ (đặc biệt là trong trình duyệt), nhanh, hiệu quả và có khả năng mở rộng cao.

Vậy Kubernetes và Wasm giao nhau như thế nào? Trước tiên, hãy giải quyết tin đồn trên mạng xã hội và phá vỡ một số huyền thoại.

Chuyện hoang đường số 1: Wasm sẽ giết chết các container.

Không. Chắc chắn không phải. Sẽ không ai viết lại Redis để hoạt động trong trình duyệt khi nó chỉ hoạt động tốt trong vùng chứa. Có rất nhiều trường hợp Kubernetes là giải pháp phù hợp. Có một số ứng dụng doanh nghiệp lớn (Drupal, Redis, nginx) đã tồn tại trong một thời gian dài sẽ không sớm chuyển sang Wasm.

Chuyện hoang đường số 2: Tôi nên tiếp tục và chạy Wasm trong các thùng chứa của mình, phải không?

Chúng tôi không nói rằng bạn không nên, nhưng nó có thể không phải là điểm khởi đầu phù hợp và bạn có thể chỉ cần thêm các lớp phức tạp bổ sung. Bạn có chi phí khởi động bộ chứa Docker (không đa nền tảng), được thêm vào chi phí khởi động WebAssembly. Nó có thể không xứng đáng với chi phí hoạt động, đặc biệt là với tất cả các công cụ có sẵn mà tôi sẽ đề cập sau]

Lầm tưởng #3: Wasm không tương thích với Kubernetes.

Vâng, đúng vậy! Đây là một câu chuyện "Better Together". Mọi thứ đều tiến hóa với máy tính. Chỉ vì chúng tôi nghĩ ra máy ảo không có nghĩa là chúng tôi không có nhu cầu về phần cứng vật lý. Và chỉ vì Wasm xuất hiện không có nghĩa là chúng ta không cần thùng chứa. Để thấy điều này hoạt động, hãy đọc cách những người bạn của chúng tôi tại Adobe đang chuyển đổi kiến ​​trúc Kubernetes của họ bằng Wasm .

Giống như những ngày đầu của Kubernetes, chúng ta đang ở giai đoạn mà mọi thứ đang đột phá và phát triển rất nhanh. Kết nối mạng vẫn còn khó khăn ở phía máy chủ ở cấp độ Wasm thô. Chúng tôi sẽ sớm nhận được hỗ trợ ổ cắm và mọi thứ đang tiến triển nhanh chóng. Chuỗi công cụ ngôn ngữ và mã trình diễn cấp thấp cũng rất quan trọng nhưng vẫn chưa có. Đó là một khoảnh khắc thú vị, mặc dù. Các tiêu chuẩn WASI (không phải trình duyệt Wasm) đã đi một chặng đường dài, ngay cả trong vài tuần qua - sẽ nói thêm về điều đó sau.

Tại sao lại là Wasm ?

Sự thật là Kubernetes có những giới hạn của nó, đặc biệt là ở phần biên . Mặc dù đã đạt được rất nhiều tiến bộ (rất hoan nghênh các dự án như K3), nhưng mọi thứ chỉ có thể đi xa hơn. Kubernetes có nghĩa là được chạy trong các cụm thường là một phần của cùng một khu vực địa lý. Khi thứ gì đó đang chạy trong tháp di động, nhà máy điện hoặc cửa hàng truyền thống, Kubernetes không mở rộng quy mô tốt. Chúng tôi đã thấy điều này khi chúng tôi nói chuyện với các thành viên trong cộng đồng của mình. Wasm thực sự là kiến ​​trúc đa nền tảng và chạy rất nhỏ, khiến nó trở thành ứng cử viên sáng giá hơn cho lợi thế cạnh tranh.

Chi phí và việc sử dụng cũng là những yếu tố chính . Chúng tôi đã nói chuyện với một số công ty trong danh sách Fortune 100 và mức sử dụng máy chủ Kubernetes của họ chiếm khoảng 25-35% tổng công suất, với một số công ty lên tới 50-60%. Nhiều người đã từ bỏ các nhóm Kubernetes nội bộ của họ vì nó quá đắt. Wasm cho phép chúng tôi đóng gói nhiều thứ hơn vào một không gian nhỏ hơn và tận dụng nó tốt hơn.

Bảo mật cũng là một lợi ích chính của Wasm. Các vùng chứa khá an toàn nhưng có rất nhiều sắc thái tạo ra sự phức tạp, đặc biệt đối với các nhà phát triển. Theo mặc định, một mô-đun WebAssugging không thể làm gì trừ khi bạn cấp cho nó đặc quyền để làm như vậy.

Chúng ta có thể làm gì với Kubernetes và Wasm ngay bây giờ ?

Tuy nhiên, với tất cả những gì đã nói, thực sự có thể làm gì với Wasm và Kubernetes ngay bây giờ? Hãy xem xét ba trong số các kịch bản lớn nhất mà bạn có thể tận dụng Wasm ngay lập tức.

runwasi trong hộp chứa CNCF

Một cách thực sự thú vị để sử dụng Wasm là kiểm tra dự án runwasi tuyệt vời, là một phần của hệ sinh thái có chứa của CNCF. Về cơ bản, runwasi cho phép bạn chạy thời gian chạy WebAssugging thông qua bộ đệm shim được chứa bên trong Kubernetes. Đây là một tùy chọn tốt hơn nhiều so với việc cố gắng chạy Wasm bên trong một vùng chứa vì nó chạy trực tiếp WebAssugging, giống như khi bạn xoay một vùng chứa trong một nhóm.

Lưới dịch vụ, có ai không ?

Envoy và các mắt lưới khác đã có khả năng viết plugin bằng WebAssembly. Với những thứ này, bạn có thể viết bộ lọc tùy chỉnh và các mô hình plugin khác bằng bất kỳ ngôn ngữ nào biên dịch thành WebAssugging.

wasmCloud

Chúng tôi biết rằng các công ty đã nhận thấy giá trị của việc kết hợp Kubernetes với Wasm trong nhiều trường hợp sử dụng khác nhau. Nhưng wasmCloud đưa nó lên một tầm cao mới nhờ khả năng kết nối các máy tính khác nhau trong cấu trúc liên kết mạng phẳng. Bản trình diễn thứ hai của tôi cho thấy việc di chuyển cùng một đoạn mã qua ba nút khác nhau, mỗi nút ở một vị trí khác nhau, dễ dàng như thế nào. Trong trường hợp này, máy Mac của tôi ở Pasadena, cụm Digital Ocean K8s ở New York và wasmCloud. Không tái cấu trúc, cùng mã, bất kỳ vị trí nào. Tiếp theo, nền tảng Cosmonic (được xây dựng trên wasmCloud) sẽ mang đến cách tiếp cận đầy đủ dịch vụ cho Wasm mà các công ty sẽ cần khi họ chuyển sang sản xuất.

Bạn muốn dùng thử wasmCloud trên nền tảng được quản lý?

Bắt đầu với Cosmonic miễn phí ngay hôm nay. Ra mắt ngay!

Mô hình thành phần

Cuối cùng, và thú vị nhất, mọi thứ đang diễn ra nhanh chóng trong không gian này. Hãy xem bài nói chuyện về WASM I/O của Bailey Hayes và Dan Chiarlone cho thấy chúng ta đã đi được bao xa trong việc xác định các tiêu chuẩn WASI và Mô hình Thành phần - đó là cái nhìn đầu tiên về những gì chúng ta thực sự muốn trong tương lai. Bạn có thể theo dõi tiến độ tại đây và tham gia Liên minh Bytecode để nghe thông tin mới nhất khi nó diễn ra.

- Bởi Taylor Thomas , Trưởng nhóm kỹ thuật tại Cosmonic

Nếu bạn muốn tìm hiểu thêm, có câu hỏi hoặc muốn trò chuyện, hãy kết nối với chúng tôi trên Discord hoặc Slack .