Ngày nay, chúng ta gặp khó khăn trong việc xác định DevOps vì vấn đề mà nó giải quyết ban đầu đã không còn nữa.

Đối với một số công ty gần đây, vấn đề này chưa bao giờ thực sự tồn tại! Họ đang làm mọi thứ một cách chính xác, nhưng thay vào đó, bối cảnh công nghệ phần mềm đã phát triển nhanh đến mức khoảng trống đã được lấp đầy bằng công cụ và kỹ thuật đám mây.

Chúng ta đã khác xa với thời kỳ đầu của DevOps và sự thay đổi văn hóa của nó nhằm phá vỡ rào cản giữa Dev và Ops.

Silo Dev và Ops

Trở lại năm 2008, khi Patrick Dubois Lần đầu tiên nghĩ đến DevOps, anh ấy đang xem xét sự cộng tác kém hiệu quả giữa bộ phận phát triển và vận hành trong bối cảnh quản lý dự án vừa chuyển từ mô hình thác nước sang Agile.

Các nhóm vận hành lúc đó quản lý mọi thứ từ mạng, máy chủ, máy ảo, hệ điều hành và cập nhật phần mềm. Điều này có hiệu quả ẩn rất nhiều hoạt động thủ công. Không phải mọi thứ đều được thực hiện thủ công, nhưng đó là trước khi Puppet, Chef và Ansible — hay thậm chí là Terraform tồn tại.

Việc quản lý phát hành máy chủ và phần mềm không hề đơn giản và đòi hỏi nhiều chuyên môn. Điều gì đó có thể ngăn cản việc phân phối các bản phát hành phần mềm mới một cách nhanh chóng và đáng tin cậy.

Đám mây, dấu hiệu đầu tiên của sự lụi tàn của silo

AWS ra đời năm 2006 là nhà cung cấp đám mây lớn đầu tiên. DevOps được tạo ra vào năm 2008 và không nhằm mục đích giải quyết vấn đề quản lý đám mây mà là các Silo thực sự giữa hoạt động của cơ sở hạ tầng tại chỗ. Đây là gốc rễ của sự nhầm lẫn về DevOps là gì. Hai sự thay đổi lớn trong bối cảnh công nghệ phần mềm bắt đầu cùng một lúc.

Khi nói đến điện toán đám mây, chúng tôi sử dụng ba mô hình chính: Phần mềm dưới dạng dịch vụ (SaaS), Nền tảng dưới dạng dịch vụ (PaaS) và Cơ sở hạ tầng dưới dạng dịch vụ (IaaS). Bởi vì chúng tôi đang sử dụng các cấu trúc cấp cao đó nên OPS (quản trị hệ thống) gần như đã biến mất. Điều này giống như vấn đề văn hóa ban đầu được cha đẻ của DevOps xác định không còn tồn tại.

Mỗi mô hình cung cấp các cấp độ kiểm soát, tính linh hoạt và quản lý khác nhau của cơ sở hạ tầng cơ bản và rất ít công ty duy trì cơ sở hạ tầng tại chỗ.

Vì vậy, trong khi phong trào DevOps đang cố gắng giải quyết các vấn đề “silot” giữa Dev và Ops , cơ sở hạ tầng đám mây đã làm mờ dần một phần vấn đề bằng cách khiến Ops trở nên lỗi thời .

Không có hoạt động, không có silo

Các phương thức chính của DevOps là “dịch chuyển sang trái” và “bạn xây dựng nó, bạn chạy nó”, điều này chỉ có thể dẫn đến việc chuyển (các) nhiệm vụ Ops sang cho Nhà phát triển. Đám mây giảm nhu cầu về quản trị viên hệ thống (Ops) bằng cách cung cấp mô hình IaaS, giảm nỗ lực cho các nhà phát triển trong việc tự quản lý và triển khai ứng dụng.

Chúng ta có thể diễn đạt lại nó để làm cho nó nghe hay hơn! Ops đã trao quyền cho Nhà phát triển bằng cách cung cấp các công cụ để đơn giản hóa việc tích hợp và triển khai phần mềm, do đó, giảm bớt gánh nặng mà các nhóm vận hành yêu cầu để duy trì cơ sở hạ tầng. Kết quả là chúng tôi rơi vào tình huống không cần quản trị hệ thống (Ops).

