Lịch sử của DevOps - Và tương lai đang hướng đến

cloudFun

Pic 1.png

Bạn làm việc trong DevOps. Bạn sống trong DevOps. Có lẽ DevOps thậm chí là kim chỉ nam cho công việc của bạn. Nhưng bạn có biết nguồn gốc của thuật ngữ này - và quan trọng hơn - ngành công nghiệp đang đi về đâu?

Tìm hiểu về lịch sử đằng sau việc quản lý cloud server rất quan trọng vì nó giúp chúng ta học hỏi từ những sai lầm trong quá khứ (và tránh lặp lại chúng) và dự đoán tốt hơn về tương lai. Đây là một cái nhìn khó hiểu về lịch sử của DevOps và nơi các tool phần mềm yêu thích của bạn có thể phù hợp với tương lai của nó.

Nguồn gốc của Developer

Trước khi nói về các Developer (nhà phát triển) thì nên nói về máy tính trước. Máy tính có thể đã tồn tại lâu hơn bạn đấy. Khái niệm máy tính có nguồn gốc từ ý tưởng của Alan Turing về một máy tự động của Google vào năm 1936. Là một thiết bị tương tự, ý tưởng đằng sau máy của Turing là đọc các bảng dữ liệu hữu hạn bằng băng và tính toán cơ học.

Ý tưởng của Turing đã dẫn đến việc tạo ra các máy tính cơ điện được sử dụng để giúp chính phủ Hoa Kỳ giải mã mã hóa của kẻ thù trong Thế chiến II. Những máy tính đầu tiên này là tiên phong cho những thế hệ sau, các máy tính lớn hơn được tạo ra bằng ống chân không, loại phần cứng bạn có thể thấy trong các bộ phim khoa học viễn tưởng cũ với hàng chục mặt số và đèn nhấp nháy.

Chừng nào các thiết bị điện toán này còn tồn tại thì vẫn cần có các operator (nhà vận hành) để lập trình. Các developer đầu tiên, bạn có thể gọi vậy theo cách hiểu hiện đại (ngồi gần một thiết bị đầu cuối và viết mã lưu trữ, mã kỹ thuật số) đã tạo ra ngôn ngữ lập trình Fortran vào năm 1957.

Vào cuối những năm 1970 và 1980, khi giá cả của các màn hình CRT ngày càng phải chăng, các developer có thể thường xuyên ngồi tại máy trạm, viết code trong quá trình phát triển, biên dịch nó và kiểm tra nó trên cùng một máy tính. Triển khai mã bao gồm biên dịch, sao chép vào hàng chục đĩa flop và cứ lặp lại như vậy. Các công ty bắt đầu tuyển tụng các vị trí lập trình viên để viết “mã nguồn”, một thuật ngữ chỉ mới gia nhập hệ thống từ vựng gần đây.

Tuy nhiên, có rất ít developer làm việc trong ngành kỹ thuật mạng, vì internet chưa được phát minh. Khái niệm về “uptime”và “downtime” nói chung bị giới hạn ở việc máy tính được bật hay tắt, trừ khi đó là một trong số ít thiết bị đầu cuối được kết nối với thứ mà sau này sẽ trở thành nguồn gốc của internet.

Pic 2.png

ARPANET, Internet và sự xuất hiện của “kỹ sư ổn định hệ thống”

Trước khi có World Wide Web, đã có ARPANET, một mạng lưới máy tính được chính phủ tài trợ trên khắp Hoa Kỳ, kết nối với nhau bằng cách sử dụng gói chuyển đổi qua đường dây điện thoại. ARPANET ra đời vào năm 1969, tạo ra các “trung tâm hoạt động mạng” thô sơ đầu trên toàn quốc, với nhân viên của “ops” quản lý cấu hình và uptime của mạng.

Đến năm 1989 - sau khi Tim Berners-Lee tạo ra giao thức World Wide Web đầu tiên, HTTP - đến khi Google thuê Ben Treynor để lãnh đạo các kỹ sư trong “môi trường sản xuất”, tách ra khỏi “môi trường phát triển” vào năm 2003. Các chức danh công việc mới của các kỹ sư này đã trở thành lịch sử: site reliability engineers – Kỹ sư quản lí độ ổn định của hệ thống hoặc viết tắt là SRE.

