Platform Engineering: Tại sao tư duy sản phẩm quan trọng hơn mã nguồn?

Bài viết được dịch và tổng hợp từ tin tức gốc. Bạn có thể đọc bài viết gốc bằng tiếng Anh tại đây.

Điểm tin nhanh:

• Platform Engineering thất bại thường do tư duy 'hạ tầng là trên hết' thay vì tập trung vào nhu cầu người dùng.
• Việc triển khai các công cụ như Backstage mà không có mục tiêu rõ ràng sẽ gây lãng phí nguồn lực và không mang lại giá trị.
• Thành công cần được đo lường bằng DevEx (Developer Experience) và các chỉ số SPACE thay vì chỉ đếm số lượng tính năng được code.

Nhiều đội ngũ kỹ thuật hiện nay đang rơi vào cái bẫy chết người: Họ coi việc xây dựng nền tảng phát triển nội bộ (Internal Developer Platform - IDP) như một dự án kỹ thuật thuần túy với deadline cứng nhắc. Nhưng thực tế, một nền tảng không có người dùng hạnh phúc cũng giống như một sản phẩm phần mềm không có thị trường. Khi bạn chỉ tập trung vào việc cài đặt công cụ mà quên đi việc lắng nghe những người trực tiếp sử dụng, bạn đang lãng phí tài nguyên vào những thứ không ai cần.

Tại sao các nền tảng phát triển nội bộ thường thất bại?

Max Korbacher, một chuyên gia dày dạn kinh nghiệm trong hệ sinh thái Cloud Native, đã chỉ ra rằng sai lầm lớn nhất của các kỹ sư là tư duy 'hạ tầng là trên hết'. Nhiều đội ngũ bắt đầu bằng việc triển khai các portal như Backstage chỉ vì thấy Spotify làm điều đó rất thành công. Tuy nhiên, họ quên mất rằng Backstage chỉ là một lớp giao diện; nếu không có sự đầu tư về cấu hình và quy trình, nó sẽ trở nên trống rỗng và vô dụng.

Các lý do phổ biến dẫn đến sự thất bại của IDP bao gồm:

Lưu ý: Đừng bao giờ bắt đầu bằng công cụ. Hãy bắt đầu bằng việc tìm hiểu những khó khăn mà đội ngũ phát triển của bạn đang gặp phải hàng ngày.

Tư duy sản phẩm trong Platform Engineering

Để xây dựng một nền tảng bền vững, bạn cần áp dụng tư duy của một Product Manager. Điều này có nghĩa là bạn phải coi các lập trình viên trong công ty là khách hàng của mình. Thay vì tự hỏi 'Chúng ta có thể code tính năng gì?', hãy tự hỏi 'Lập trình viên đang gặp rào cản gì trong quy trình deploy?'. Nếu bạn đang loay hoay với việc tối ưu hóa quy trình, hãy tham khảo cách tối ưu hóa quy trình báo cáo để hiểu cách tiếp cận vấn đề từ gốc rễ.

Đo lường giá trị thực tế

Việc đo lường thành công không nên dựa vào số lượng commit hay số lượng service được tạo ra. Thay vào đó, hãy tập trung vào:

1. DevEx (Developer Experience): Mức độ hài lòng và sự thuận tiện khi sử dụng nền tảng.
2. SPACE Metrics: Đo lường năng suất dựa trên sự hài lòng, hiệu suất, và sự cộng tác.

Nếu bạn đang xây dựng các hệ thống phức tạp, việc tự xây dựng hệ thống Feature Flags cũng là một cách để tăng cường tính linh hoạt cho nền tảng mà không cần phụ thuộc vào các giải pháp bên thứ ba đắt đỏ. Ngoài ra, hãy luôn nhớ rằng bản demo hoạt động không phải là bằng chứng của nhu cầu thị trường, vì vậy hãy kiểm chứng mọi ý tưởng trước khi scale.

Đánh giá & Lời khuyên Thực tiễn

Từ góc nhìn của một kỹ sư cấp cao, Platform Engineering không phải là một dự án có điểm kết thúc, mà là một sản phẩm liên tục tiến hóa.

• Ưu điểm: Giúp chuẩn hóa quy trình, giảm thiểu nợ kỹ thuật và tăng tốc độ phát triển (velocity).
• Nhược điểm: Dễ rơi vào bẫy 'randomeering' - thêm thắt các công cụ mới chỉ vì chúng đang là xu hướng (như KubeCon trends) mà không thực sự cần thiết.
• Lưu ý: Khi triển khai, hãy bắt đầu với 'Minimum Viable Governance' (Quản trị tối thiểu). Đừng cố gắng kiểm soát mọi thứ ngay từ đầu. Hãy để nền tảng phát triển cùng với sự trưởng thành của đội ngũ.

Câu hỏi thường gặp (FAQ)

Tại sao Backstage thường bị coi là khó triển khai?

Backstage rất mạnh mẽ nhưng nó đòi hỏi một đội ngũ vận hành chuyên trách để cấu hình các plugin và tích hợp vào hệ thống hiện tại. Nếu không có nguồn lực, nó sẽ trở thành một gánh nặng thay vì giải pháp.

Làm thế nào để biết nền tảng của tôi có đang mang lại giá trị?

Hãy thực hiện các cuộc khảo sát định kỳ với lập trình viên. Nếu họ vẫn phải dành quá nhiều thời gian cho các tác vụ thủ công (toil) thay vì viết code, nền tảng của bạn chưa thực sự hiệu quả.

Tôi nên bắt đầu từ đâu nếu muốn áp dụng tư duy sản phẩm?

Hãy bắt đầu bằng việc phỏng vấn các team phát triển, liệt kê các 'pain points' lớn nhất của họ và giải quyết từng vấn đề một thay vì cố gắng xây dựng một nền tảng toàn diện ngay từ ngày đầu.

Kết luận

Platform Engineering là một hành trình dài đòi hỏi sự kết hợp giữa kỹ thuật chuyên sâu và tư duy sản phẩm nhạy bén. Đừng để những công cụ hào nhoáng che mắt bạn khỏi mục tiêu cuối cùng: giúp lập trình viên làm việc hiệu quả hơn. Nếu bạn muốn tìm hiểu sâu hơn về tư duy kỹ thuật, hãy đọc thêm bài viết về tư duy kỹ thuật: thứ mà AI không thể thay thế. Hãy theo dõi hi_dev để cập nhật những xu hướng công nghệ mới nhất và chia sẻ kinh nghiệm của bạn trong phần bình luận bên dưới.