Tuy nhiên, chúng tôi cần ai đó duy trì “các công cụ giúp đơn giản hóa việc tích hợp và triển khai phần mềm”.

Vai trò mới nổi này vẫn chưa có tên vì nó được mang đến cho bạn bởi Ops cũ, người đã đổi tên nó thành “DevOps guys”. Hãy gọi nó là kỹ sư DevOps. Có lẽ ai đó đã nói điều đó vào một lúc nào đó, và nó đã bị mắc kẹt.

DevOps đã tự xác định lại

DevOps chưa bao giờ nói về công cụ; đó là về văn hóa. Ý tưởng là công nghệ phần mềm cũng có thể trở nên “Tinh gọn” hơn và việc phân phối phần mềm có thể được thực hiện đúng lúc. Vấn đề ban đầu của DevOps có thể đã tồn tại từ lâu nhưng nó đã khai sinh ra ý tưởng quan trọng nhất trong công nghệ phần mềm: Phân phối liên tục.

Tôi từ lâu đã ủng hộ những người cho rằng DevOps không phải là một vai trò hay một nhóm và nếu bạn gọi nó như vậy thì bạn đang làm sai. Sau này tôi nhận ra rằng mọi chuyện phức tạp hơn nhiều. Chúng tôi đã tạo ra một vai trò một cách vô lý, “(những) người duy trì các công cụ để đơn giản hóa việc tích hợp và triển khai phần mềm,” nhưng chúng tôi không đặt tên cho vai trò đó.

Khi nghĩ về điều đó, bạn có thực sự cần “(những) người duy trì các công cụ để đơn giản hóa việc tích hợp và triển khai phần mềm” nếu mọi thứ đều được cung cấp trên nền tảng đám mây không? Được quản lý hoàn toàn? Hoạt động chỉ bằng một nút bấm?

Đây là giấc mơ của hầu hết các nhà cung cấp Đám mây và của nhiều sản phẩm DevOps SaaS (ví dụ: hãy nghĩ về GitLab). Sự thật không đơn giản như vậy. Về mặt lý thuyết, mọi thứ có thể đơn giản và các nhiệm vụ Ops có thể được tự động hóa, dịch vụ được quản lý hoàn toàn, v.v. Trên thực tế, chúng tôi đã tạo ra một con quái vật.

Do đó, thách thức đối với hầu hết các nhóm vận hành/cơ sở hạ tầng (còn gọi là Ops) là điều hướng bản đồ của vô số công cụ và dịch vụ, hiểu, triển khai và kết nối các công cụ đó thành một cơ sở hạ tầng và công cụ mạch lạc mà các nhà phát triển có thể sử dụng.

DevOps bị mắc kẹt là từ thông dụng quan trọng đó, dễ dàng bắt nguồn từ: DevSecOps, FinOps, GitOps, MlOps, v.v.

Nhưng nếu bạn để ý, hương thơm đọng lại luôn là Ops. Điều buồn cười là mỗi cách tiếp cận đều nhằm mục đích loại bỏ Ops của phương trình. Ops, hay còn gọi là “(những) người đăng nhập vào hệ thống và thực hiện mọi việc để hệ thống hoạt động”.

TL;DR

Vấn đề ban đầu mà DevOps đặt ra để giải quyết có thể không còn tồn tại do sự phát triển của cơ sở hạ tầng đám mây. Tuy nhiên, DevOps đã khai sinh ra ý tưởng quan trọng về phân phối liên tục và mang đến sự thay đổi văn hóa trong công nghệ phần mềm.

Mặc dù thuật ngữ “DevOps” có thể vẫn được coi là một từ thông dụng nhưng nó đã dẫn đến sự phát triển của các phương pháp tiếp cận mới như DevSecOps, FinOps và GitOps, tất cả đều nhằm mục đích loại bỏ nhu cầu về các nhiệm vụ Ops truyền thống.

Cuối cùng, bối cảnh của DevOps và cơ sở hạ tầng đám mây không ngừng phát triển và thật khó để cập nhật và chọn đúng công cụ. Trớ trêu thay, DevOps ban đầu có nghĩa là sự hợp tác giữa Dev và Ops, nhưng nó đã chuyển sang loại trừ Ops khỏi phương trình.