Khám phá Platform engineering – 7 điều cần biết khi áp dụng Platform engineering vào doanh nghiệp của bạn

Hầu hết các developers ghét làm bất cứ điều gì không liên quan đến việc code: quản lý cơ sở hạ tầng, tạo và cấu hình repositories, xử lý CI/CD pipelines, v.v… Hầu hết thời gian, họ ước mình có thể tập trung vào những gì họ giỏi – viết những đoạn code tuyệt vời – và để người khác xử lý phần còn lại.

Bạn thử đoán xem đó là gì? Có một giải pháp cho vấn đề đó: platform engineering. Đây là một cách để giảm bớt gánh nặng công việc cho các developers, để họ có thể tập trung vào việc mang lại giá trị cho product. Đó cũng là một cách để tránh một số cạm bẫy phổ biến khi triển khai DevOps.

Platform engineering là gì?

Platform engineering là quá trình xây dựng toolchains và workflows nhằm trao quyền cho các developers khả năng self-service. Điều này cho phép họ xử lý độc lập toàn bộ lifecycle của việc phát triển phần mềm. Các toolchains và workflows này kết hợp với nhau được gọi là một platform, với cốt lõi là Internal Developer Platform (IDP).

Nói một cách đơn giản, IDP được tạo thành từ công nghệ và tools mà developer cần để thực hiện công việc của họ. Tất cả các thiết lập được trừu tượng hóa (abstracted) theo nhu cầu của từng developer. Nhiệm vụ tạo và quản lý các platforms này thường được xử lý bởi platform engineering team, những người xem các developers là khách hàng nội bộ và platform là việc phân phối product.

Hiện tại, platform engineering đang gây được nhiều tiếng vang như một lĩnh vực mới nổi. Các cloud providers như AWS và Azure đang xây dựng các services chỉ để hỗ trợ platform engineering. Trong khi đó, các công ty như Accenture đang cung cấp platform engineering as a service. Nó đang trở nên rất phổ biến và rất nhanh.

Tại sao lại có sự cường điệu xung quanh platform engineering?

Nguồn gốc của platform engineering thực sự bắt đầu với sự nổi lên của DevOps. Mười lăm năm trước, DevOps thực sự thành công: các tổ chức bắt đầu áp dụng nó, các chuyên gia công nghệ và developers đón nhận nó và các tools mới dành cho DevOps xuất hiện. Đó là cách tiếp cận vàng sẽ phá vỡ rào cản giữa ops và developers, đồng thời trao quyền cho các tổ chức cung cấp phần mềm và giải pháp nhanh hơn. Ai mà không muốn điều đó chứ?

Và đối với nhiều tổ chức, DevOps đã thực hiện được lời hứa này. Tuy nhiên, nhiều người khác đã phải vật lộn để đạt được outcomes mong muốn và sáng kiến DevOps của họ đã thất bại. Tại sao? Có nhiều loại “anti-patterns” (còn được gọi là “anti-types”) làm suy yếu tính hiệu quả của các DevOps projects. Anti-pattern là một phản ứng phổ biến đối với một quá trình lặp đi lặp lại nhưng cuối cùng lại mang tính phản tác dụng cao.

Thất bại của DevOps: Khi các developers gặp khó khăn trong việc xử lý cơ sở hạ tầng

Một trong những anti-patterns chính đối với DevOps – và là lý do phổ biến dẫn đến sự thất bại của các DevelOp projects – là sự thiếu gắn kết. Một team nhỏ trong tổ chức (thường là các developers) chịu gánh nặng xây dựng structures và workflows của riêng họ để triển khai vận hành DevOps. Team này đảm nhận trách nhiệm tập hợp các tools và workflows cần thiết để quản lý hiệu quả các nhiệm vụ phát triển và vận hành, trở thành tâm điểm để chuyển đổi khái niệm trừu tượng về DevOps thành một functional framework một cách hiệu quả.

Kết quả là gì? Triển khai DevOps không thành công hoặc giảm hiệu quả, dẫn đến việc cung cấp giải pháp hoặc phần mềm chậm hơn. Điều này hoàn toàn trái ngược với những gì bạn mong muốn khi triển khai DevOps.

Để có danh sách đầy đủ về các anti-patterns phổ biến của DevOps, bạn có thể tham khảo resource sau: DevOps anti-types.