“Về cơ bản, đó là những gì xảy ra khi bạn yêu cầu một kỹ sư phần mềm thiết kế một chức năng hoạt động”_ TreBor Treynor cho hay về kỹ thuật độ tin cậy web.

Nhiệm vụ của họ là duy trì uptime cao cho Google, làm việc với các developer để đảm bảo các hoạt động không bị gián đoạn cho khách hàng. Tóm lại, hậu quả của bất kỳ downtime nào mà Google gặp phải trong sản phẩm chính đều dẫn đến thiệt hại hàng ngàn đô la doanh thu từ AdWords- ra đời vào năm 2000. Mặc dù thuật ngữ này chưa được đặt ra nhưng SRE là những nhà hoạt động đầu tiên trên DevOps.


Flickr bắt đầu kết hợp “Dev” + “Ops”


Google không phải là công ty duy nhất bắt đầu sử dụng SRE. Ngay sau đó, tất cả những nhà công nghệ lớn bắt đầu thực hành độ tin cậy web để giảm downtime và làm tăng sự hài lòng của khách hàng. Vào năm 2008, MobileMe của Apple đã trải qua một khoảng downtime vì cloud service non trẻ của họ đã nhận được “lưu lượng truy cập đến máy chủ nhiều hơn so với dự đoán” điều này chứng minh rằng ngay cả những anh lớn trong công nghệ cũng không tránh khỏi downtime - hoặc làm mất lòng khách hàng.


Bất hoà giữa Developer và Operator

Sự xuất hiện của John Allspaw và Paul Hammond, kỹ sư Flickr. Thông qua kinh nghiệm quản lý thời gian hoạt động tại trang chia sẻ ảnh lớn nhất thế giới (vào thời điểm đó), Allspaw và Hammond lưu ý rằng nhóm ops (operators), chịu trách nhiệm quản lý máy chủ và nhóm dev (developers), được giao nhiệm vụ tạo mã, dường như luôn luôn bất hòa hoặc thậm chí đổ lỗi cho nhau.

Giải pháp họ đề xuất là thuê các “ops nhưng nghĩ như devs” và “devs nhưng nghĩ như ops”. Trong một bài thuyết trình tại Hội nghị O’Reilly năm 2009, Allspaw và Hammond đã đề xuất tích hợp phát triển và vận hành vào một cơ sở hạ tầng tự động cùng với sự kiểm soát phiên bản chung và xây dựng và triển khai từng bước. “DevOps” đã ra đời theo cách đó, tuy nhiên tại thời điểm đó nó còn chưa được đặt tên.


DevOpsDays đầu tiên tại Vương quốc Bỉ

Một kỹ sư có tên Patrick Debois đến từ Bỉ, không thể tham dự hội nghị O'Reilly ở San Jose, California, đã quyết định tổ chức một hội nghị nhỏ hơn của riêng mình liên quan đến “quản trị hệ thống nhanh”, Tìm cách để quảng cáo hội nghị trên Twitter, Debois tạo ra một portmanteau (sự pha trộn ngôn ngữ) là “DevOps” như một hashtag rút ngắn từ phát triển và vận hành. Các hashtag nhanh chóng trở thành tên của phong trào mà Allspaw và Hammond lần đầu tiên phát biểu tại hội nghị Velocity.

Tên của Debois không chỉ được gắn cho quản trị hệ thống nhanh, mà còn là mô hình bản DevOpsDays của ông cũng được nội địa hóa. Ngày nay, DevOpsDays là một phong trào trên toàn thế giới, nơi các developer và operator chuyên nghiệp hoạt động cùng nhau ở các quốc gia sở tại để thảo luận về tự động hóa, thử nghiệm, bảo mật và văn hóa tổ chức cần thiết để tránh sự xung đột giữa dev và ops.

Pic 3.png

Dữ liệu của Google Trends cho thấy sự gia tăng tìm kiếm của “DevOps” từ năm 2009 cho đến nay.


DevOps hiện đại và “Franken-monitor”

Vì “DevOps” là một phương pháp vẫn còn khá mới mẻ nên có thể có những cách hiểu sai về DevOps “hiện đại”. Tuy nhiên, đây là thế giới công nghệ, và mọi thứ đều diễn ra rất nhanh chóng. Vào năm 2013, Bernd Harzog, khi đó còn là một nhà phân tích APM tại The Virtualization Practice, đã viết blog về “Fanken-monitor”. Ông than thở rằng tình trạng quản lý DevOps hiện tại bao gồm một loạt các công cụ quản lý liên kết với nhau để tạo ra một bức tranh hoàn chỉnh về cơ sở hạ tầng.

