Tản Mạn DevOps và NoOPS trong bối cảnh nhà nhà nói chuyện Cloud

Bài này viết theo trải nghiệm cá nhân của Gà, mong nhận được chia sẻ và trao đổi của nhiều bạn để chúng ta có cái nhìn đa chiều hơn. Không ngừng rèn luyện, không ngừng trau dồi.

Mình đã trải qua rất nhiều giai đoạn nghề nghiệp và cũng đi tìm việc, học nhiều bằng cấp chứng chỉ nhằm khiến mình trở nên có ích hơn, cảm thấy tự tin và có giá trị hơn khi tham gia vào một tổ chức nào đó. Có cái thời mấy Job liên quan ERP cực “hót”, có thời lại kỹ sư cầu nối (Brse), có thời lại Fullstack developer, có thời lại Solution Architect, có thời lại IT Project Manager, và hiện tại có thể là các vị trí liên quan đến Cloud Solution Architect hót hơn bao giờ hết. Bạn thử check xem các report về thu nhập thì các vị trí Cloud Solution Architect thường xuyên chiếm ngự trong Top 5 (AWS Cloud và  Cloud). Điều này cũng phản ánh xu thế và nhu cầu thị trường dịch chuyển theo cloud, nguồn lực lao động cũng đổ dồn về mảng này.

