CLS - ICT

Làm thế nào để thay bánh xe khi xe vẫn đang chạy với tốc độ 100km/h?” 🏎️💨

Đây chính là bài toán hóc búa mà đội ngũ kỹ thuật tại CLS phải đối mặt khi quyết định chuyển dịch hệ thống sang kiến trúc Event-driven Architecture (EDA) trên hạ tầng K8s On-premise.

Thay vì một cú "đập đi xây lại" đầy rủi ro (Big Bang), chúng tôi đã chọn chiến lược Strangler Fig (Cây bóp nghẹt). Và "chuột bạch" đầu tiên chính là module Chứng chỉ.

Tại sao lại là module này? Và chúng tôi đã rút ra được những bài học "xương máu" gì?

1. Đừng tham lam, hãy bắt đầu từ sự độc lập Module Chứng chỉ đủ quan trọng để thử nghiệm nhưng cũng đủ độc lập để không làm sụp đổ toàn bộ hệ thống nếu có sự cố. Bài học ở đây là: Hãy bóc tách những phần ít phụ thuộc nhất để làm quen với dòng chảy dữ liệu mới.

2. Thay đổi tư duy (Mindset) quan trọng hơn thay đổi Code Không chỉ kỹ sư, mà ngay cả Product Owner cũng phải học cách tư duy theo "Sự kiện" (Event). Mọi thứ không còn là "A gọi B rồi đợi kết quả" mà là "A hoàn thành việc của mình và thông báo cho cả thế giới".

3. Kiên nhẫn là chìa khóa của sự bền vững "Muốn nhanh thì phải từ từ". Việc chuyển đổi kiến trúc là một cuộc chạy Marathon, không phải chạy nước rút. Hệ thống vẫn phải phục vụ hàng nghìn khách hàng Enterprise mỗi ngày, trong khi bên dưới, những mầm mống của EDA đang dần thay thế các kết nối cũ kỹ.

Kết quả? Module Chứng chỉ hiện tại không chỉ chạy ổn định hơn mà còn dễ dàng mở rộng, giảm tải đáng kể cho lõi hệ thống (Core).

Tuy nhiên, EDA không phải là "viên đạn bạc" cho mọi quy mô. Có những "hố vôi" về chi phí vận hành và quản trị Kafka trên On-premise mà bạn cần lường trước.

👉 Chi tiết lộ trình bóc tách và các lưu ý kỹ thuật từ thực tế của CLS đã được đúc kết trong bài viết mới nhất.

Link bài viết chi tiết tôi để dưới phần bình luận nhé! 👇

CÀNG NHIỀU TÍNH NĂNG, HỆ THỐNG CÀNG NHANH... "CHẾT"?

Trong một buổi làm việc với một khách hàng lớn mới đây, chúng tôi nhận được một "sấp" tài liệu dài dằng dặc các yêu cầu tùy biến. Vị CEO nhìn tôi và nói: "Tôi muốn nhân viên của mình có thể làm tất cả mọi thứ trên một màn hình duy nhất."

Đó là khoảnh khắc mà đội ngũ CLS hiểu rằng: Nếu chúng tôi gật đầu, chúng tôi không giúp họ, mà đang trực tiếp "khai tử" hệ thống đào tạo của họ trong tương lai gần.

Sau cuộc thảo luận căng thẳng, chúng tôi đã thuyết phục khách hàng "quay xe" thành công. Dưới đây là 3 bài học xương máu về nghịch lý của sự dư thừa trong hệ thống SaaS doanh nghiệp:

1. Bẫy "Feature Creep": Mỗi nút bấm thêm vào không chỉ là một dòng code, mà là một gánh nặng lên trải nghiệm người dùng (UX). Khi hệ thống trở thành một mê cung, nhân viên sẽ nản lòng trước khi kịp bắt đầu khóa học.
2. Áp lực hạ tầng K8s On-premise: Với hệ thống vận hành tại máy chủ nội bộ, tài nguyên là có hạn. Việc nhồi nhét quá nhiều Microservices không cần thiết sẽ làm tăng nguy cơ giật lag và Downtime khi có hàng vạn người cùng truy cập.
3. Quy luật 80/20: Thực tế, 80% hiệu quả đào tạo đến từ 20% tính năng cốt lõi. Sự tinh gọn mới chính là chìa khóa để vận hành bền vững.

Chúng tôi chọn cách nói "KHÔNG" với những yêu cầu thừa thãi để nói "CÓ" với sự ổn định tuyệt đối của khách hàng.

Tại sao CLS lại dám từ chối những hợp đồng tùy biến béo bở? Câu trả lời nằm ở triết lý phát triển sản phẩm mà chúng tôi đã đúc kết trong bài viết mới nhất.

👇 Link chi tiết câu chuyện và giải pháp nằm dưới phần bình luận!