Bugünlerde DevOps'u tanımlamakta çok zorlanıyoruz çünkü başlangıçta çözdüğü sorun çoktan ortadan kalktı.  Bazı yeni şirketler için sorun aslında hiçbir zaman yaşanmadı! Her şeyi doğru yapıyorlar, ancak bunun yerine yazılım mühendisliği ortamı o kadar hızlı gelişti ki boşluk, araçlar ve bulut mühendisliği tarafından dolduruldu.  DevOps'un orijinal gününden ve Dev ile Ops arasındaki siloları kırmayı amaçlayan kültür değişiminden çok uzaktayız.  Geliştirme ve Operasyon Siloları  2008'de, ne zaman  DevOps'u ilk düşündüğünde, proje yönetiminin şelaleden Agile'a yeni geçtiği bir bağlamda geliştirme ve operasyonlar arasındaki etkisiz işbirliğine bakıyordu.   Patrick Dubois  O dönemde operasyon ekipleri ağ oluşturma, sunucu, sanal makine, işletim sistemi ve yazılım güncellemelerine kadar her şeyi yönetiyordu. Bu, birçok manuel işlemi etkili bir şekilde gizledi. Her şey manuel değildi ama Puppet, Chef ve Ansible'dan, hatta Terraform'un ortaya çıkmasından önceydi.  Sunucu ve yazılım sürümlerini yönetmek basit bir iş değildi ve çok fazla uzmanlık gerektiriyordu. Yeni yazılım sürümlerinin hızlı ve güvenilir şekilde teslim edilmesini engelleyecek bir şey.   Siloların Söndüğünün İlk İşareti Bulut  2006 yılında doğan AWS, ilk büyük bulut sağlayıcısıdır. DevOps 2008 yılında icat edildi ve bir bulut yönetimi sorununu değil, şirket içi altyapının işleyişi arasındaki gerçek Siloları çözmeyi amaçlıyordu. DevOps'un ne olduğu konusundaki kafa karışıklığının kökeni budur. Yazılım mühendisliği ortamında iki büyük değişim hemen hemen aynı zamanlarda başladı.  Bulut bilişim söz konusu olduğunda üç ana model kullanıyoruz: Hizmet Olarak Yazılım (SaaS), Hizmet Olarak Platform (PaaS) ve Hizmet Olarak Altyapı (IaaS). Bu üst düzey yapıları kullandığımız için OPS (sistem yönetimi) neredeyse ortadan kalktı. Bu sanki DevOps'un babalarının tespit ettiği orijinal kültür sorunu artık yokmuş gibi.  Her model, temel altyapının farklı kontrol, esneklik ve yönetim düzeylerini sunar ve çok az şirket şirket içi altyapıyı sürdürür.  Yani DevOps hareketi   çalışırken bulut altyapısı,   sorunun bir kısmını zaten silikleştiriyordu.  , Dev ve Ops arasındaki "silot" sorunlarını çözmeye Ops'u geçersiz kılarak  Operasyon Yok, Silo Yok  DevOps'un temel motorları "sola kaydırma" ve "sen inşa et, sen çalıştır"dır; bu yalnızca bir Ops görevinin/görevlerinin Devs'e aktarılmasına yol açabilir. Bulut, IaaS modelini sunarak sistem yöneticilerine (Ops) olan ihtiyacı azalttı ve geliştiricilerin uygulamaları kendi başlarına yönetme ve dağıtma çabalarını azalttı.  Daha iyi ses çıkarması için onu yeniden ifade edebiliriz! Operasyon ekipleri, yazılım entegrasyonunu ve dağıtımını basitleştirecek araçlar sunarak Devs'i güçlendiriyor, böylece operasyon ekiplerinin altyapıyı korumak için ihtiyaç duyduğu ağır kaldırma yükünü azaltıyordu. Sonuç olarak sistem yönetimine (Ops) ihtiyaç duymadığımız bir durumla karşılaştık.   Ancak bu "yazılım entegrasyonunu ve dağıtımını basitleştirecek araçları" sürdürecek birine ihtiyacımız var.  Bu yeni ortaya çıkan rolün, onu "DevOps adamları" olarak yeniden markalayan eski Ops tarafından size getirildiği için henüz bir adı yok. Buna DevOps mühendisi diyelim. Muhtemelen birisi bir noktada bunu söyledi ve öyle kaldı.   DevOps Kendini Yeniden Tanımladı  DevOps hiçbir zaman araçlarla ilgili olmadı; kültürle ilgiliydi. Buradaki fikir, yazılım mühendisliğinin de daha "Yalın" olabileceği ve yazılım tesliminin tam zamanında yapılabileceğidir. DevOps'un başlangıçtaki sorunu çoktan çözülmüş olabilir ancak yazılım mühendisliğindeki en önemli fikri doğurdu: Sürekli Teslimat.  DevOps'un bir rol ya da ekip olmadığını iddia edenleri uzun süredir destekliyorum ve eğer buna böyle dersen yanlış yapıyorsun demektir. Daha sonra işlerin daha karmaşık olduğunu fark ettim. Uyumsuz bir şekilde "yazılım entegrasyonunu ve dağıtımını basitleştirecek araçları sağlayan adam(lar)" şeklinde bir rol yarattık, ancak buna bir isim vermedik.  Bunu düşündüğünüzde, eğer her şey bir bulut teklifiyse, gerçekten "yazılım entegrasyonunu ve dağıtımını basitleştirecek araçları koruyan adama/adamlara" ihtiyacınız var mı? Tamamen yönetiliyor mu? Tek tuşla mı çalışıyor?  Bu, çoğu Bulut sağlayıcısının ve birçok DevOps SaaS ürününün hayalidir (örneğin GitLab'ı düşünün). Gerçek o kadar basit değil. Teoride her şey basit olabilirdi ve Operasyon görevleri otomatikleştirilmiş, hizmet tamamen yönetilmiş vb. olabilirdi. Gerçekte bir canavar yarattık.   Sonuç olarak, çoğu operasyon/altyapı ekibinin (diğer adıyla Ops) karşılaştığı zorluk, sayısız araç ve hizmetin haritasında gezinmek, bu araçları anlamak, dağıtmak ve geliştiricilerin kullanabileceği tutarlı bir altyapı ve araçlara bağlamaktır.  DevOps'un takılıp kalması, türetilmesi kolay, moda olan anahtar kelimedir: DevSecOps, FinOps, GitOps, MlOps, vb.  Ama dikkat ederseniz geriye kalan koku her zaman Ops'tur. İşin komik yanı, her yaklaşımın denklemlerin Ops'larını ortadan kaldırmayı amaçlamasıdır. Operasyonlar, diğer adıyla "sisteme giriş yapan ve sistemin çalışması için şeyler yapan adam(lar).  TL;DR  DevOps'un çözmek için yola çıktığı asıl sorun, bulut altyapısının yükselişi nedeniyle artık mevcut olmayabilir. Ancak DevOps, sürekli teslimat gibi önemli bir fikri doğurdu ve yazılım mühendisliğinde bir kültür değişikliği getirdi.  "DevOps" terimi moda bir sözcük olarak kullanılmış olsa da DevSecOps, FinOps ve GitOps gibi hepsi geleneksel Ops görevlerine olan ihtiyacı ortadan kaldırmayı amaçlayan yeni yaklaşımların geliştirilmesine yol açtı.  Sonuçta DevOps ve bulut altyapısının manzarası sürekli olarak gelişiyor ve güncel kalmak ve doğru araçları seçmek zor. İronik bir şekilde, DevOps başlangıçta Dev ve Ops arasındaki işbirliği anlamına geliyordu, ancak şimdi Ops'u denklemin dışında bırakmaya doğru kaydı.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

