12 yếu tố để xây dựng một webapp chạy được

Trước giờ chỉ cắm đầu vào code cho đến một ngày tôi được một ông DevOps dở hơi nào đó nói cho tôi nghe về thuật ngữ “The Twelve-Factor App”. Sau một tuần dài, nay cuối tuần nên tôi sẽ dành một ít thời gian để ghi chép lại một số điều mà tôi học được từ khái niệm trên

Cơ bản tôi rút ra 12 factor app được sử dụng để giải quyết một số vấn đề dưới đây:

• Thống nhất một quy đình khi phát triển app, để các thành viên trong team không phải đau đầu đi tìm một flow chung
• Khái niệm này không chỉ đòi hỏi về kiến thức lập trình, còn liên quan đến các kiến thức về kiến trúc hệ thống, quy trình để phát triển dự án.
• Code mang ra production để chạy rồi thì làm sao để fix bug, release một bản vá hay phiên bản mới một cách nhanh nhất.
• Hiện nay tôi đang đảm nhiệm viết service đăng ký và đăng nhập. Tôi phải làm gì .
• Các yêu tố trong pháp luận rất phổ biến do nó phù hợp với các nguyên tắc của một hệ thống Microservices.
• Khi team có một developer mới gia nhập, đã có flow chung nên rất dễ dàng và nhanh chóng tham gia dự án. Không cần tốn thời gian vào việc đào tạo nhân sự mới.

Twelve-Factor App methodology là cái chi ?

Đây là một phương pháp luận để xây dựng các ứng dụng dới dạng dịch vụ, Sotfware as a Service. Phương pháp luận này c xây dựng bởi nhiều developer trên thế giới và tổng hợp lại thành 12 yêu tố, bộ yếu tố này giúp các webapp có khả năng mở rộng linh động và khả năng phục hồi.

Dưới đây là 12 yếu tố trong phương pháp luận và một số ví dụ cơ bản, các yếu tố đã có một bản dịch Tiếng Việt nhưng theo tôi vẫn nên đọc bản gốc bằng Tiếng Anh.

• 1. Codebase.
  Code luôn được quản lý và theo dõi trong một hệ thống quản lý phiên bản của mã nguồn (ví dụ là Git,Subversion …) . Chỉ có một codebase duy nhất cho một app, nhiều app không thể cùng một code tuy nhiên có thể làm dependency cho nhau dưới dạng thư viện. Các app chỉ có một codebase nhưng phải đáp ứng có thể deploy trên nhiều môi trường.
  Các môi trường ở đây bao gồm một production site, một hoặc nhiều staging site và các developer có thể sử dụng để chạy dưới môi trường dev của họ.
  Để quản lý được luồng code có thể tham khảo thêm gitflow
• 2. Dependencies
  Hiện tại nhiều ngôn ngữ đã có các package system đã phân phối các thư viện ( npm, maven, graven ). Tuy nhiên nêu việc quản lý các package của app không rõ ràng thì khó có thể tránh khỏi việc sử dụng các system-wide package trong các local project. Việc có các manifest khai kháo rõ ràng và chính xác cho từng app sẽ tránh được trường hợp “chạy trên máy dev” và lên thực thế thì build bị lỗi. Ngoài ra khi một developer mới muốn phát triển một feature từ app thì chỉ cần pull về và cài các dependency tránh trình trạng mất nửa ngày chỉ để tìm và cài gói thiếu.
• 3. Config
  Cấu hình của app là mọi thứ có thể thay đổi giữa các môi trường khác nhau ( dev, staging và production ). Trong cấu hình thường bao gồm:
  - Các cấu hình để làm việc với database, memcached và endpoint của các dịch vụ
  - Các cấu hình credential của AWS S3 hay FB Developer app.
  - Các giá trị cho mỗi lần triển khai ví dụ như domain, hostname.
  Trong 12 Factor, "hard code" các giá trị trong config là cấm kị kể cả trong môi trường dev. Các config phải được plan từ đầu, các config phải được chứa trong biến môi trường. Các biến môi trường dễ dàng thay đổi giữa các môi trường deploy mà không cần thay đổi, các biến môi trường không giống như các file config, các file config vẫn chịu ảnh hưởng bởi các config loader của các ngôn ngữ ví dụ như Java System Properties cần bố trí theo một cấu trúc yêu cầu.
• 4. Backing services
  Backing service là các dịch vụ mà app kết nối qua mạng, không phân biệt dịch vụ tại chỗ hay do bên thứ 3 cấp. Ví dụ có thể là MongoDB, hàng đợi RabbitMQ hoặc Kafka, hệ thống cache như Memcached được gọi là một backing service. Trong 12 factor các dịch vụ này đối với app là các tài nguyên đính kèm, thay đổi nhanh gọn endpoint và credential thông qua config. Ví dụ ban đầu đang sử dụng MySQL trên server tại chỗ, tuy nhiên muốn thay đổi lên sử dụng AWS RDS chỉ cần thay đổi URL và tài khoản kết nối.