DevOps İçin Bir Ağıt

DevOps'un kavramı ve tarihi

• DevOps, yaklaşık 2007'de ortaya çıkan bir kavramdı ve donanımı yönetenlerle yazılım yazanlar arasındaki ayrımı ortadan kaldırmayı hedefliyordu
• Başlangıçta, kod dağıtımının güvenliğini artırmak için NASA'nın prosedürleri ve fikirleri örnek alınıyordu
• O dönemde yazılım dağıtım süreci şu şekildeydi:
  • geliştirme ekibi sunucu yazılımı için bir sürüm hazırlıyor, QA ekibi bunu test ediyor ve ardından müşteriye dağıtıyordu
  • operasyon ekibi, yazılım değişiklikleri ve sorun çıktığında nasıl müdahale edileceği dahil bir playbook alıyordu
  • veri merkezi içinde güncellemeler kademeli olarak rollout ediliyor ve izleniyordu
  • dağıtım günü belirleniyor ve dağıtımdan sonra izleme yapılıyordu

DevOps'un sorunları

• DevOps çok emek yoğun bir yaklaşımdı
• geliştirme ekibi, QA ekibi, teknik yazarlar ve operasyon ekibi arasında iş birliği gerekiyordu
• özellik dağıtımı yavaştı ve önemli güncellemeler önceliklendiriliyordu
• birçok kuruluşun DevOps'u benimsemesinin nedenleri şunlardı:
  • teknik personelin kolayca ikame edilememesi
  • işe alımın zor ve maliyetli olması
  • SaaS sağlayıcılarının karmaşıklığı azaltması
  • bulut platformlarının avantajlarının öne çıkarılması
  • geliştiricilerin küçük değişikliklerin dağıtıma çıkmasının uzun sürmesinden rahatsız olması

DevOps'un gerçekte nasıl göründüğü

• DevOps, geliştirme ve operasyon ekiplerinin tek bir ekipte birleşmesini hedefliyordu
• QA ekibi işten çıkarıldı ve hızlı dağıtım ile geri bildirim sayesinde dahili test süresi kısaldı
• DevOps bazen Google'ın SRE yaklaşımıyla karıştırılsa da SRE daha yapısal ve daha katı bir yaklaşıma sahiptir
• DevOps'un pratikteki süreci genelde şöyleydi:
  • geliştirici git üzerinde bir branch oluşturup özellik ekler
  • bir PR açılır, ekip arkadaşları inceleme yaptıktan sonra main'e merge edilir
  • CI/CD sistemi build sürecini başlatır ve container'ı registry'ye push eder
  • CD sistemi sunuculara yeni sürümü bildirir ve dağıtımın başarılı olup olmadığını izler
  • release-aware metriklerle dağıtımdan sonraki değişiklikler izlenir

DevOps'un başarısızlık nedenleri

• geliştiriciler yerel ortamda test yapıp Linux sunucularına dağıtım yaptığında küçük farklılıklar ortaya çıkıyordu
• operasyon ekibi dağıtımı izlemediğinde sorun çözmek zorlaşıyordu
• geliştiricilerin sistem işletimine dair bilgisi yetersizdi
• container'ların benimsenmesi bazı sorunları çözse de operasyonel karmaşıklık hâlâ sürüyordu

Container'ların gelişi ve sınırları

• Container'lar, "benim bilgisayarımda çalışıyordu" sorununu çözdü
• Linux sunucularının yapı bileşenlerini basitleştirdi
• Ancak hâlâ kalan sorunlar vardı
  • Operate: altyapı bakımı, yükseltmeler vb. için uzmanlık gereksinimi
  • Observe: karmaşık izleme sistemlerini kurma ve yönetme zorluğu
  • Sürekli geri bildirim: dahili geri bildirimlerin işlenmesindeki yetersizlik
  • Discover: ekipler arasında bilgi paylaşımının yetersizliği
  • Plan: merkezi planlama yapmanın zorluğu

Platform Engineering'in ortaya çıkışı

• Platform Engineering, DevOps'un ardından gelen bir kavram olarak, geliştirme ekiplerinin platform işletimini anlayıp sorun çözmesi yerine bunun platform ekibi tarafından üstlenilmesini öngörür
• Bu yaklaşım, geliştirme ekipleri ile platform operasyonunun sorumluluklarını daha net ayırarak rol paylaşımını açıklığa kavuşturur, ancak yine de çok sayıda teknik beceri gerektirir
• Hem geliştiriciler hem de operasyon ekipleri daha fazla iş yapmak zorundadır

Sonuç

• Altyapı alanında basit ve platforma bağımlı olmayan araçlar arama eğilimi artıyor
• birçok kuruluş Kubernetes gibi karmaşık teknolojilerden vazgeçip daha basit iş akışlarına geri dönüyor
• Platform Engineering her derde deva bir çözüm değil; kuruluşların gerçekten neye ihtiyaç duyduğunu ve neyin gereksiz olduğunu ayırt etmesi gerekiyor
• DevOps yaklaşımının avantajlarını korurken sadeleşme ve kararlılığa odaklanmak gerekiyor

GN⁺ görüşü