This piece was written for humor or satire and may include nonfactual statements, stories, or anecdotes.

Read My Stories

Bu ses hikayenin orijinal dilinde üretilmiştir!

DevOps Paradoksu: Operasyonlardan Uzaklaşmaya Geçiş

About Author

YORUMLAR

ETİKETLERİ ASIN

BU YAZI

Related Stories

HackerNoon Yazma Yarışmasını mı Kazanmak İstiyorsunuz? İşte #crypto-api Yarışması Kazananlarının Önerileri

Benzersiz Bir Ekosistemi Güçlendiren Bitcoin UTXO Modeli

Kazanmak için Dokun: Telegram, Solana'dan Önce Sonraki 10 Milyar Kripto Kullanıcısına Katılabilir

Yapay Zekanın Gücünü Ortaya Çıkarıyoruz. En Son Tekniklerin Sistematik Bir İncelemesi: Özet ve Giriş

HackerNoon Yazma Yarışmasını mı Kazanmak İstiyorsunuz? İşte #crypto-api Yarışması Kazananlarının Önerileri

Benzersiz Bir Ekosistemi Güçlendiren Bitcoin UTXO Modeli

Kazanmak için Dokun: Telegram, Solana'dan Önce Sonraki 10 Milyar Kripto Kullanıcısına Katılabilir

Yapay Zekanın Gücünü Ortaya Çıkarıyoruz. En Son Tekniklerin Sistematik Bir İncelemesi: Özet ve Giriş

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps