Bạn có thể bỏ qua khả năng phục hồi khi xây dựng ứng dụng gốc trên đám mây không?

Samar Abbas của Temporal tin rằng các nhà phát triển thậm chí không cần phải nghĩ đến việc mất trạng thái. Chỉ có những lần thực hiện bền bỉ không bao giờ thất bại.

Nếu bạn đã sử dụng các công cụ xử lý văn bản trong một thời gian dài, bạn sẽ nhớ hành động theo phản xạ là nhấn phím tắt “save” — nỗi sợ mất công việc của mình, lớn tiếng chửi bới và than vãn về công việc tuyệt vời mà bạn vừa đánh mất.

Với các công cụ hiện đại (nghĩ rằng Google Docs), nỗi lo này thậm chí không xuất hiện. Đang nói dở thì mất điện? Không có gì. Mọi thứ được lưu ở trạng thái bạn để lại và bạn có thể tiếp tục.

Samar Abbas và nhóm của anh ấy tại công cụ điều phối quy trình công việc Temporal muốn đưa khái niệm này vào quy trình làm việc của doanh nghiệp bạn. Bạn cung cấp logic nghiệp vụ và họ xử lý tất cả các phần đòi hỏi chuyên môn chuyên sâu như tính kiên trì và khả năng phục hồi.

Temporal được thành lập vào năm 2019 bởi Abbas và đồng nghiệp Maxim Fateev khi họ còn ở Uber. Họ đã tạo ra một nền tảng phát triển cho công ty ứng dụng gọi xe có tên là “Cadence”. Đó là sự phát triển của nền tảng AWS Simple Workflow Service mà bộ đôi này đã giúp phát triển khi họ còn là đồng nghiệp tại Amazon vào giữa những năm 2000. Hàng chục dịch vụ và ứng dụng của Uber đã áp dụng Cadence .

Abbas và Fateev rời đi để đồng sáng lập Temporal và xây dựng dự án kế thừa công cụ quy trình công việc có khả năng chịu lỗi cho Cadence. Trong ba năm kể từ đó, công ty đã đạt được thành công vững chắc, với các công ty như Netflix, Instacart và những công ty khác sử dụng mã phần mềm nguồn mở của Temporal. Đầu năm nay, công ty đã bảo đảm vòng Series B trị giá 103 triệu đô la, đưa mức định giá của nó lên 1,5 tỷ đô la.

Gần đây tôi đã trò chuyện với Abbas (bạn có thể xem toàn bộ nội dung ) về cách anh ấy và Fateev xây dựng liên doanh cực kỳ thành công của họ. (Những lời của anh ấy dưới đây được chỉnh sửa cho rõ ràng và dài hơn).

Từ Uber đến tạm thời

Năm 2015, Uber mở văn phòng tại Seattle và tôi tham gia nhóm kỹ thuật của họ. Tôi và Max [Người đồng sáng lập tạm thời Maxim Fateev] đã đến Uber trong vòng một tháng. Dự án quan trọng mà chúng tôi đã làm việc cùng nhau là Cadence.

Tại Uber, các kỹ sư đã dành nhiều thời gian để kết hợp các hàng đợi cấp thấp, cơ sở dữ liệu và bộ hẹn giờ lâu bền để xây dựng khả năng phục hồi cho các ứng dụng của họ.

Đây là những gì chúng tôi đang cố gắng giải quyết với một hệ thống như Cadence, nơi chúng tôi cung cấp khả năng trừu tượng hóa cấp cao vẫn dựa trên mã, nhưng chúng tôi đã loại bỏ một số loại lỗi nhất định khỏi bảng của kỹ sư và giải quyết chúng bên dưới nền tảng để cho phép các kỹ sư để tập trung vào logic nghiệp vụ cho ứng dụng, thay vì xây dựng khả năng phục hồi.

Điều đó đã thành công với Uber và vì nó là mã nguồn mở nên chúng tôi bắt đầu thấy rất nhiều ứng dụng bên ngoài áp dụng công nghệ này. Vì vậy, vào năm 2019, cả tôi và Max đã quyết định thực hiện một bước nhảy vọt và bắt đầu Temporal, vì chúng tôi thực sự muốn tập trung vào việc áp dụng công nghệ ra bên ngoài.

Trải nghiệm nhà phát triển tạm thời

