Khi các tổ chức hướng tới DevOps để phát triển, phân phối và tích hợp liên tục các chức năng kinh doanh, việc kiểm soát cẩn thận là rất quan trọng.
Các tổ chức đang chuyển từ phương pháp phát triển phần mềm truyền thống theo mô hình thác nước và tầng lớp, nơi mã được tạo ra trong các khoảng thời gian xác định và kết hợp với quản lý hệ thống vận hành và quản lý ứng dụng, sang các phương pháp linh hoạt hơn.
Với nhu cầu ngày càng tăng về việc cung cấp chức năng nhanh chóng thông qua tích hợp liên tục, phát triển liên tục và phân phối liên tục, nhiều doanh nghiệp đang tìm cách áp dụng quy trình DevOps.
DevOps nhằm mục đích kết hợp các nhóm phát triển, kiểm thử và vận hành để hợp lý hóa việc di chuyển mã và các ứng dụng chức năng thông qua ba lĩnh vực này.
Tuy nhiên, quy trình này cần mức độ kiểm soát cao với các vòng phản hồi phù hợp để đảm bảo mọi thứ hoạt động trơn tru, mang lại kết quả tích cực cao nhất cho doanh nghiệp với tác động tiêu cực thấp nhất.
Sự chuyển đổi do nhà phát triển dẫn đầu
Vấn đề đối với các tổ chức là DevOps đang phát triển nhanh chóng – và đang phát triển từ dưới lên, thay vì được kiểm soát từ trên xuống.
Nhiều công cụ DevOps có sẵn dưới dạng phần mềm mã nguồn mở – không có rào cản nào đối với việc một cá nhân trong tổ chức tải xuống công cụ mà họ thấy phù hợp và bắt đầu sử dụng.
Đối với nhiều nhân viên trong bộ phận phát triển hoặc vận hành, đây là một cơ hội quá tốt để bỏ qua. Các nhà phát triển đã tìm kiếm các hệ thống hỗ trợ mà họ có thể tích hợp vào môi trường phát triển tích hợp (IDE) hiện có của mình, cho dù đó là các hệ thống thương mại như IBM Rational Software Architect hoặc Microsoft Visual Studio, hay các hệ thống mã nguồn mở như Eclipse.https://www.eclipse.org/downloads/)** hoặc Anjuta, hoặc phần mềm quản lý dự án như Atlassian Jira Software hoặc CA PPM.
Điều này đã dẫn đến việc sử dụng ngày càng nhiều các công cụ như Jenkins.https://searchitoperations.techtarget.com/tip/Secure-Jenkins-for-fast-and-safe-app-delivery(Chef và Puppet được các nhà phát triển và nhân viên vận hành sử dụng). Jenkins cung cấp một bộ quy trình tự động quản lý phiên bản phần mềm – hoàn chỉnh với các plugin để chấp nhận các công cụ quản lý phiên bản hiện có như Perforce, CVS, Subversion, Git và Accurev – cùng với các quy trình được tối ưu hóa cho việc phân phối liên tục. Chef và Puppet ban đầu tập trung nhiều hơn vào khía cạnh “Vận hành” của DevOps, sử dụng các nguyên tắc quản lý cấu hình để tạo ra các gói chức năng sau đó có thể được tự động cung cấp cho môi trường vận hành.
Mở rộng các tùy chọn
Khả năng của các công cụ này đã được cải thiện rất nhiều kể từ khi chúng lần đầu tiên ra mắt thị trường vào năm 2005 (Puppet), 2009 (Chef) và 2011 (Jenkins, về cơ bản là sự tiếp nối công việc được thực hiện trong dự án Hudson do Sun khởi xướng năm 2004 và hiện thuộc sở hữu của Oracle).
Khả năng của chúng hiện nay giao thoa với nhau nhiều hơn so với chỉ vài năm trước, và nhu cầu sử dụng các công cụ riêng lẻ khác để tạo ra một môi trường DevOps hoàn chỉnh đã giảm đi đáng kể.
Việc tăng cường hỗ trợ làm việc nhóm và các vòng phản hồi đầy đủ có nghĩa là những công cụ ban đầu chỉ dành cho cá nhân giờ đây đã hỗ trợ đầy đủ cho các nhóm – ngay cả trên các địa điểm phân tán và các nhóm làm việc xuyên suốt các công ty, chẳng hạn như nhà thầu và tư vấn viên.
Bên cạnh ba công cụ khổng lồ này, còn có các công cụ khác có sẵn theo nhiều giấy phép mã nguồn mở khác nhau phù hợp với cùng lĩnh vực, chẳng hạn như Ansible và Salt, cũng như các công cụ được tích hợp sẵn trong các hệ thống quản lý phần mềm container như Docker và Kubernetes. Đối với phương pháp tích hợp Ubuntu, được hỗ trợ bởi doanh nghiệp, Canonical cung cấp bản phân phối riêng của mình về **[Kubernetes thông qua JuJu](https://www.computerweekly.com/blog/Open-Source-Insider/AppScale-FastStart-for-Google-Compute-Engine-AWSKubernetes đang nhanh chóng trở thành một thế lực mới trong lĩnh vực điều phối container, có thể được sử dụng trong môi trường DevOps – nó được hỗ trợ bởi Cloud Native Computing Foundation (CNCF), với các thành viên như Amazon Web Services (AWS), Google, Microsoft, IBM, Intel, Twitter và nhiều công ty khác.
Cloud Foundry là một hệ thống mã nguồn mở khác – cũng có sẵn dưới dạng hệ thống được hỗ trợ thương mại, giống như hầu hết các công cụ mã nguồn mở đã đề cập – cung cấp một bộ khả năng tự động hóa phù hợp với DevOps, có khả năng cung cấp mức độ hỗ trợ cao cho các hệ thống thượng nguồn và hạ nguồn khác. Mặc dù Cloud Foundry cũng là thành viên của CNCF, nhưng nó có một số điểm tương đồng với những gì Kubernetes làm, tuy nhiên lại có phạm vi tiếp cận rộng hơn nhiều, vượt ra ngoài môi trường container hóa. Một dự án riêng biệt trong Cloud Foundry, được gọi là KuBo (Kubernetes trên BOSH) cung cấp một ngăn xếp Cloud Foundry/Kubernetes tích hợp cho những người làm việc trong môi trường mã ứng dụng không đồng nhất, máy ảo (VM) hoặc container.
Quá nhiều công cụ
Việc xử lý tình huống các nhà phát triển và quản trị viên hệ thống tự ý sử dụng các công cụ khác nhau, dẫn đến sự pha trộn các công cụ khác nhau trong môi trường CNTT, có thể trở thành vấn đề đối với các tổ chức. Có hai cách để giải quyết vấn đề này.
Thứ nhất, hãy đưa ra chỉ dẫn: Quyết định một bộ công cụ duy nhất để sử dụng và đặt ra quy định – tất cả các nhà phát triển và quản trị viên hệ thống phải sử dụng cùng một bộ công cụ. Thật không may, cách này gần như chắc chắn thất bại – hãy nhớ rằng bạn đang làm việc với các nhà phát triển và quản trị viên hệ thống. Hãy nhìn vào ngăn kéo trên cùng của bàn làm việc của họ và xem số lượng đĩa CD và USB chứa phần mềm không được phép sử dụng mà họ thấy hữu ích trong công việc hàng ngày. Họ có vẻ đồng ý với bạn về sự cần thiết của một công cụ duy nhất, nhưng rất có thể họ vẫn tiếp tục làm theo cách riêng của mình khi bạn không còn để ý.
Khi đó, các tổ chức sẽ rơi vào tình trạng tự cho mình là đúng: sau khi đã chỉ thị mọi người làm theo lời mình, họ cho rằng điều đó là đúng. Sau đó, xảy ra sự cố, và việc phân tích nguyên nhân sự cố sẽ làm sáng tỏ các vấn đề: các chức năng rời rạc, không có sự giám sát thống nhất.
Thứ hai, hãy thực tế: Chấp nhận rằng đã quá muộn để đảo ngược tình thế và tìm cách biến hỗn loạn các công cụ riêng lẻ thành một hệ thống sẵn sàng cho doanh nghiệp hơn.
Nhiều công cụ mã nguồn mở, thông qua việc sử dụng ngày càng nhiều các plugin hoặc giao diện lập trình ứng dụng (API) mở, có thể chấp nhận đầu vào từ các công cụ mã nguồn mở khác với độ chính xác từ khá đến cao.
Trong trường hợp cần mức độ kiểm soát cao hơn, cùng với sự hỗ trợ đầy đủ ở cấp độ doanh nghiệp, thì việc đăng ký sử dụng một trong các bản phân phối phần mềm mã nguồn mở được hỗ trợ đầy đủ – chẳng hạn như CloudBees, với sự hỗ trợ cho Jenkins và các thành phần bổ sung – có thể cung cấp thêm “tính chất doanh nghiệp” mà các tổ chức đang tìm kiếm.
Hệ thống mở mang lại tuổi thọ cao
Ngoài ra, cũng có các hệ thống thương mại cho phép mức độ mở tốt để hỗ trợ các công cụ hiện có. Một ví dụ là CA Automic, cung cấp một phương pháp tự động hóa tốt để tối ưu hóa quy trình DevOps đồng thời chấp nhận nhiều công cụ nền tảng khác nhau một cách mở.
Khả năng cho phép các hệ thống như vậy hoán đổi linh hoạt giữa các công cụ nền tảng khác nhau là một điểm quan trọng: năm năm trước, không nhiều người nói về Chef và Puppet, và Kubernetes chỉ mới được phát hành ba năm trước. Thị trường sẽ như thế nào trong năm năm nữa? Nếu hệ thống bao quát là một hệ thống khép kín với các liên kết cứng nhắc đến các công cụ được xác định, thì bạn có thể thấy mình bị tụt hậu. Nếu nó mở và cho phép chức năng cắm/rút, bạn có thể dễ dàng tiếp nhận các công cụ mới khi chúng xuất hiện.
Có rất nhiều công ty khác đang hoạt động trong lĩnh vực DevOps. Ví dụ, HashiCorp có một số công cụ, bao gồm Terraform và Vagrant, giúp đơn giản hóa việc vận hành môi trường DevOps. Perforce đã mở rộng từ lĩnh vực cốt lõi là kiểm soát phiên bản và đã ra mắt bộ công cụ Helix cung cấp nhiều chức năng DevOps.
Trong thế giới của phần mềm quản lý cấu hình hệ thống kiểu cũ đang phát triển, BMC có bộ tự động hóa BladeLogic. Được hiện đại hóa để hỗ trợ điện toán đám mây và container, BladeLogic Server Automation – đặc biệt khi kết hợp với các sản phẩm khác của BMC, chẳng hạn như Atrium Orchestrator, Control-M Automation và bộ TrueSight – có thể cung cấp chức năng DevOps.
Cơ sở hạ tầng có thể cấu hình của HPE thu hẹp khoảng cách giữa phần cứng và phần mềm, cho phép dễ dàng cấu hình các nền tảng logic và cung cấp phần mềm vật lý, ảo hóa hoặc container hóa thông qua việc sử dụng OneView.
Tất nhiên, cũng có các tùy chọn DevOps trên đám mây. IBM cung cấp một bộ khả năng rộng lớn thông qua nền tảng BlueMix của mình. AWS, Google và Microsoft cung cấp các công cụ trực tiếp trên nền tảng của họ, trong khi nhiều công cụ đã đề cập ở trên có sẵn để triển khai thông qua chế độ tự phục vụ trên nền tảng đám mây của họ.
DevOps đang trở thành một phương tiện chính để cung cấp cho doanh nghiệp những gì họ muốn và cần: phát triển liên tục các chức năng mới có thể được cung cấp nhanh chóng khi cần thiết. Một lưu ý nhanh: nó thực sự nên là “BusDevOps” – những nhu cầu và mong muốn đó phải do doanh nghiệp quyết định, chứ không phải do các nhà phát triển.
Để tận dụng tối đa môi trường BusDevOps như vậy cần có các công cụ mạnh mẽ – và điều này khó có thể đạt được thông qua các quy tắc mang tính bắt buộc hoặc cấm đoán. Hãy thực tế: cung cấp các hệ thống tổng thể có thể thiết lập trật tự cho sự hỗn loạn hiện có, và cho phép các nhà phát triển và quản trị viên hệ thống làm việc theo cách mà họ thấy phù hợp.
(Nguồn: https://www.computerweekly.com)
