Trong ngành phần mềm, có một nguyên tắc nổi tiếng Đừng tạo lại bánh xe (Don't reinvent the wheel). Ý tưởng của nguyên tắc này rất hợp lý: nếu cộng đồng đã có sẵn một thư viện hoặc framework tốt, việc tận dụng sẽ giúp tiết kiệm thời gian, chi phí và rút ngắn thời gian phát triển sản phẩm.
Tuy nhiên, khi xây dựng một nền tảng lớn như EzyPlatform, mọi thứ không còn đơn giản là "có sẵn thì dùng". Trên thực tế, EzyPlatform vẫn sử dụng thư viện bên ngoài ở những vị trí phù hợp, nhưng với các phần liên quan đến công nghệ lõi (core technology) như kiến trúc tổng thể, các thư viện HTTP, Socket, kết nối cơ sở dữ liệu, EzyPlatform lại ưu tiên tự phát triển hoặc kiểm soát sâu về mặt kỹ thuật. Đây không phải vì EzyPlatform muốn làm mọi thứ từ đầu, mà vì nền tảng cần giải quyết những yêu cầu dài hạn:
  • Sự ổn định
  • Khả năng mở rộng
  • Bảo mật
  • Hiệu năng
  • Khả năng hỗ trợ khách hàng
  • Mô hình Marketplace
Dưới đây là những lý do quan trọng.

1. Sự ổn định là điều quan trọng nhất của nền tảng

Một website đơn lẻ gặp lỗi có thể ảnh hưởng đến một doanh nghiệp. Nhưng với nền tảng như EzyPlatform, một thay đổi nhỏ có thể ảnh hưởng đến rất rất nhiều các dịch vụ mà khách hàng đang chạy. Khi phụ thuộc quá nhiều vào thư viện bên ngoài sẽ xuất hiện nhiều vấn đề:
  • Mỗi thư viện có chuẩn khác nhau
  • Chu kỳ nâng cấp khác nhau
  • API thay đổi khác nhau
  • Cách cấu hình khác nhau
  • Dependency chồng chéo lẫn nhau
Ví dụ:
  • Plugin A dùng thư viện X phiên bản 1.2
  • Plugin B yêu cầu thư viện X phiên bản 2.0
  • Core hệ thống dùng phiên bản 1.8
Kết quả có thể dẫn tới tình trạng dependency hell: 
flowchart TD
    A[EzyPlatform Core] --> B[Plugin A]
    A --> C[Plugin B]
    A --> D[Theme C]

    B --> E[Library X v1.2]
    C --> F[Library X v2.0]
    D --> G[Library Y v3.1]

    E --> H[Xung đột phiên bản]
    F --> H
    G --> I[Xung đột dependency khác]

    H --> J[Lỗi runtime]
    I --> K[Build fail]
    
    J --> L[Khó nâng cấp]
    K --> L
Ban đầu hệ thống có thể hoạt động bình thường. Nhưng vài tháng sau:
  • thư viện ngừng hỗ trợ
  • API thay đổi
  • tính năng bị deprecated
  • phiên bản mới không tương thích
Khi đó chi phí xử lý thường cao hơn rất nhiều so với việc kiểm soát từ đầu.
Vì vậy đối với EzyPlatform thì tốc độ phát triển nhanh là quan trọng, nhưng sự ổn định dài hạn còn quan trọng hơn.

2. Khả năng nâng cấp, mở rộng và tùy biến là điều quan trọng thứ hai

Một nền tảng Marketplace không giống một ứng dụng đóng. EzyPlatform cần hỗ trợ plugin, theme, API, SDK, event system, tích hợp hệ thống ngoài, v.v Trong khi đó, đa số thư viện bên ngoài được xây dựng để giải quyết bài đặc trưng. Nhưng thực tế khách hàng lại thường yêu cầu rất đa dạng, ví dụ như:
  • thay đổi logic xác thực
  • custom workflow
  • mở rộng event
  • can thiệp luồng xử lý dữ liệu
Đôi khi cùng một tính năng nhưng 2 khách hàng lại yêu cầu khác nhau. Nên nếu core phụ thuộc quá sâu vào thư viện ngoài: Mỗi lần tùy biến sẽ phải sửa source thư viện, fork repository hay maintain phiên bản riêng. Điều này dẫn tới việc khó nâng cấp, tăng chi phí bảo trì và mất khả năng đồng bộ.
Flow sẽ thường giống như sau:
flowchart TD
    A[Yêu cầu mới từ khách hàng] --> B{Thư viện hỗ trợ?}

    B -->|Có| C[Sử dụng trực tiếp]
    B -->|Không| D[Fork thư viện]

    D --> E[Sửa source]
    E --> F[Quản lý phiên bản riêng]
    F --> G[Khó nâng cấp về sau]

    C --> H[Dễ bảo trì]
Khi làm chủ công nghệ lõi:
  • hệ thống có thể thiết kế mở rộng ngay từ đầu
  • plugin có thể gắn thêm logic
  • module có thể tùy biến
  • ít ảnh hưởng tới phần còn lại của hệ thống

3. Đảm bảo khả năng chủ động vá lỗi khi có lỗ hổng bảo mật

Bảo mật không phải câu chuyện nếu nó xảy ra mà là khi nào thì xảy ra. Một thư viện log như apache log4j tưởng chừng như quá nhỏ, quá nội bộ để không bao giờ bị lỗ hổng bảo mật thì lại gây ra zero day thì không còn bất cứ thư viện nào có thể tự tin 100% là không có lỗ hổng cả. Nếu sử dụng thư viện bên ngoài, quy trình xử lý thường là:
flowchart LR
    A[Phát hiện lỗ hổng] --> B[Chờ cộng đồng xác nhận]
    B --> C[Chờ bản vá]
    C --> D[Kiểm thử]
    D --> E[Triển khai]
Trong khoảng thời gian đó hệ thống có thể bị tấn công, dữ liệu có thể bị ảnh hưởng, khách hàng có thể gặp rủi ro.
Nếu EzyPlatform kiểm soát phần lõi:
flowchart LR
    A[Phát hiện lỗi] --> B[Tự phân tích nguyên nhân]
    B --> C[Tự vá lỗi]
    C --> D[Kiểm thử nội bộ]
    D --> E[Phát hành ngay]
Điều này đặc biệt quan trọng với xác thực token, upload file, phân quyền hay xử lý dữ liệu người dùng.

4. Đáp ứng mô hình kinh doanh Marketplace

Một trong những điểm khác biệt lớn của EzyPlatform là mô hình Marketplace. Khách hàng không chỉ dùng plugin của EzyPlatform Mà còn có thể dùng plugin, theme từ nhà phát triển khác. Khi khách hàng gặp lỗi:
  • plugin không chạy
  • API lỗi
  • theme hiển thị sai
  • dữ liệu không đồng bộ
Khách hàng thường không quan tâm lỗi đến từ đâu, khách hàng chỉ nhìn thấy website của họ đang không hoạt động và yêu cầu trợ giúp. Flow hỗ trợ thường diễn ra như sau: 
flowchart TD
    A[Khách hàng cài plugin] --> B{Plugin hoạt động?}

    B -->|Có| C[Website hoạt động bình thường]

    B -->|Không| D[Khách hàng cần hỗ trợ]

    D --> E[Kiểm tra plugin]
    E --> F[Kiểm tra theme]
    F --> G[Kiểm tra API]
    G --> H[Kiểm tra dữ liệu]
    H --> I[Phát hiện nguyên nhân]
    I --> J[Vá lỗi hoặc hỗ trợ]
Điều này yêu cầu EzyPlatform phải hiểu rất rõ:
  • cách plugin chạy
  • cách dữ liệu xử lý
  • cơ chế event
  • luồng giao tiếp giữa các module
Mức độ hiểu biết này chỉ đạt được khi làm chủ công nghệ lõi.

5. Giảm rủi ro phụ thuộc vào bên thứ ba

Phụ thuộc bên ngoài luôn có rủi ro:
  • thư viện ngừng phát triển
  • tác giả dừng hỗ trợ
  • thay đổi giấy phép sử dụng
  • chuyển sang mô hình trả phí
  • dự án bị archive
Lịch sử phần mềm đã chứng minh điều này xảy ra khá nhiều. Một thư viện rất phổ biến hôm nay chưa chắc còn tồn tại sau vài năm. Nếu công nghệ lõi phụ thuộc quá sâu:
  • chi phí chuyển đổi sẽ rất lớn
  • ảnh hưởng nhiều hệ thống
  • tạo ra rủi ro dài hạn

6. Tối ưu hiệu năng cho đúng bài toán thực tế

Thư viện mã nguồn mở thường phải phục vụ hàng triệu trường hợp sử dụng khác nhau. Điều này khiến chúng chứa nhiều chức năng dư thừa, nhiều lớp abstraction, nhiều logic tổng quát Hệ quả là dung lượng của EzyPlatform có thể phình to, ngoài ra khi sử dụng có thể bị tăng RAM, tăng CPU, tăng thời gian xử lý.
Khi EzyPlatform hiểu rõ dữ liệu được xử lý thế nào, điểm nghẽn ở đâu, luồng nào cần tối ưu thì có thể, tối ưu cache riêng, tối ưu truy vấn riêng, tối ưu event riêng và loại bỏ xử lý không cần thiết.

7. Tạo lợi thế công nghệ dài hạn

Nếu mọi nền tảng đều dùng cùng framework, dùng cùng thư viện, dùng cùng kiến trúc thì rất khó tạo khác biệt.
Công nghệ lõi mới chính là nơi tạo ra DNA của nền tảng:
  • kiến trúc plugin
  • hệ thống event
  • khả năng scale
  • cơ chế mở rộng
  • luồng dữ liệu
Đây mới là giá trị tạo nên lợi thế lâu dài cho EzyPlatform.

Tổng quan lý do EzyPlatform làm chủ công nghệ lõi

flowchart TD
    A[Làm chủ công nghệ lõi]

    A --> B[Ổn định hệ thống]
    A --> C[Dễ nâng cấp]
    A --> D[Dễ mở rộng]
    A --> E[Chủ động bảo mật]
    A --> F[Tối ưu hiệu năng]
    A --> G[Hỗ trợ Marketplace tốt hơn]

    B --> H[Nền tảng phát triển bền vững]
    C --> H
    D --> H
    E --> H
    F --> H
    G --> H

Kết luận

EzyPlatform không cố tình tránh thư viện mã nguồn mở. Ngược lại, thư viện bên ngoài vẫn rất hữu ích ở nhiều vị trí phù hợp. Tuy nhiên, với những thành phần ảnh hưởng trực tiếp đến:
  • sự ổn định
  • khả năng mở rộng
  • bảo mật
  • hiệu năng
  • mô hình Marketplace
  • trải nghiệm khách hàng
thì việc làm chủ công nghệ lõi gần như là lựa chọn bắt buộc. Bởi với một nền tảng, mục tiêu không chỉ là làm cho nó chạy được là xong mà còn phải làm cho nó ổn định, phát triển được và tồn tại lâu dài.