Đôi khi mọi người mô tả Temporal như một công cụ quy trình công việc hoặc mô tả các tính năng của nó, nhưng đề xuất giá trị chính đối với chúng tôi là năng suất của nhà phát triển: tốc độ mà các nhà phát triển có thể xây dựng ứng dụng và chạy chúng trong sản xuất mà không mất hàng tuần hoặc hàng tháng để thử nghiệm tất cả các loại tình huống lỗi có thể xảy ra. xảy ra trong môi trường dựa trên đám mây.

Vì vậy, cách chúng tôi nghĩ về trải nghiệm của nhà phát triển không chỉ là khía cạnh cốt lõi của những gì công nghệ cung cấp; chúng tôi đề cập đến toàn bộ vòng đời phát triển phần mềm ngay từ đầu, cách các nhà phát triển xây dựng ứng dụng của họ. Chẳng hạn, rất nhiều công cụ quy trình làm việc thường đi theo lộ trình ngôn ngữ dành riêng cho miền (DSL). Tất cả chúng ta đều dựa trên mã. Chúng tôi biết các nhà phát triển thích viết mã và chúng tôi muốn họ viết mã, nhưng chỉ loại bỏ một số mối quan tâm nhất định, chẳng hạn như cách làm cho mã đó có khả năng phục hồi nếu một số cơ sở hạ tầng cơ bản gặp sự cố hoặc cách làm cho mã có khả năng phục hồi khi xảy ra lỗi mạng .

Thời gian tạo nên sự khác biệt khi nào và như thế nào?

Chuyển tiền là một trong những trường hợp sử dụng chính mà Tạm thời được sử dụng khá thường xuyên. Nếu bạn đang chuyển tiền từ tài khoản này sang tài khoản khác, thường là từ góc độ người dùng, vâng, tôi ghi nợ từ tài khoản A và sau đó ghi có vào tài khoản B. Nhưng phần lớn thời gian phát triển phần mềm được dành cho các lỗi hệ thống giữa hai cuộc gọi đó. Và về cơ bản, đây là nơi các kỹ sư dành đủ loại thời gian.

Đây là một ví dụ về thời điểm một hệ thống như Temporal có thể giúp ích rất nhiều - nó thậm chí còn mang lại cảm giác kỳ diệu. Chúng tôi nghe câu hỏi này rất nhiều: Điều gì xảy ra nếu ứng dụng của tôi không thành công vào thời điểm này?

Câu trả lời của chúng tôi cho câu hỏi đó là: Quy trình làm việc không bao giờ lỗi (Tại thời điểm tạm thời, chúng tôi gọi nguyên tắc mà chúng tôi đang xây dựng là “quy trình làm việc”.) Sau đó, đó là một trong những khoảnh khắc khi công tắc đèn bật sáng. Chúng tôi bắt đầu gọi đây là "thực thi lâu bền", ở cấp độ cao, những gì chúng tôi cung cấp là: Quá trình thực thi của bạn hoàn toàn bền. Họ không bao giờ thất bại.

Tác động kinh doanh của quy trình làm việc có trạng thái 'Không biết lỗi'

Quay trở lại những năm 90 khi tôi còn đi học, chúng tôi thường nhập tất cả các bài tập của mình trong Microsoft Word. Bạn có thói quen lưu tài liệu của mình mỗi khi bạn viết một vài chỉnh sửa. Tuy nhiên, có một số loại lỗi nhất định, chẳng hạn như đĩa cứng bị hỏng, khiến bạn mất tất cả công việc.

Giờ đây, với Google Docs, trẻ em thậm chí không thể hiểu được điều này. Thậm chí không có nút “lưu” nữa. Chúng tôi tin rằng có một lớp ứng dụng có trạng thái vẫn còn tồn tại trong thời đại những năm 1990 này, trong đó hơn 80% mã là về xử lý sự cố cơ sở hạ tầng để xây dựng khả năng phục hồi cho các ứng dụng có trạng thái. Mỗi khi một sự kiện xảy ra, bạn tải trạng thái đó, áp dụng sự kiện đó, thực hiện một loạt hành động và sau đó lưu trạng thái đó trở lại. Đây là nơi mà phần lớn kỹ thuật hướng tới: làm thế nào để làm cho nó đáng tin cậy, nhanh chóng và hiệu quả, đồng thời bảo vệ nó khỏi mọi loại lỗi và hư hỏng.