Internal Developer Platforms giúp giải quyết những lỗ hổng về cơ sở hạ tầng như thế nào?

Nếu bạn đã quen với khái niệm trong ITIL được gọi là danh mục service, thì bạn sẽ hiểu khái niệm Internal Developer Platforms. Cả danh mục service của ITIL và IDP trong Platform Engineering đều đóng vai trò là tài nguyên tập trung (centralized resources) để hỗ trợ việc cung cấp và quản lý service trong một tổ chức.

• Danh mục service ITIL cung cấp cái nhìn tổng quan có cấu trúc về các service công nghệ thông tin hiện có, mô tả của chúng và các thỏa thuận service-level liên quan.
• Tương tự, IDP (chẳng hạn như Backstage hoặc Humanitec) hoạt động như một danh mục dành cho developers, cung cấp cổng thông tin self-service để truy cập vào các tools, services và resources cần thiết cho việc phát triển phần mềm.

• Cả hai đều cung cấp khả năng hiển thị các service có sẵn, thúc đẩy tiêu chuẩn hóa (standardization), cho phép các teams dễ dàng khám phá và sử dụng các service theo yêu cầu.

Cuối cùng, cả danh mục service ITIL và IDP đều nhằm mục đích nâng cao hiệu quả, sự cộng tác và tính minh bạch trong các lĩnh vực tương ứng của chúng.

Đi theo “con đường vàng” (golden path) để thành công với DevOps và sử dụng product mindset

Platform Engineering hợp lý hóa toolchain và workflows DevOps bằng cách kết hợp chúng thành một khái niệm được gọi là golden paths. Golden path có thể được coi là một bộ tools và workflows phù hợp với nhu cầu chung của developer. Golden path giúp developer dễ dàng mua những thứ họ cần và tiến về phía trước mà không cần phải phát minh lại bánh xe cho một software project.

Bạn nên xem platform engineering là một product nội bộ và development team là khách hàng của mình. Bạn nên áp dụng các nguyên tắc quản lý product vào quá trình phát triển và tiến hóa IDP. Điều này có nghĩa là:

• Hiểu nhu cầu và yêu cầu của users platform, cho dù họ là developers nội bộ hay các stakeholders khác.
• Thu thập feedback, tiến hành nghiên cứu user cũng như ưu tiên các tính năng và cải tiến dựa trên giá trị và tác động của chúng.
• Có cái nhìn toàn diện về lifecycle của platform, từ thiết kế và phát triển ban đầu đến bảo trì và lặp lại liên tục.

Mindset này đảm bảo rằng platform này được xem là một product đang phát triển, có tầm nhìn, lộ trình rõ ràng và tập trung tận tâm vào việc mang lại giá trị cho users.

Khi nào thì tổ chức của mình nên áp dụng platform engineering?

Theo nguyên tắc chung, nếu bạn có từ 20 developers trở lên thì đây là thời điểm thích hợp để cân nhắc việc áp dụng platform engineering. Hầu hết các tools liên quan đều phổ biến và bạn có thể đã biết chúng nếu bạn đang làm việc trong DevOps hoặc GitOps. Điều này có nghĩa là chỉ cần một chặng đường học tập nhỏ để mở rộng sang platform engineering.

Ngay cả khi tổ chức của bạn hiện chưa sẵn sàng thì đó vẫn là một không gian mới nổi mà bạn không nên bỏ qua. Nhu cầu về platform engineering đã tồn tại từ lâu và vấn đề mà nó giải quyết cho DevOps sẽ không còn nữa.

Các hành động tiềm năng kế tiếp

• Khám phá xem sắp tới có nhu cầu về Platform Engineering hay không và chuẩn bị cho nhu cầu đó.
• Hãy cân nhắc việc run một project thí điểm platform engineering có thể lặp đi lặp lại.
• Tiếp tục trau dồi kiến thức bản thân thông qua các bài đăng trên blog (như bài viết này) và các quyển sách về platform engineering.
• Tham gia vào các nhóm user, hội nghị và cộng đồng Slack – bạn có thể tìm thấy những cộng đồng này tại www.platform engineering.org.
• Cuối cùng nhưng không kém phần quan trọng, hãy tham gia một số khóa đào tạo về Platform Engineering!

Cảm ơn bạn vì đã đọc bài viết này!