Mình không phải thuần túy làm về DevOps nhưng vì tính chất công việc mình làm sản phẩm trên cloud nên bắt buộc phải tìm hiểu và áp dụng cải tiến quy trình/ cách thức làm sản phẩm. Và mình phải học lại. Quá trình muốn học (learn) một cái gì đó mới, luôn phải bắt đầu bằng unlearn (loại bỏ một số tư duy và thói quen kinh nghiệm cũ để cho cái mới vào đã, rồi suy xét đánh giá sau.

DevOps là gì?

Ngày xưa các bạn developer lập trình phần mềm, sau khi lập trình phần mềm thì có 02 hướng:

  1. Chính bạn / đội developer đó sẽ triển khai phần mềm của mình viết trên hạ tầng nào đó (có thê on-premise hay nền tảng cloud). Khoan hãy nói triển khai dạng gì.
  2. Chuyển giao phần mềm đóng gói đó cho đội operation để cài đặt triển khai ở kiến trúc nào đó (Có load balancing hay không, có phân tải bao nhiêu node, có bảo mật thế nào, có phân lớp chia subnet hay join các vùng nào…

Tùy thuộc vào mỗi cty bạn lớn hay nhỏ, đặc thù nhiều hay ít mà thường rơi vào một trong hai loại trên. Với mỗi cách đều có cái thốn của nó:

  1. Với cách 1 (Dev làm hết), thường thì các bạn dev thuần túy sẽ không có kiến thức nhiều về architect mà chỉ thuần túy chuyển giao các yêu cầu thành các tính năng phần mềm. Việc để một bạn chuyên dev đi làm cài đặt OS, DB, Middleware thực sự là điều gì đó rất rủi ro và các hệ thống sẽ thành kiểu “em yêu khoa học”. Đây là cách mà các sản phẩm bị thui chột.
  2. Với cách thứ hai thì có vẻ chuyên nghiệp hơn nhưng phản vận hành một đôi operation sẽ phát sinh chi phía và việc truyền thông giữa đội dev và system thường là sinh nhiều cãi vã, đặc biệt và vấn đề hardware sizing, về tối ưu vận hành, về lãng phí chi phí do ko hiểu nghiệp vụ.

Và DevOps sinh ra để nhằm mục đích tự động hóa các quy trình chuyển đổi từ Dev lên trên môi trường Operation (hay production / dev lab). Vd đơn giản nhất là khi tạo một instance hay một máy chủ bạn phải cài OS, DB, Middleware thì DevOps có thể đơn giản tạo các image cho instance đó, khi cần launch là bấm cái launch luôn ko phải lọ mọ đi cài. Hay các quy trình tự động CI/CD rồi triển khai lên môi trường production mà không phải kiểu phải thủ công vào FTP rồi upload overwrite source code cái mới vào thế cái cũ.

Mà nhỡ nếu có upload version mới code bị lỗi, có thể rollback về bản cũ trong một cú click chẳng hạn. chính cái này là DevOPS. Khiến mọi chuyện dễ dàng cho Dev. Đơn giản theo cách hiểu của Gà là các bạn DevOps sẽ làm cuộc đời của Dev đơn giản hơn, chỉ việc code, triển khai lên production chỉ trong vòng một nốt nhạc.

Automation, automation and automation…

DevOps quả là một nghề hay ho và làm sao để trở thành DevOps… theo igà có 02 hướng:

  1. Từ các bạn có nhiều kiến thức về system / infrastructure như OS/ DB, Scripting, Virtualization… học thêm một chút và hiểu biết về lập trình software. Có Ops trước Dev.
  2. Từ một bạn làm Dev, học thêm các kiến thức về mạng máy tính, về hạ tầng… Có Dev trước Ops.

Theo cá nhân iga thì con đường có Dev trước Ops sẽ đi xa và lý thú hơn nhưng học cũng lâu hơn. Còn có Ops trước muốn lên DevOps sẽ nhanh nhưng về lâu dài sẽ thiếu sự linh hoạt do muốn linh hoạt bạn cần phải học và có tư duy lập trình, đặc biệt lập trình tự động. Nói chung là theo IT nói chung, DevOps hay SA nói riêng bạn đều phải liên tục trau dồi học hỏi. iga nghĩ rằng nếu bạn có background là một developer sẽ rất thuận tiện để phát triển đi xa.

Nhưng theo iga xu hướng tương lai sẽ là NoOps

NoOps là gì? NoOps là có nghĩa ko còn phần operation hoặc tiêu giảm luôn phần này. Đặc biệt nếu ngẫm nghĩ về xu hướng cloud hóa, chuyển đổi nền tảng lên cloud. Cách quy trình CI/CD được tự động với các dịch vụ rất mạnh mẽ ví dụ AWS có Amplifier hay dịch vụ Netlify chuyên hosting các static web. Một vài công cụ phổ biến trong chuỗi quy trình này ví dụ GitHub, GitLab hay Jenkin…

Có câu “DevOps is Dead. Long live NoOps

Theo cá nhân iga thì NoOps Era còn sẽ lâu, và không phải doanh nghiệp nào cũng bắt kịp hay chuyển đổi dễ dàng / nhanh chóng. Trong thế giới làm kiến trúc giải pháp, tư vấn giải pháp luôn có một quá trình quá độ, chuyển đổi từ từ, ví dụ làm cloud migration cũng phải từng phần kiểu hybrid cloud trước. Đội ngũ nhân sự của doanh nghiệp cũng luôn cần trau dồi để update các kiến thức mới, chuyển đổi lên các vị trí giá trị hơn cho bản thân và doanh nghiệp.

Solution Architect (SA) vs DevOps

Trong ngữ cảnh igà làm dự án thì SA làm các công việc liên quan đến nắm yêu cầu khách hàng, tư vấn giải pháp, đưa ra kiến trúc triển khai tối ưu theo các ràng buộc về công nghệ. Đôi lúc SA sẽ tham gia vào quá trình triển khai để đảm bảo các methodology / design được deliver thành công. Riêng về DevOps sẽ thiên về vận hành sau khi sản phẩm / phần mềm đi vào production.

Vậy SA sẽ tham gia chủ yếu vào giai đoạn tư vấn triển khai. DevOps sẽ tham gia chủ yếu vào giai đoạn vận hành. Ở giai đoạn triển khai SA và DevOps sẽ cùng involve (tham gia) tùy theo tính chất dự án và đặc thù khách hàng.

(Một dự án thông thường trải qua 03 giai đoạn lớn: tư vấn, triển khai, và maintenance).

Theo iGà, một SA tốt là SA rất nhạy với các bài toán khách hàng nêu ra và đưa ra các cách giải bài tối ưu, tư duy sẽ chủ động. Còn DevOps thiên về tối ưu hệ thống, tự động hóa vận hành…

Nếu để ý một điều thì sau này việc học một ngôn ngữ sẽ rất nhanh, các framework thì ra liên tục như rau ngoài chợ. Việc lập trình sẽ học kiểu phổ cập. Là một engineer theo igà nghĩ tương lai phần sáng tạo trong sản phẩm rất quan trọng, deploy sản phẩm đó lên hạ tầng hay nền tảng cloud sẽ dễ dàng và tự động hóa. Có nghĩa là sân chơi của Developer sẽ rất rộng và thỏa sức sáng tạo.

Đây là một số chia sẻ của igà. Mong nhận được chia sẻ từ các bạn ở phần comment nhé.

iga

 

 

Topics #amplifier #aws #cicd #git #netlify