BLOG
Bir Dönüşüm Hikayesi
Yayınlanma Tarihi
Ocak 19, 2024
Paylaş
Devops yakın tarihimizin yazılım dünyasında önemli bir mihenk taşı olarak yerini almıştır. Geliştirme ve Operasyonlar anlamına gelen Development (Dev) ve Operations (Ops) kelimelerinin kısaltmasından oluşan DevOps’un hala bir teknoloji mi yoksa metodoloji mi olduğuna dair tartışmalar tazeliğini koruyor. Yazılım dünyasına bu kadar sirayet etmiş bir kavram hala net olarak tanımlanmakta güçlük çekiliyor. Devops’un ne olduğuna dair gizem aslında bir taraftan da onun gündemde olmasına ve zinde kalmasına katkı sağlamaktadır. Dolayısıyla bu kavram üzerinde yaklaşımlar, arayışlar ve araştırmalar dinamizmini kaybedecek gibi değil. Bazılarına göre Devops bir teknoloji, bazılarına göre araçlar topluluğu, bazılarına göre de yaklaşım olarak değerlendiriliyor. Kavramsal arayışları bir kenara bırakırsak aslında Devops geliştirme sürecini hızlandırmaya yönelik araçların ve yöntemlerin birleşimidir diyebiliriz.
Peki Devops yokken hayat nasıldı?
2000’lerin başına kadar işler şöyle yürüyordu. Bir geliştirici uygulamasını çalıştırmak için kapı kapı dolaşıp bir sistem yöneticisi bulmaya çalışırdı. Sistem yöneticisinden uygulama için ihtiyaç duyduğu kaynakları talep ederdi. Tabii bu ikili arasındaki konuşma çoğu zaman iki tarafın da bilmediği bir dilde gerçekleşirdi. Günün sonunda geliştiriciler kaderine razı bir şekilde karşılanan taleplerine iyi kötü demeden sebat ederdi. Yani geliştiriciler uygulamalarının kurumlarına kadar giden operasyondan da sorumlulardı. Uygulamanın geliştirilmesinden kurulumuna giden bu çileli yol birçok uyumsuzluk ve yoksunluktan dolayı oldukça çetrefilliydi. Ancak bu işleyiş sektörde hızla değişen teknolojilere yenik düştü. Bulut sistemlerinin yani “as-a-service” yapılarının ortaya çıkması, monolitik mimarilerden mikro servislere dönüşüm, ortamların çeşitliliğinin (dev, test, qa, uat, pre-prod, prod…vb) ve iş sürekliliği, felaket kurtarma ve yedeklilik ihtiyaçlarının artması gibi evrimsel gelişmeler nedeniyle mevcut akış yanıt veremez duruma geldi. Dolayısıyla acı dolu bu kurulum ve geçiş süreci geliştime ve operasyonun ayrılmasına evrildi. Böylece geliştiriciler artık OPS cenahında olmayacak fakat uçtan uca uygulamalarının süreçlerini yönetebileceklerdi. Bu durum kurumların işleyişine göre çok farklı modeller olarak ortaya çıktı.
Birinci Model
Bu modelde OPS ekibi ağırlıklı olarak sistem uzmanlarından oluşmaktadır. Yani OPS süreci sistem ekiplerine aktarılmıştır. Böylece DEV ve OPS işleyişi ayrılmıştır. Bu durumda DEV ekipleri ile OPS ekipleri arasında iletişim ve birliktelik sorunu hala devam etmiştir.
İkinci Model
Bu modelde DEV ve OPS ekipleri ayrılmıştır. Birinci modelden farklı olarak OPS ekibi geliştiricilerden oluşmaktadır. Yani OPS süreci geliştiricilere aktarılmıştır. Ancak bu durumda kurulum ve geçişler için yeterli deneyime sahip olmayan geliştiriciler ciddi sorunlar yaşamaktadır. Canlı ortam sorunlarında büyük oranda artış görmektedir.
Üçüncü Model
Bu modelde Devops bir araç seti olarak görülmektedir. Devops ekibi genellikle orta katman uzmanlarından oluşmaktadır. Bu durumda Devops’un çıkış felsefesi olan DEV ve OPS sürecinin ayrılması sağlanmış olsa da bu iki ekip arasında izolasyon ortaya çıkmıştır.
En yaygın Devops pratikleri olarak görülen bu üç modelin dışında OPS as-a-service, temp OPS, DEV+OPS ve SRE gibi farklı Devops modelleri de söz konusudur.
Tabii ki her kurum için uygun olan bir Devops modeli mümkün değildir. Çünkü kurumların işleyişleri, süreçleri ve politikaları kendine özgüdür ve en iyi pratik uygulaması da buna göre değişkenlik göstermektedir. Bu nedenle bir Devops modeli bir kurum için oldukça başarılı olsa da aynı model başka bir kurumda başarısız olabilir.
Farklı Devops işleyişlerinin ortaya çıkması Conway yasası tarafından anlaşılır bir şekilde açıklanabilir. Melvin Conway kurgulanan sistemlerin ekiplerin örgütsel iletişim yansımaları olduğu fikrini ortaya atmıştır. Buna göre organizasyon içinde iletişimin nasıl kurulması ile elde edilen çıktılar veya ürünler arasında bir ilişki vardır. Yani iletişim ve kolektif beceriler sadece toplantılar ile sınırlı olmayıp geliştirilen uygulamalara kadar sirayet etmektedir.
“Bir derleyici üzerinde çalışan dört ekibiniz varsa, dört geçişli bir derleyici elde edersiniz.” • Eric S. Raymond
Devops’un çıkış öyküsü ‘you build it, you run it’ yani Ops bileşenin kaldırılması aslında birçok kurum tarafından sağlıklı bir şekilde sağlanamamıştır. Buradaki en büyük sorun süreç içerisinde sorumlulukların en deneyimli geliştiricilere verilmesidir. Bu da organizasyonlar için en maliyetli ve katkısı yüksek kaynakların ziyan edilmesine sebep olmaktadır.
Peki Ops süreci self-service bir yapıda olsaydı durum nasıl olurdu? Yani düşünün ki kod dışındaki her türlü çevresel bileşenden münezzeh evrensel bir platforma sahip olsaydık. Yani uygulamanın hangi ortamda çalışacağının değerlendirilmesi, kullanılacak araçlara hakim olma veya altyapısal konfigürasyonlar gibi gerekliliklerin olmadığı bir platformdan bahsediyoruz.
Geliştirme sürecinde farklı ekipler farklı araçlara, çerçevelere veya yazılım dillerine sahiptir. Dolayısıyla bu çeşitlilik geliştiriciler için öğrenilmesi ve kullanım alışkanlığı edinilmesi gereken bir çabadır. Bunun neticesinde geliştiriciler asıl odaklanılması gereken geliştirmeye yeterli vakti bulmakta zorluk çekmektedirler. İşte böyle bir platform marifetiyle geliştiricilerin sadece koda odaklanması beklenmektedir. Dahili Geliştirici Platformu (IDP) olarak adlandırılan bu yapı geliştiricilere kodun testten kuruluma kadar ihtiyaç duydukları her kaynağı sağlayan self-service bir sistemdir. Birçok teknoloji ve aracın entegrasyonu ile bu yapıyı kuran ve işletenler de Platform Mühendisi olarak ifade edilmektedir.
Platform mühendisliği, geliştiricilerin SDLC’nin operasyonlarını uçtan uca otonom bir şekilde yapılabilmesine imkan sağlayan bir süreçtir. Platform mühendisleri geliştiricilerin uygulamalarını hızlı ve etkin bir şekilde üretim ortamına taşımaları için ihtiyaç duyulan araç ve iş akışlarını oluşturur ve işletir. Geliştiriciler ve altyapı arasında bir katman olarak yer alırlar ve altyapı sorunlarının geliştiricilere yansımasının önüne geçerler.
Platform mühendisleri Devops’un felsefesi olan ‘you built it, you run it’ yaklaşımının yani geliştiricilerin payesindeki Ops sürecinin ortadan kaldırılmasının en iyi pratiğini uygulamayı hedeflemektedir. Dolayısıyla geliştiricilerden maksimum fayda sağlayarak daha iyi bir uygulama geliştirme ve bu uygulamanın hızlı bir şekilde canlı ortama alınması idealine ulaşılmış olunacaktır.
Kim bilir belki de Platform Mühendisleri geliştiricilerin “Golden Path”ini inşa edecekler ve Devops’un teknolojideki doğal sınırlarına ulaşacaklardır.
Referanslar:
https://platformengineering.org/