1. DevOps'un evrimi ve bugünkü durumu, teknoloji sektöründeki trend değişimlerini iyi gösteren bir örnek. Başlangıçtaki ideal hedeflerle gerçeklik arasındaki farkın kabul edilip daha pratik yaklaşımların aranması ilgi çekici

2. Platform Engineering'e geçiş, DevOps'un sınırlarını kabul edip yeni çözümler arama girişimi gibi görünüyor. Ancak bu da kusursuz bir çözüm değil; kuruluşun ölçeğine ve özelliklerine uygun özelleştirilmiş bir yaklaşım gerekecek

3. Cloud-native teknolojiler ve mikroservis mimarisinin karmaşıklığı arttıkça sadelik ve kararlılık yeniden değerlendiriliyor. Bu da teknoloji seçimlerinde iş değeri ile operasyonel verimliliğin daha önemli dikkate alınması gerektiğini gösteriyor

4. DevOps ve platform engineering'deki değişim, yazılım geliştirme ve operasyon alanlarında sürekli öğrenme ve uyum sağlamanın önemini vurguluyor. Teknik uzmanların yalnızca yeni araç ve yöntemleri öğrenmesi değil, iş gereksinimleri ile teknik karmaşıklık arasında denge kurma becerisini de geliştirmesi gerekecek

5. Gelecekte yazılım geliştirme ve operasyon yöntemlerinin daha esnek ve bağlama uygun yaklaşımlar benimsemesi bekleniyor. Büyük ölçekli kuruluşlar ile küçük startup'ların aynı yöntemi izlemesi yerine, her birinin kendi durumuna uygun en iyi süreç ve araçları seçtiği eğilim güçlenecek

[kaydash]

Oldukça sık
yöneticiler
sadece DevOps kavramını benimserlerse
çaba harcamadan büyük bir dönüşümün ortaya çıkacağını
bekleyen (büyük ya da küçük şirket fark etmeksizin)
eski kafalı şirketlerin yanlış düşüncesi

[GN⁺]

Hacker News görüşü

• asıl mesele, "devops cycle" diyagramında "build, test, deploy" kısmına odaklanmak

  • odak hızdaydı; mühendislik mükemmeliyeti ise hesaba katılmadı
  • operasyon ekipleri işten çıkarıldı ve QA yeniden yapılandırıldı
  • tüm ekiplerin bir on-call rotası oldu
  • kısa vadeli kazanç uğruna sisteme kaotik değişiklikler yapıldı
  • birkaç ay sonra her değişiklikte sorun çıkmaya başladı
  • devops araçları faydalıydı ama pahalı ve sinir bozucuydu
  • yeni geliştiriciler devops bilmiyor ama container biliyor

• bu, devops ekiplerinin yaşadığı sorunlara dayanan bir görüş

  • yeni servisler ekleyebilmeli ve altyapıyı güvenli şekilde yönetebilmelisiniz
  • devops standart haline geldi; manuel sistem yöneticisi işleri artık gerekmiyor

• Kubernetes eleştirisi yanlış

  • Kubernetes, mükemmel yazılım mühendisliğine iyi bir örnek; iyi destekleniyor ve her yerde çalışıyor
  • rastgele bash script'leri kullanmak yerine Kubernetes öğrenmek daha iyi

• devops, yazılım dağıtımını kolaylaştırmak için engelleri kaldırmakla ilgilidir

  • günlük deployment, daha yüksek kaliteli kodun dağıtılmasına yardımcı olur
  • yalnızca kod hazır olduğunda deployment yapabilme seçeneği önemlidir
  • aylık release'ler baskı yaratır ve verimsiz seçimlere yol açabilir

• devops bir metodoloji değil, bir felsefedir

  • amaç, operasyonu SDLC'ye entegre etmektir
  • cloud bunu daha kolay hale getirdi
  • "DevOps" ekiplerinin ortaya çıkması, asıl felsefeyi çarpıttı

• liderliğin "silo'ları yıkma" yaklaşımı neredeyse göstermelik

  • sorumluluk olmadan verilen yetki etkili olmaz
  • en iyi devops yetenekleri, kendilerini kodla ikame etmekten keyif alır
  • devops araçları olgunlaşmış ve iyi belgelenmiştir
  • Kubernetes öğrenmeyen bir geliştirici, Linux komutlarını bilmeyen bir geliştirici gibidir

• kullanıcılar testçi olabiliyorsa öyle olmalı

  • ortada sadece ekonomik bir mesele var
  • müşteriniz çoksa kullanıcıların test etmesine izin verin, azsa testi kendiniz yapmalısınız

• platform ekipleri yalnızca büyük şirketlerde mümkün

  • KOBİ'ler, devops personeli eksikliği nedeniyle stres ve risk üstlenmek zorunda kalıyor
  • platform ekibinin yokluğu birçok soruna yol açıyor

• devops bir metodoloji değil, bir felsefedir

  • silo ekiplerdeki deneyim, devops ihtiyacını kanıtlıyor
  • devops, ekiplerin projeyi bütünüyle anlayıp dağıtabilmesini sağlar

• devops iyi niyetlerle ortaya çıktı

  • hızlı geri bildirim döngüleri geliştirme hızı için önemlidir
  • organizasyon ve ürüne en uygun çözümü bulmak gerekir