Vấn đề bất đồng quan điểm giữa Developer và Operator

Franken-monitor đã được viết trên blog này và CEO của chúng tôi đã trình bày về chủ đề này. Và có thể nhận định rằng đó là một vấn đề lớn. Đó là lý do tại sao nền tảng giám sát DevOps Blue Matador đã được ra mắt, nơi dự định sẽ có một sản phẩm giám sát phần mềm cho từng khía cạnh của chu trình phát triển và vận hành. Phương pháp này sẽ giải quyết được rất nhiều vấn đề cho các tổ chức đã xây dựng Franken-monitor của riêng mình và rồi sau đó phát hiện ra rằng chúng rất tốn kém, đối phó thay vì chủ động và có khả năng dự đoán về downtime.

https://youtu.be/jP8o-s_HhjE

DevOps: Nhất thời hay Tương lai?

Lịch sử về DevOps sẽ không hoàn chỉnh nếu không nhắc đến tương lai. Biết DevOps đã ở đâu trong thập kỷ qua, chúng ta có thể thấy ngành công nghiệp đang biến động ở đâu?

Từ quan điểm đô la và xu, DevOps sẽ tiếp tục bùng nổ. Theo một báo cáo nghiên cứu gần đây của Technavio, thị trường DevOps toàn cầu sẽ trải qua CAGR 19,42% từ 2016-2020. (CAGR là tốc độ tăng trưởng kép hàng năm và con số giữa 10 - 20% đều rất tốt cho triển vọng đầu tư.)

Nói tóm lại, DevOps sẽ tiếp tục tồn tại trong tương lai gần cho đến khi một số phương pháp mới - hoặc công nghệ - xuất hiện để phá vỡ kịch bản này. Sau tấy cả, đó là những gì DevOps đang làm đối với các hoạt động độc lập về phát triển, vận hành, QA và bảo mật.

Chúng ta đã thấy DevOps đang có khả năng trưởng thành và phát triển cao hơn. AI đang bắt đầu xâm nhập vào mọi thứ, từ điện thoại thông minh đến xe tự lái. Nó cũng sẽ giúp phá vỡ cấu trúc lõi của DevOps đó là tự động hóa. Ví dụ, tạp chí CIO gần đây đã báo cáo rằng các trợ lý ảo đang “thúc đẩy việc áp dụng” chương trình ChatOps và VoiceOps. Chúng tôi hy vọng sẽ thấy nhiều bot hơn và các khía cạnh hỗ trợ AI khác của DevOps trong tương lai gần.


Timeline của các sự kiện DevOps chính

1957
- Lập trình viên máy tính đầu tiên viết mã bằng Fortran, tạo công việc cho developer đầu tiên

1969 - ARPANET ra mắt, tạo ra các công việc kỹ thuật mạng và trung tâm điều hành mạng đầu tiên

2003 - Ben Treynor được thuê để lãnh đạo một nhóm bảy kỹ sư phần mềm để điều hành một môi trường sản xuất tại Google, tạo ra bộ “kỹ sư ổn định hệ thống” đầu tiên

2009 - John Allspaw và Paul Hammond của Flickr lần đầu tiên trình bày trên “10+ Deploys Per Day: Dev and Ops Cooperation at Flickr,” lần đầu tiên công khai phương pháp của DevOps

2009 - Patrick Debois tổ chức DevOps Day đầu tiên ở Bỉ và đặt tên cho thuật ngữ này là “DevOps” như một hashtag rút gọn để quảng bá

2012 - Splunk và SolarWinds, một số công cụ phần mềm DevOps đầu tiên, IPO với giá $ 1,57B và $ 802MM, báo hiệu tiềm năng tăng trưởng của ngành

2013 - Puppet Labs công bố khảo sát State of DevOps đầu tiên, nêu bật tình trạng và xu hướng của ngành

2017 - Nền tảng giám sát Blue Matador ra mắt, kết hợp giám sát máy chủ hỗ trợ AI và đăng nhập tập trung dưới một lần đăng nhập.





Nguồn: Bluematador
 
Top