Sau 11 tuần chuyển sang Kubernetes, công ty quên mất lý do tồn tại của mình (2020)
(theolognion.com)- Startup Thung lũng Silicon Xenobroom Inc. quyết định chuyển hạ tầng máy chủ hiện có sang Kubernetes khi lượng sử dụng hằng ngày tăng vọt trong đại dịch vào tháng 5/2020
- Việc chuyển đổi vượt xa một cải tiến triển khai đơn thuần và biến thành dự án dài hạn để xem xét lại, rồi thiết kế lại cấu hình dựa trên VPS và các bash script
- Phạm vi tiếp tục phình to khi đội ngũ đồng thời thúc đẩy nâng cấp dependency và library, chuyển một phần PostgreSQL sang kho lưu trữ KV phân tán, đồng thời tận dụng tính linh hoạt của AWS
- Máy chủ staging cũ cùng quy trình triển khai hằng ngày dựa trên nhánh develop được thay bằng workflow production-only CI, định tuyến động, A/B testing và hỗ trợ phụ thuộc theo khu vực
- Đến lúc tưởng như việc chuyển đổi đã xong, không còn ai trong công ty nhớ được mục đích của sản phẩm, còn người dùng và nhà đầu tư cũng thừa nhận họ vốn không hiểu sản phẩm ban đầu, khiến việc khôi phục gần như bất khả thi
Phạm vi công việc phình to vì chuyển sang Kubernetes
- Xenobroom Inc. bắt đầu nâng cấp hạ tầng máy chủ vào tháng 5/2020
- Theo các mẩu nhật ký của CEO và ghi chép kỹ thuật của CTO, lượng sử dụng hằng ngày đã tăng mạnh trong đại dịch
- Sau đó công ty quyết định chuyển hạ tầng hiện có sang Kubernetes
- Công việc kéo dài hơn dự kiến
- Cần phải dựng lại, rà soát và tái thiết kế các bash script đơn giản cùng những máy VPS
- Trong nội bộ công ty, đây cũng được xem là cơ hội để nâng cấp dependency và library phần mềm
- Thay đổi hạ tầng dẫn đến tái cấu trúc lớn hơn
- Công ty cho rằng có thể thay một phần lớn cơ sở dữ liệu PostgreSQL vốn chạy trên một máy đơn bằng kho lưu trữ KV phân tán
- Điều này cũng được gắn với lý do tận dụng tính linh hoạt của AWS
- Máy chủ staging đơn giản vốn được triển khai mỗi ngày từ nhánh develop biến mất
- Thay vào đó là workflow production-only CI với định tuyến động, hỗ trợ mượt mà cho A/B testing và các phụ thuộc theo khu vực
Đánh mất mục đích sản phẩm và tìm kiếm trợ giúp bên ngoài
- Khi quy trình chuyển đổi có vẻ đã hoàn tất, không còn ai trong công ty nhớ được mục đích của sản phẩm
- Người dùng và nhà đầu tư cũng không thể giải quyết tình hình
- Cả hai nhóm đều công khai thừa nhận rằng ngay từ đầu họ chưa từng thực sự hiểu sản phẩm
- Sau vài tuần downtime, việc khôi phục ý nghĩa của sản phẩm gần như là không thể
- CEO đã tìm đến Phutar Afrayughum, một nhà ngoại cảm kiêm chuyên gia nhận thức siêu cảm, để nhờ trợ giúp
- Ông được giới thiệu là người từng giúp Google tăng thị phần trong thị trường ứng dụng nhắn tin và cũng tham gia phát triển framework Material Design
- Tuy vậy, sự trợ giúp này được mô tả là “allegedly”, nên không thể khẳng định đó là sự thật
1 bình luận
Các ý kiến trên Hacker News
Bài này còn buồn cười hơn: nói về việc sa thải 20% quản lý cấp trung thì năng suất phát triển tình cờ tăng gấp 3 lần
https://www.theolognion.com/p/company-accidentally-increased...
Ở $dayjob của chúng tôi cũng đang làm một đợt migration kiểu này, bắt đầu từ 2 năm trước nhưng đến giờ vẫn chưa xong nổi 30%
Những người từng hô to nhất rằng “phải chuyển sang Kubernetes, phải giết monolith” giờ thì mải nghịch LLM nên quên Kubernetes rồi
Một số người thật sự thích proof of concept và những thứ mới bóng bẩy, và vai trò đó có vẻ cũng có ích ở mức nào đó
Vì vậy có vẻ những người thông minh vẫn làm việc khá thỏa mãn ở các tập đoàn công nghệ khổng lồ phi đạo đức, công ty quảng cáo, công ty giám sát
Công ty tồn tại vì lý do gì, hay thực sự làm gì bên ngoài chiếc máy tính của họ, không quan trọng lắm; điều quan trọng là công nghệ và quyền tự do theo đuổi cái mới
Công ty thích năng suất và nhiệt huyết mà họ tạo ra, và trả lương hậu hĩnh
Thường thì các developer kiểu này cũng có lương tâm, nhưng lương tâm đó hay bị hấp thụ và trưng bày dưới dạng các phong trào xã hội tốt đẹp thân thiện với doanh nghiệp
Ai đó đang lần lượt tick các ô chỉ để có thể nói “tôi đã làm X”
Trong một đội nhỏ, cách làm này có thể khiến năng suất dừng lại rất nhanh, và thường được bao bọc bằng mong muốn giải quyết mọi vấn đề
Nhưng kết quả là không vấn đề nào được giải quyết, trái lại còn sinh ra nhiều vấn đề mới hơn
Muốn thăng chức cần có promotion package, và promotion package cần một dự án lớn, nặng ký
Rốt cuộc vấn đề cốt lõi cần giải quyết không còn là nhu cầu kinh doanh mà là thăng chức, rồi xuất hiện những dự án khổng lồ đi tìm vấn đề
Thứ được mô tả dường như thậm chí còn không phải proof of concept. Điều kiện cơ bản của proof of concept là trước hết nó phải chạy được, còn cái này gần với việc tạo ra một cấu hình để chạy theo đám đông và trông có vẻ bận rộn
Với nhân viên thì đó có lẽ cũng không phải môi trường tốt để ở lâu
Blog đó còn nhiều bài buồn cười hơn nữa. Tôi đặc biệt thích bài này:
https://www.theolognion.com/p/dev-builds-perfect-note-taking...
Và còn bài này nữa:
https://www.theolognion.com/p/ai-solves-all-political-econom...
Người khác có thể bớt được hai cú nhấp
Tôi biết là chuyện đùa, nhưng nếu làm postmortem thì nguyên nhân thất bại có lẽ sẽ là “nhiều người trong công ty nghĩ nhân cơ hội này cũng nên nâng cấp dependency phần mềm và thư viện. Họ cũng cho rằng các phần lớn của cơ sở dữ liệu PostgreSQL chạy trên một máy đơn có thể được chuyển thành kho khóa-giá trị phân tán để tận dụng sự linh hoạt khổng lồ của AWS”
Phải giữ phạm vi
Trên đời có nhiều người tập trung vào công nghệ họ dùng hơn là sản phẩm họ làm ra
Tập trung vào sản phẩm nghĩa là biết phạm vi, và không thiết kế quá mức quá sớm
Trò đùa tập trung vào Kubernetes, nhưng cũng có thể viết y hệt với server-side rendering, AI, $modernFrontendLib, $modernLanguage
Nếu ngành kinh doanh không phải là bán hạ tầng cloud thì cứ dùng nhà cung cấp cloud có sẵn là được
Đặc biệt nếu đã đang trả tiền cho nhà cung cấp cloud rồi thì tốt hơn là không dùng Kubernetes
Trong thực tế, một đợt migration Kubernetes kéo dài 11 tuần hẳn đã được xem là đại thành công
Tất nhiên vận hành cơ sở dữ liệu chắc hơi vất vả. Vì họ quên cấu hình storage Kubernetes cho đúng, nên sau khi pod đột ngột bị chuyển chỗ thì dữ liệu đã biến mất
Còn nếu thậm chí chưa dùng Docker, thì trong một migration tương tự, vấn đề nhiều khả năng không nằm ở bản thân Kubernetes
Chưa bao giờ việc vận hành hệ thống lại dễ và rẻ như bây giờ
Thế nhưng các kỹ sư lại thích kiểu muốn giao một chiếc pizza thì lập đoàn viễn chinh, leo Everest, chụp ảnh pizza trên đỉnh, rồi mang nó về nhà bằng máy bay, thuê Lamborghini chạy Mongol Rally, và chỉ 18 tháng sau mới giao chiếc pizza đó
Trong lúc đó, chỉ cần đi một chiếc scooter rẻ tiền xuống cuối đường là thắng
Nếu là công nghệ phức tạp thì trước hết phải học đã. Nên thử trên một dịch vụ nhỏ và không quan trọng trước
Làm từng thứ một, và bắt đầu đơn giản
Tôi đã chuyển dịch vụ của chúng tôi sang Kubernetes mà không gặp vấn đề, nhưng mất 2 năm để học và thử nghiệm bằng cách chuyển các dịch vụ nhỏ
Sau khi thử nhiều cách tiếp cận, tôi mới tới được cách phù hợp nhất, mà đó không phải là cách có thể tìm thấy ngay trên Internet
Chúng tôi dùng GitOps nhưng không tự động hóa; với thứ cần thiết thì chỉ chạy
kubectl apply -k. Vì khi đó tôi cho rằng flux phức tạp không cần thiết để bắt đầuGiờ số dịch vụ đã lên tới hàng chục và cũng đã có hiểu biết, nên tôi đang nghĩ đến việc đưa flux vào
Năm 1977, tôi làm luật sư tranh tụng trẻ tại một hãng luật tính phí theo giờ.
Chúng tôi ghi trên giấy những việc đã làm cho từng vụ, và nhân viên văn phòng cắt các dải có thể xé ra từ những tờ giấy đã hoàn thành rồi dán lên bảng bên trong hồ sơ giấy của từng vụ.
Năm 1979, tôi mua một chiếc RadioShack Tandy I, và chẳng bao lâu sau ở nhà tôi đã đào sâu vào Foxbase, một chương trình cơ sở dữ liệu chạy trên DOS. Sau này nó trở thành FoxPro và được Microsoft mua lại vào đầu thập niên 1990.
Năm 1981, tôi mở hãng luật riêng; khi đó đổi mới mới nhất về năng suất văn phòng là máy fax và máy đánh chữ điện có màn hình một dòng, bộ nhớ, cùng đĩa nhỏ để lưu biểu mẫu. Các doanh nghiệp vẫn chưa dùng máy tính cá nhân.
Hãng luật của tôi nhanh chóng đạt quy mô khoảng 10 luật sư và 12 nhân viên hỗ trợ, và tôi mua máy tính Compaq cho tất cả thư ký.
Tôi dành rất nhiều thời gian để viết một chương trình theo dõi thời gian và lập hóa đơn thay cho việc dán dải thủ công, đồng thời học cách lắp đặt mạng rồi tự mình lắp.
Các hãng luật khác mà tôi biết không có lấy một chiếc máy tính, nhưng chúng tôi có hơn 10 máy cho nhân viên hỗ trợ và 4–5 chiếc Compaq “xách tay” cho luật sư xem lại hóa đơn trước khi gửi cho khách hàng.
Cùng lúc đó, tôi đang phá hỏng công việc kinh doanh của mình. Vào thời người khác còn chưa có một chiếc máy tính nào, chúng tôi có công nghệ ở tầm hàng đầu thế giới, nhưng tôi không tập trung vào việc hành nghề luật hay bán dịch vụ cho khách hàng doanh nghiệp; tôi đóng cửa phòng và chỉ lập trình.
Cuối cùng, năm 1994 tôi đóng cửa hãng luật.
Dù vậy, đó vẫn là một thời kỳ đầy phấn khích. Chẳng bao lâu sau, mọi hãng luật đều có máy tính để xử lý văn bản, nhưng chương trình lập hóa đơn thương mại thì vẫn chưa có.
Trong khoảng 24 tháng, tất cả luật sư ở các hãng luật khác từng làm việc với tôi đều muốn có chương trình lập hóa đơn của tôi.
Nhưng dù ngập trong công việc vụ án, tôi vẫn chỉ mải mê với việc lập trình thú vị, và công việc pháp lý của tôi là một phòng thí nghiệm hoàn hảo cho chương trình đó. Đáng tiếc là chính việc lập trình ấy đã phá hỏng công việc kinh doanh của tôi.
Nếu còn ảnh nào thì tôi rất muốn xem.
Trong lĩnh vực của tôi, chỉ cần thay “Kubernetes” bằng GraphQL/React/Next là vẫn đúng nguyên xi.
Tất nhiên đó là việc di chuyển một ứng dụng đang chạy hoàn toàn tốt, mà phần lớn còn là CRUD.
Họ làm vậy dù hoàn toàn không cần những đánh đổi mà GraphQL hay frontend tương tác mang lại.
Càng ở lâu trong ngành này, tôi càng thấy nhiều người ở vị trí có trách nhiệm thật ra không biết mình đang làm gì.
Họ được thưởng vì thay đổi, miễn là ít nhất có thể giả vờ rằng thay đổi đó đang tạo ra kết quả hoặc một ngày nào đó sẽ tạo ra.
Tôi đang vật lộn ngày đêm suốt 4 tháng để chuyển 500 nghìn blob từ MinIO tự host sang dịch vụ lưu trữ blob được quản lý, trong đó phần việc thật sự hiệu quả, không phải chính trị và quan liêu, chưa đến 1 tuần.
Vì vậy, một cuộc di chuyển Kubernetes kéo dài 11 tuần nghe như một thành công lớn.