Đây là một post trên Phê tê bốc.
Nhân dịp chú Trần Quang Khải hỏi về Cloud, DevOps cũng hay, em có cái tham luận (nói sơ sơ, không chi tiết, vì em đang lười):
~~~~~
He...he... dạo này anh đang lười viết những bài dài dài về cloud với DevOps.
Nhưng mà nói ngắn gọn thì đại khái như thế này:
* Container (docker hoặc những thứ ít phổ biến hơn như LXC/LXD) là đồ tốt, nên dùng.
* Khi dùng một hệ thống có nhiều container chạy nhiều server/software khác nhau thì phải có một software nào đó làm container orchestra để deploy và run hệ thống, ví dụ như K8S hoặc những thứ khác, chú search "docker container orchestration tools" thì ra một đống.
* Các thứ như K8S đều over-complicated, rất mất thời gian để setup, maintain trong quá trình build infrastructure và run infrastructure. Và đa số các công ty đếch phải Gu gờ, cũng không dùng tới khoảng 90% chức năng của các container orchestra software. Chỉ dùng khoảng 10% chức năng của nó thì tội vạ gì mà khổ thế?
* Các infrastructure software phổ biến hiện nay đều quá invasive, theo nghĩa là trong codebase của các software project phải có Dockerfile và một đống các file YAML, JSON của những tool ngu xuẩn kia.
Giả sử DevOps là cái gì đấy tốt, thì bọn software engineer chỉ cần viết code thôi, còn deploy và run thế nào là việc của bọn DevOps và mấy cái tool. Nhưng rất tiếc là trong các công ty software và các team làm software hiện nay, software engineer bị làm phiền quá nhiều về việc phải dùng những tools kia, nhiều trường hợp là phải dùng trong cả local dev và team dev works.
* Các files mô tả hệ thống kiểu như YAML, JSON và các server config, setup chỉ dùng được cho một software project cụ thể. Đến khi có project mới cần deploy và run, thì lại phải viết mới và thử lại, rất mất thời gian và rất chán.
=======
* Giải pháp là viết mẹ nó tool của mình, làm sao cho nó thoả mãn các yêu cầu:
- Ngắn gọn, đơn giản, không có chức năng thừa.
- Tách phần mô tả hệ thống (descriptive files) và phần execution (binary executable files) ra càng nhiều càng tốt.
- Không bắt buộc software engineer phải biết và dùng tool này cho local development work.
- Seamlessly deploy và manage các docker container ở build time và runtime.
- Reusable cho nhiều software project khác nhau mà không cần sửa đổi phần execution, mà chỉ viết mới phần descriptive files cho project mới.
- Làm việc với đủ loại cloud khác nhau, private, public, hybrid ...etc... Cloud Agnostic.
- Không dùng cú pháp counter-intuitive, tối nghĩa, ngu xuẩn như bọn Terraform, Cloudformation, Chef, Ansible, K8S các thứ dùng. Phần mô tả trong YAML phải vô cùng đơn giản, trực quan, dễ hiểu, cho phép configure số lượng, tính chất và config của các loại container mà kỹ sư phần mềm nào đọc cũng dễ hiểu, không cần phải học document ngu ngu như bọn kia.
-
Nghe thì có vẻ gớm, nhưng thực ra rất dễ làm. Hồi mấy năm trước có lần anh post một cái clip demo hệ thống do anh viết, có mỗi vài ba cái Ruby script, Jenkins và các descriptive files dùng YAML format, hoàn toàn nằm ngoài codebase của software project chính, chứ không invasive như bọn kia, deploy bất kỳ số lượng docker container nào ra bất kỳ cloud nào, private, public hay hybrid.
Và điểm lý thú là hệ thống của anh dùng các container như là các virtual machine, nghĩa là khi deploy software mới, hệ thống không nhất thiết phải build container image mới, deploy container rồi chạy nó.
Bọn các hệ thống dùng container bây giờ build mới container image rồi deploy nó, thế thì khác chó nào chú dùng cái laptop, mỗi lần có software upgrade mới thì vứt mẹ cái laptop đấy đi, mua cái laptop mới về rồi install lại toàn bộ software từ đầu.
Tất nhiên là quá trình build container image mới là do code làm, nhưng nó cũng mất thời gian.
Hệ thống của anh là chỉ trừ khi có biến đổi về hệ điều hành và những component lớn của container và software phụ thuộc thì nó mới build container image mới và redeploy container, rồi mới deploy software.
Còn không thì mỗi lần software engineer hoặc dev team hoặc devops team cần deploy code mới cho software product của team, thì Hệ thống của anh coi các docker container đang chạy là các máy tính đang chạy sẵn, chỉ việc build code trong codebase, push deploy rồi restart container là xong.
Mỗi container tốn dưới một giây đồng hồ để deploy software, vì không phải build mới container image rồi deploy container. Dùng multi-thread deployment thì toàn bộ quá trình deploy software của anh chỉ tốn mỗi build codebase và deploy ra container đang chạy.
Nhanh hơn rất rất rất nhiều so với ngồi chờ nó build container image thấy mẹ như các hệ thống ngu xuẩn kia, rồi mới deploy container mới build ra cloud.
Nhưng chẳng qua là các công ty software và các kỹ sư bị bọn nó lừa "Không cần biết X vẫn làm được Y, chỉ cần dùng tool có sẵn Z của chúng tôi", thế là đưa tiền và thời gian ra cho chúng nó chém.
=====
Về phần các dịch vụ chém khách hàng của các Cloud như AWS, GCP, Azure, hoặc những thứ râu ria, cung cấp dịch vụ gia tăng như DataDog, NewRelic, Splunk, SumoLogic ...etc... thì đừng có dùng.
Ví dụ như dùng AWS ở mức đơn giản nhất chỉ cần Route53, VPN, EC2, EBS, S3 là đủ.
Chỉ cần dùng vài con EC2, mỗi con deploy một đống container lên đấy là mình có mẹ cloud của mình, còn cần chó gì ECS, EKS và những thứ ngu xuẩn của nó.
Trong container của mình, mình dùng RabbitMQ hoặc ActiveMQ, thì còn cần mẹ gì SQS.
Trong container của mình, mình cài PostgreSQL (ví dụ thế), thì cần đếch gì RDS hay Redshift.
Tương tự cho tất cả các dịch vụ mắm thối, chém cổ khách hàng khác của chúng nó như ElasticCache, Kibana ...etc...
Tóm lại là có kiến thức cơ bản tốt, mình sẽ biết cái gì là nên dùng, nên sử dụng công cụ có sẵn hay viết một cái tool tự động hóa của mình thì tốt hơn.
~~~~~
Đọc thêm: