Vào tháng 9 năm ngoái, một bản cập nhật lớn của Proton Mail dành cho iOS và Android đã được ra mắt.
Nhìn bề ngoài, các ứng dụng mới mang lại thiết kế hiện đại, hiệu suất tốt hơn và các khả năng ngoại tuyến—nhưng còn nhiều điều hơn thế nữa. Đằng sau hậu trường, các ứng dụng này là sự viết lại hoàn toàn của Proton Mail trên một ngăn xếp công nghệ mới lạ, một dự án có tên nội bộ là Engineering Transformation. Thuật ngữ mới lạ được sử dụng một cách có chủ ý, bởi vì — theo hiểu biết tốt nhất — đây là lần đầu tiên công nghệ được chọn được sử dụng trong bối cảnh của một ứng dụng sản xuất đã định hình.
Bài viết này nhằm mục đích làm sáng tỏ hành trình thú vị mà đội ngũ đã trải qua trong việc tạo nên cuộc cách mạng này, đồng thời trả lời một số câu hỏi mà cộng đồng đã đặt ra trong suốt quá trình. Trước hết, lý do đằng sau là nhu cầu thay đổi hiện trạng.
Mọi chuyện đã bắt đầu như thế nào
Nhận thức về việc mọi thứ cần phải thay đổi đã xuất hiện vào một buổi tối thứ Sáu tháng 10 năm 2023. Nó hiện ra với sự rõ ràng đáng ngạc nhiên, nhưng không phải ngẫu nhiên: đó là kết quả của nhiều tháng cố gắng tìm kiếm mẫu số chung cho các vấn đề dường như không liên quan ảnh hưởng đến trải nghiệm của người dùng với các sản phẩm di động Mail và Lịch.
Nếu không muốn nói quá đơn giản, có thể tóm tắt các điểm nghẽn trong ba lĩnh vực:
Chất lượng: Khi xét riêng lẻ, Mail iOS và Mail Android chưa đạt kỳ vọng về chất lượng và hiệu suất.
Khoảng cách tính năng giữa iOS và Android: Một số tính năng chỉ có sẵn trên một nền tảng, mà không có thông tin rõ ràng về thời điểm nền tảng còn lại sẽ bắt kịp.
Tốc độ phát triển kỹ thuật: Các bản cập nhật quan trọng và tính năng được mong đợi từ lâu đã không được phát hành kịp thời trên cả hai nền tảng.
Một số sự cố còn vượt ra ngoài phạm vi di động, và việc giải quyết chúng đòi hỏi phải chuyển từ miền công nghệ sang không gian vấn đề hấp dẫn của việc mở rộng quy mô tổ chức, đặc biệt là các doanh nghiệp khởi động công nghệ phát triển nhanh. Nhưng tính mỏng manh của hệ sinh thái di động phần lớn bắt nguồn từ công nghệ và kiến trúc.
Mở rộng quy mô kỹ thuật di động
Việc mở rộng quy mô kỹ thuật di động đi kèm với một loạt thách thức độc đáo, khác biệt đáng kể so với việc mở rộng quy mô các đội ngũ web và phụ trợ. Những khác biệt này bắt nguồn từ sự phân mảnh nền tảng và thực tế vận hành của hệ sinh thái di động. Các đội ngũ di động thường cần hỗ trợ nhiều nền tảng trên nhiều hệ điều hành và thiết bị khác nhau (điện thoại, máy tính bảng, đôi khi là thiết bị đeo). iOS và Android đi kèm với các ngôn ngữ lập trình, khung công tác và công cụ riêng, dẫn đến một lượng lớn nỗ lực bị trùng lặp: nhiều đội ngũ, các cơ sở mã bị trùng lặp và các đánh đổi liên tục giữa công việc dành riêng cho nền tảng và công việc liên quan đến sản phẩm. Việc duy trì đồng bộ các dịch vụ sản phẩm đòi hỏi một lượng lớn sự phối hợp.
Thách thức chung của toàn ngành này đặc biệt nghiêm trọng đối với Proton. Các ứng dụng chức năng như Mail và Lịch vốn phức tạp hơn hầu hết các ứng dụng di động trên thị trường. Khi thêm lớp logic máy khách bổ sung cần thiết để xử lý mã hóa đầu cuối, sẽ dẫn đến các máy khách đặc biệt “dày”. Trước đây, đội ngũ Android đã bận rộn viết lại Mail để đạt tiêu chuẩn chất lượng tốt hơn—một khoản đầu tư mất phần lớn thời gian trong 18 tháng. iOS cũng rất cần cấu trúc lại kiến trúc, chưa kể đến Lịch. Chi phí trùng lặp đã ngốn sạch tài nguyên kỹ thuật, và rõ ràng là sẽ không thể thành công nếu tiếp tục làm theo cách cũ.
Điều tuyệt vời nhất khi nhận ra mình đang bị mắc kẹt là nó hoạt động như một yếu tố thúc đẩy để suy nghĩ vượt ra khỏi những ràng buộc của hiện trạng hiện tại. Sẽ làm gì nếu có thể bắt đầu lại từ đầu, thoát khỏi gánh nặng của những lựa chọn và cam kết đã dẫn đến đây? Khi nhìn kỹ hơn vào cách các công ty thành công giải quyết sự cố này trong thập kỷ trước, có thể thấy họ đã tuân theo một trong hai chiến lược khả thi duy nhất:
- Họ đã vung tiền để giải quyết vấn đề, xây dựng các đội ngũ ngày càng lớn hơn khi chi phí vận hành cao được bù đắp bằng sự kết hợp giữa các khoản đầu tư không đáy và/hoặc lợi nhuận khổng lồ. Đây không phải là một lựa chọn cho mô hình kinh doanh không có vốn đầu tư mạo hiểm của Proton: không thể cạnh tranh với mức chi tiêu của các đối thủ cạnh tranh hoạt động dựa trên quảng cáo và được các nhà đầu tư hậu thuẫn.
- Họ đã thiết kế lại các ứng dụng để loại bỏ sự lãng phí, nghĩa là xây dựng các ứng dụng sử dụng (nhiều nhất có thể) một cơ sở mã chia sẻ.
Với việc lựa chọn 1 không khả thi, đường dẫn phía trước đã được xác định.
Phương tiện để đạt mục đích: chọn ngăn xếp công nghệ phù hợp
Bước tiếp theo là chọn một ngăn xếp công nghệ thực sự có thể hoàn thành công việc.
Trong 15 năm qua, việc phát triển di động đa nền tảng đã tràn ngập các giải pháp “phù hợp cho tất cả”: HTML5, Xamarin, React Native, Flutter, Kotlin Multiplatform và nhiều giải pháp khác. Mỗi giải pháp đều đi kèm với cùng một lời hứa—thay thế hoàn toàn việc phát triển gốc. Trên thực tế, hầu hết đều thất bại hoàn toàn hoặc chỉ thành công trong các không gian vấn đề bị ràng buộc chặt chẽ. Không có sự trừu tượng hóa phổ quát nào làm biến mất sự khác biệt giữa các nền tảng: bất kỳ ai từng phân phối và bảo trì các ứng dụng di động lớn đều biết điều này. Cách đáng tin cậy duy nhất là đi ngược lại từ các yêu cầu cụ thể thay vì đi tiếp từ các xu hướng công cụ.
Mục tiêu cuối cùng đó đã được chuyển dịch thành một tập hợp các yêu cầu không thể thương lượng (1) mà bất kỳ giải pháp nào được chọn cũng phải đáp ứng, và sử dụng chúng làm khung hướng dẫn trong suốt quá trình đánh giá:
- Chi phí và mốc thời gian: Ngăn xếp phải giảm đáng kể chi phí và thời gian cần thiết để phân phối, bảo trì và phát triển Proton Mail trên iOS và Android.
- Trải nghiệm người dùng: Phải duy trì hiệu suất gần như gốc và chất lượng tương tác—bất kỳ điều gì kém hơn đều không khả thi.
- Đảm bảo tính chiến lược trong tương lai: Giải pháp phải có tuổi thọ lâu dài. Việc tránh các khung công tác của bên thứ ba để lộ trình không bị phụ thuộc vào sự hỗ trợ liên tục của một nhà cung cấp khác là có chủ ý.
Sự căng thẳng giữa hai ràng buộc đầu tiên là phiên bản của chén thánh trong ngành: “Một giải pháp đa nền tảng mang lại hiệu suất và trải nghiệm người dùng của các ứng dụng gốc.”
Ngay từ đầu đã có sự hoài nghi rằng React Native hoặc Flutter—hai khung công tác đa nền tảng thống trị vào thời điểm đó—có thể đáp ứng được tiêu chuẩn này. Tuy nhiên, sự hoài nghi đó đã được xác thực bằng cách xây dựng các bản triển khai thử nghiệm khái niệm cho chế độ xem danh sách thư của Mail.
React Native nhanh chóng bộc lộ những hạn chế. Việc cuộn qua một tập dữ liệu lớn đã làm lộ rõ chi phí của mô hình thực thi thông dịch. Flutter hoạt động tốt hơn, nhưng giao diện người dùng vẫn hiển thị rõ là phi bản địa, đặc biệt là trên iOS. Quan trọng hơn, Flutter là một khung phát triển độc quyền do Google kiểm soát, vốn có lịch sử(cửa sổ mới) từ bỏ các công nghệ nội bộ và gần đây đã sa thải một phần lớn đội ngũ Flutter. Đối với một sản phẩm có cam kết bảo mật và độ tin cậy lâu dài, mức độ phụ thuộc vào bên ngoài như vậy là không thể chấp nhận được.
Kotlin Multiplatform là ứng cử viên tiếp theo. Đây là một lựa chọn hấp dẫn—đặc biệt đối với các tổ chức có chuyên môn sâu về Android—nhưng cuối cùng nó vẫn không đáp ứng được trường hợp sử dụng của chúng tôi. Việc thiếu lớp giao diện người dùng chia sẻ, các câu hỏi xung quanh mức độ hoàn thiện và chi phí chung bổ sung do mô hình thực thi của nó gây ra đã vượt trội hơn những lợi ích mang lại.
Tại thời điểm này, kết luận đã rõ ràng và phù hợp với trực giác ban đầu: kiến trúc duy nhất liên tục tiếp cận kết quả mong muốn là một ngăn xếp được kết hợp một cách có chủ ý. Giao diện người dùng gốc trên mỗi nền tảng – Jetpack Compose trên Android, SwiftUI on iOS – được hỗ trợ bởi một lớp logic nghiệp vụ chia sẻ được viết bằng ngôn ngữ cấp thấp, hiệu suất cao. Cách tiếp cận này đã có lịch sử chứng minh: Dropbox nổi tiếng với việc sử dụng C++ để chia sẻ logic nghiệp vụ trên các nền tảng di động trước khi từ bỏ vào năm 2019 do chi phí vận hành và nhận thức của ngôn ngữ này.
Đến cuối năm 2023, Rust rõ ràng đã nổi lên như một thế hệ kế thừa trong dòng ngôn ngữ lập trình hệ thống.
Rust có cùng mức hiệu suất như C++, nhưng không có nhiều điểm hạn chế lịch sử của nó. Nó cung cấp các đảm bảo an toàn bộ nhớ mạnh mẽ mà không cần thu gom rác, thực thi tính đồng thời an toàn luồng tại thời điểm biên dịch, và được hỗ trợ bởi một hệ sinh thái nguồn mở lớn và có năng lực cao. Quan trọng không kém, Rust tích hợp hoàn toàn với các ngôn ngữ di động gốc—Swift và SwiftUI trên iOS, Kotlin và Jetpack Compose trên Android—biến nó thành một lựa chọn thực tế để chia sẻ logic cốt lõi mà không xâm phạm đến lớp giao diện người dùng.
Đây không phải là một quyết định không có rủi ro. Vào thời điểm đó, có rất ít ví dụ về các ứng dụng di động quy mô lớn, hướng đến người tiêu dùng được xây dựng trên kiến trúc tập trung vào Rust, và kinh nghiệm về Rust trong đội ngũ còn hạn chế.
Nhưng sự đổi mới có ý nghĩa hiếm khi xảy ra trong vùng an toàn. Thách thức thực sự không phải là bản thân Rust, mà là sức ỳ của tổ chức—chuyển từ các phương pháp tiếp cận bảo thủ, đã được chứng minh sang thử nghiệm có chủ ý, được hướng dẫn bởi các ràng buộc rõ ràng và đánh giá kỹ thuật.
Proton Mail mới: kết quả và bài học kinh nghiệm
Hãy tua nhanh đến ngày hôm nay và xem canh bạc này đã diễn ra như thế nào.
Sơ đồ bên dưới thể hiện kiến trúc của Mail trên di động. Phần lõi Rust chịu trách nhiệm cho toàn bộ logic nghiệp vụ của ứng dụng. Việc sử dụng Rust đã được đẩy xa hơn các ứng dụng thông thường (mạng, lưu trữ, tính toán thuật toán) vào việc xử lý logic điều hướng phức tạp. Một trường hợp điển hình là logic kiểm soát việc cuộn vô hạn của danh sách thư. Mặc dù không theo quy chuẩn, điều này đã được chứng minh là chìa khóa để đạt được mục tiêu tối đa hóa việc tái sử dụng mã. Kết quả là, gần 80% cơ sở mã hiện được chia sẻ trên iOS và Android.
Điều này có giúp đưa sản phẩm ra thị trường nhanh hơn và chất lượng cao hơn không? Mặc dù vẫn còn quá sớm để đưa ra phán quyết cuối cùng, nhưng những dấu hiệu ban đầu rất đáng khích lệ:
- Trong hai tháng sau khi phát hành, đội ngũ đã quản lý để duy trì nhịp độ cập nhật tính năng hàng tuần trên cả hai nền tảng (tổng cộng có 12 bản phát hành tính năng).
- Các khoảng cách tính năng giữa các nền tảng đã được đóng lại, mang các tính năng được mong đợi từ lâu đến Android như hoãn, phản hồi lời mời họp (RSVP) trên lịch và vuốt sang thư tiếp theo.
- Ngay cả ở giai đoạn đầu này, cơ sở mã mới đã chứng minh tính ổn định hơn so với các thế hệ trước trên cả hai nền tảng: tỷ lệ sập ứng dụng trên iOS là 0,05% (giảm từ 0,12%), trong khi của Android trở lại mức cơ sở lịch sử (0,19%). Đây là sự chứng thực mạnh mẽ cho tính ổn định trong thời gian chạy của Rust.
Hỗ trợ cũng mở rộng quy mô hiệu quả hơn theo cách tiếp cận này. Thường sẽ nhanh hơn để xác định và giải quyết một nguyên nhân gốc rễ duy nhất, chia sẻ hơn là truy tìm các sự cố tương tự về mặt bề ngoài phát sinh từ các lỗi logic hơi khác nhau trải rộng trên hai cơ sở mã độc lập. Đã tìm thấy bằng chứng xác thực cho giả thuyết hoạt động trước đây trong khi khắc phục một loạt sự cố đồng bộ hóa danh mục ảnh hưởng đến logic nền tảng cho các khả năng ngoại tuyến của ứng dụng: một nguyên nhân gốc rễ, một giải pháp—được thể hiện trong sơ đồ ở trên bởi mô-đun Rebasing được phân phối cùng với phiên bản 7.6.2.
Mặt trái của đồng xu?
- Các lỗi và lỗi hồi quy có khả năng có tác động rộng hơn và ảnh hưởng đến người dùng trên cả hai nền tảng. Không thể có được tất cả—nhưng chắc chắn có thể giảm thiểu rủi ro bằng cách tập trung mạnh vào kiểm thử đầu cuối (E2E).
- Giống như bất kỳ việc phân chia giải pháp hướng đến người dùng nào theo ranh giới công nghệ ngang, có rủi ro tạo ra các hố ngăn kiến thức và mất đi sự tập trung kỹ thuật vào trải nghiệm người dùng đầu cuối. Cần phải nhận thức được điều này và chủ động giảm thiểu rủi ro. Trong số các biện pháp hiệu quả nhất:
- Điều chỉnh các nhóm phụ để phân phối các tính năng thay vì các lớp công nghệ.
- Đào tạo các kỹ sư di động trở thành “full stack”, tức là có thể gỡ lỗi, hỗ trợ và phát triển trên cả cơ sở mã Rust và các nền tảng bản địa.
Tiếp theo là gì cho Chuyển đổi Kỹ thuật
Ngay từ đầu dự án này, rõ ràng là các mối đe dọa đã vượt xa Proton Mail. Việc áp dụng thành công ngăn xếp công nghệ này vào ứng dụng hàng đầu của Proton luôn được dự định là bước đầu tiên trong một hành trình dài hơn—một hành trình cuối cùng sẽ chứng kiến cách tiếp cận này được triển khai trên phần còn lại của hệ sinh thái di động.
Kịch bản đó hiện đang diễn ra. Khi viết bài viết này, các SDK Tài khoản và Thanh toán, cũng như thế hệ ứng dụng di động Proton Calendar tiếp theo, đang được viết lại theo hướng kỹ thuật mới này.
Sự kiện này đánh dấu sự khởi đầu của làn sóng chuyển đổi kỹ thuật thứ hai—một sự phát triển mở rộng kế hoạch công nghệ với khung kiến trúc được thiết kế để giúp việc tái sử dụng thành phần dễ dàng hơn, không chỉ trên các nền tảng mà còn trên các sản phẩm. Mặc dù quá trình chuyển đổi này sẽ không diễn ra trong một sớm một chiều, nhưng nó là nền tảng để xây dựng hệ sinh thái tích hợp liền mạch, ưu tiên quyền riêng tư mà khách hàng mong đợi ở Proton.
(1): Simon Lewis, “Chiến lược triển khai ứng dụng trên nhiều nền tảng”, 2023.