Các nhà phát triển thậm chí không cần phải nghĩ rằng họ có thể mất trạng thái của mình. Chỉ có những lần thực hiện bền bỉ không bao giờ thất bại. Và tôi nghĩ nó sẽ thay đổi hoàn toàn cách các kỹ sư nghĩ về các hệ thống dựa trên đám mây.

Tại sao Apache Cassandra được quản lý?

Tôi và người đồng sáng lập Max của tôi có nền tảng kiến thức về xây dựng hệ thống nhắn tin và phần mềm trung gian. Chạy hệ thống lưu trữ không phải là thế mạnh của chúng tôi. Vì vậy, khi chúng tôi thành lập công ty chỉ với hai người, mục tiêu chính của chúng tôi là tận dụng thế mạnh của mình để cung cấp trải nghiệm nhà phát triển tốt nhất cho người dùng Tạm thời. Temporal có một thành phần máy chủ và SDK máy khách mà hầu hết các nhà phát triển hiện có sử dụng để xây dựng ứng dụng. Nhưng làm thế nào mọi người có thể chạy các máy chủ đó với chi phí hoạt động tối thiểu? Đây là nơi chiếm phần lớn chi phí cho việc chạy Temporal.

Chúng tôi có một mô hình kiên trì có thể cắm được; chúng tôi hỗ trợ Apache Cassandra , MySQL và Postgres dưới dạng bộ điều hợp có thể cắm được. Cassandra là một trong những bộ điều hợp có đặc điểm khả năng mở rộng rất tốt. Một đề xuất giá trị quan trọng cho người dùng của chúng tôi là họ đang chạy các ứng dụng quan trọng và độ tin cậy là điều quan trọng mà họ đang tìm kiếm. Vì vậy, chúng tôi không xem nhẹ khi đưa một sự phụ thuộc mới vào Thời gian tạm thời. Chúng tôi đã chạy hơn một tháng để đánh giá tất cả các loại tùy chọn bền bỉ. Đó là DataStax Astra DB .

Một số cơ sở dữ liệu giành được một số tính năng, những cơ sở dữ liệu khác giành được các tính năng khác. Nhưng nó thậm chí không phải là về công nghệ trong trường hợp này; đó là về người dân. Chúng tôi tin rằng lỗi và thất bại là một phần của cuộc sống. Đó là tất cả về cách bạn phản ứng khi mất điện. Và đây là nơi chúng tôi tin rằng Astra DB sẽ thắng. Có rất nhiều điểm tương đồng với cách DataStax đối xử với khách hàng của mình và các loại mối quan hệ mà họ xây dựng khi vận hành cơ sở dữ liệu của mình. Và điều đó đã cho chúng tôi niềm tin rằng đây là một phần phụ thuộc mà chúng tôi muốn đầu tư vào một phần cốt lõi của hệ thống.

Tôi không nghĩ chúng ta sẽ ở vị trí như ngày nay nếu không có công nghệ như Astra để chúng ta tận dụng và xây dựng trên đó. Những việc như chỉ vận hành Cassandra và hoàn thành công việc một mình sẽ là một dự án kéo dài ít nhất một năm và đó thậm chí không phải là một phần sức mạnh cốt lõi của chúng tôi. Đối với một công ty như chúng tôi, nơi đề xuất giá trị chính là độ tin cậy, nếu chúng tôi không thể tìm ra cách vận hành và vận hành kho lưu trữ của bạn theo cách đáng tin cậy, thì chúng tôi không kinh doanh được.

Đăng ký ngay cho Cassandra Forward, một sự kiện ảo miễn phí kéo dài hai giờ diễn ra vào ngày 14 tháng 3 đi sâu vào mọi thứ về Apache Cassandra.

Bởi Patrick McFadin, DataStax

Patrick McFadin là đồng tác giả của cuốn sách O'Reilly 'Quản lý dữ liệu gốc trên đám mây trên Kubernetes'. Anh ấy hiện đang làm việc tại DataStax trong lĩnh vực quan hệ với nhà phát triển và là người đóng góp cho dự án Apache Cassandra. Patrick đã làm việc với tư cách là người truyền bá chính cho Apache Cassandra (anh ấy cũng là một người đi làm Cassandra mới được đúc kết!) và là cố vấn cho DataStax, nơi anh ấy đã có thời gian tuyệt vời để xây dựng một số triển khai lớn nhất trong sản xuất.