Tôi đã có ác cảm với Docker từ rất lâu rồi.
Điều khiến tôi bực bội nhất ư? Một cái Docker image cứ nhất quyết phải tải về cả gia phả 18 đời tổ tông của nó, gần như bê nguyên cả cái kho npm về máy tính của tôi. Và để làm gì? Để rồi tôi ngồi nhìn chằm chằm vào cái pipeline CI/CD chạy mất 15 phút… và đây không phải là lần đầu tiên.
Cái máy tính cùi bắp của tôi quạt quay như máy bay phản lực chỉ để khởi động vài ứng dụng không hề phức tạp. Tôi sửa một dòng code, muốn xem thử kết quả trên local, nhưng thời gian chờ build lại cái image cũng đủ để pha một ấm trà.
Và rốt cuộc tôi làm tất cả những điều này vì cái gì?
Chẳng phải chỉ để chạy một dự án cần dùng Python, Rust, Node.js, và PHP, kèm theo Redis và PostgreSQL thôi sao?
Có phải chế tạo tên lửa đâu cơ chứ.
Nhưng tôi đã luôn nghĩ rằng mình đang làm điều "đúng đắn". Docker nghe có vẻ ngầu mà, phải không? Môi trường cô lập, đồng nhất với production, mở rộng vô hạn. Nhưng tất cả những gì tôi nhận được là sự phức tạp, viết file YAML đến mức muốn nôn ọe, và một môi trường local cứ ba ngày bảy bữa lại dở chứng.
Cho đến một ngày, tôi… không phục vụ nữa.
Tôi đã xóa sổ Docker khỏi quy trình làm việc của mình.
Và bạn biết gì không? Trời không sập.
Ngược lại, cả thế giới bỗng trở nên tốt đẹp hơn.
Tôi đã thay thế Docker bằng gì? Câu trả lời là ServBay
Dù có bị ăn gạch, tôi cũng phải nói: Hầu hết các lập trình viên không cần Docker. Cái họ thực sự cần là một môi trường phát triển đáng tin cậy và dễ hiểu.
Thế là tôi tự hỏi: Rốt cuộc mình đang dùng Docker để làm gì?
1. Môi trường phát triển local? Docker quá phức tạp và thừa thãi.
Dự án của tôi có một frontend React, một API Node.js, một dịch vụ dữ liệu Python, một module PHP cũ nhưng quan trọng, và một công cụ hiệu suất cao viết bằng Rust.
Trước đây, tất cả chúng bị nhồi nhét trong một file docker-compose.yml nặng nề. Bây giờ, tôi dùng ServBay, một công cụ phát triển tích hợp. Nó cho phép tôi dùng giao diện đồ họa để chọn các phiên bản PHP, Node.js, Python mà tôi muốn, như đi chợ chọn đồ vậy. Các dịch vụ như database và Redis cũng chỉ cần một cú nhấp chuột để bật/tắt.
Kết quả? Không áp lực. Không gánh nặng tinh thần. Và nhanh như một cơn gió.
2. Build CI/CD? Docker là một gánh nặng.
Docker image từng là cơn ác mộng trong GitHub Actions của tôi. Build một microservice thôi cũng dễ dàng ngốn mất 12 phút.
Bây giờ thì sao? Tôi dùng thẳng runner có sẵn môi trường của GitHub và chạy vài dòng shell script sạch sẽ. Không Docker-in-Docker, không push/pull image, không có địa ngục cache.
CI của tôi bây giờ chỉ mất 3 phút là chạy xong. Lần nào cũng vậy.
"Nhưng… còn sự đồng nhất giữa môi trường dev và prod thì sao?"
Trời ơi, câu này tôi nghe đến mức mòn cả tai rồi.
"Docker đảm bảo sự đồng nhất giữa môi trường development và production!"
Tỉnh lại đi. Nó chẳng đảm bảo được cái gì cả.
Trừ khi bạn khóa cứng phiên bản của mọi base image và gói phần mềm trong Dockerfile và bắt buộc build lại toàn bộ sau mỗi thay đổi, nếu không môi trường container của bạn luôn luôn âm thầm trôi dạt một cách nguy hiểm.
Tôi đã gặp bao nhiêu lần cái cảnh "trên máy tôi chạy ngon lành" nhưng lên môi trường staging thì nổ banh xác? Tại sao? Có thể là một dependency cấp thấp nào đó trong base image đã được cập nhật. Có thể là một gói trong Alpine Linux đã thay đổi. Hoặc có thể là một cái tầng cache chết tiệt nào đó có vấn đề.
Kể từ khi tôi chuyển sang ServBay và dùng .servbay.config để triển khai, tôi lại gặp ít lỗi không đồng nhất môi trường hơn. Tại sao? Vì có ít thành phần chuyển động hơn, quản lý phiên bản rõ ràng hơn, và môi trường phát triển minh bạch hơn.
Lý do thực sự: Bạn không tin tưởng môi trường phát triển của mình
Docker đã trở thành một miếng băng cá nhân che đậy những vấn đề thực sự:
- Tài liệu thì lộn xộn, lỗi thời.
- Môi trường local của mỗi người là một phiên bản độc nhất vô nhị.
- Quy trình onboarding cho người mới thì hỗn loạn đến mức muốn trầm cảm.
Nhưng đây là vấn đề về quy trình, không phải vấn đề về container.
Khi tôi ngừng dùng Docker, tôi buộc phải ghi lại các bước dựng môi trường một cách rõ ràng. Và với ServBay, quy trình đó giờ đơn giản chỉ còn một câu: "Tải ServBay về, tick vào các dịch vụ cần thiết, và bấm nút khởi động."
Đây là các số liệu hiện tại của tôi:
- Thời gian build: Từ 12 phút → 3 phút
- Thời gian onboarding cho người mới: Từ 2 giờ → 15 phút
- Dung lượng ổ cứng: Từ 20GB+ Docker image → Chưa tới 500MB
- Gánh nặng tinh thần: Cuối cùng tôi cũng hiểu được tech stack của chính mình, không còn phải đi điều tra những vấn đề siêu hình như "tại sao container này không kết nối được với container kia?" nữa.
Làm ơn, đừng dựng cả một cụm K8s chỉ cho một cái App To-Do
Bạn đã bao giờ gặp một lập trình viên, nước bọt bay tứ tung, giải thích về kiến trúc microservice cho cái app To-Do đơn giản của anh ta chưa?
“Trời ạ, chúng tôi có một service tạo task, một service thông báo, dùng Redis để cache, RabbitMQ cho message queue, dữ liệu lưu trong PostgreSQL, và tất cả được điều phối bởi Kubernetes…”
Nghe oách thật đấy.
Nhưng trên thực tế, thứ họ thực sự cần có lẽ chỉ là: một service Express.js, một cái database, và thêm một cái cron job.
Nhưng không, chúng ta container hóa mọi thứ, thêm vào năm tầng trừu tượng, và tự chôn mình trong một biển YAML—để rồi dành phần lớn thời gian để debug tại sao cái K8s Ingress lại không định tuyến được đến service của mình.
Để tôi nói cho bạn một điều có thể bạn không thích nghe: Lập trình viên thường nhầm lẫn sự phức tạp của công cụ với sự trưởng thành về mặt kỹ thuật. Cứ như thể nếu không viết file YAML cho nó ra dáng thì mình không đủ chuyên nghiệp vậy. Kết quả là gì? Phần lớn thời gian bị lãng phí vào việc vật lộn với công cụ thay vì tạo ra giá trị.
Tất nhiên, tôi không có ý vơ đũa cả nắm. Trong một số kịch bản nhất định, Docker vẫn là một vũ khí lợi hại. Nhưng trong công việc phát triển web hàng ngày của tôi, nó chính là định nghĩa của việc "dùng dao mổ trâu để giết gà".
Thứ tôi cần không phải là một công cụ có thể mô phỏng cả một trung tâm dữ liệu. Tôi chỉ cần một môi trường giúp tôi chạy code một cách nhanh chóng và ổn định. Và ServBay đã làm được chính xác điều đó.
Vậy, bài học rút ra là gì?
Thứ bạn cần không phải là container.
Thứ bạn cần là sự rõ ràng, kỷ luật, và một tech stack mà bạn thực sự có thể kiểm soát.
Và quan trọng nhất:
Hãy ngừng vọc vạch chỉ để tỏ ra ngầu trong giới công nghệ. Hãy bắt đầu làm việc vì tốc độ, sự tỉnh táo, và việc ra mắt sản phẩm.