Yazılımda Üç Silahşörler: Platform Engineering/DevOps/SRE
Kasvetli bir İstanbul gününden merhabalar sevgili okuyucu, bu yazımda özellikle 2020 yılı itibariyle dünyada oldukça popülerleşmeye başlayan ve bununla beraber de yeni kavram karmaşalarının yanında geldiği bazı pozisyonların hikayelerini, tanımlarını ve sorumluluklarını açıklamaya çalışacağım.
Yazıda ele aldığım başlıklar şöyle:
DevOps
— Geçmişe Bir Bakış
— Kültür Oluşumu
— Bir Pozisyon Olarak DevOps
— Metriklerle DevOps
SRE
— Site Reliability Yapı Taşları
— Zaman Yönetimi
— DevOps ile İlişkisi
— Kısaltmalar Üçlüsü: SLI,SLO,SLA
Platform Engineering
— Nedir Bu IDP?
— Ürünler
Araç Gereçler
Özet
Kaynakça
Yazılım geliştirme denilince çoğu zaman akla en yaygın olan backend, frontend, mobil geliştirici pozisyonları gelir. Oysa ki bunların yanında farklı alanlara ilgisi ve yeteneği olan kişiler için göz önünde bulundurulması gereken bazı pozisyonlar bulunuyor.
İnsanlara kariyer tavsiyesi verirken sadece tek bir alana ve pozisyona yöneltmek o alanda rekabetin artmasına dolayısıyla daha zor iş bulunmasına, aynı zamanda diğer alanlarda kalifiye çalışan bulmanın zorlaşmasına sebep oluyor.
Oysa ki yazılım alanındaki her pozisyon ayrı ayrı değerli.
Birazdan hakkında konuşacağımız pozisyonları/terimleri tanımlarken özellikle güncel literatürden, olayların tarihsel işleyişinden, bu terimlerin çıkış noktası kişiler ve kitaplardan ve son olarak yıllar içerisindeki tecrübelerimden istifade edeceğim. Uzun süredir Platform Engineering/SRE/DevOps konularında tecrübe etmiş birisi olarak bu konuda birkaç kelam etme tasarrufunda bulunuyorum.
Sözü fazla uzatmadan yazılımda üç silahşör diye adlandırdığım, birbirleri ile yakın iletişimde bulunan, son yılların popüler konu ve pozisyonlarından olan DevOps, Site Reliability Engineering ve Platform Engineering pozisyonlarını inceleyelim.
Unutmamak gerekir ki bu pozisyonlar birbirinin alternatifi veya rakibi değil, birbirini tamamlayan farklı sorumluluk alanları bulunan pozisyonlardır.
DevOps
Geçmişe Bir Bakış
DevOps rolünün (aslında doğrudan bir pozisyon olmasından ziyade bir yaklaşım, felsefe diyebiliriz) nasıl ortaya çıktığını anlamak için biraz geriye gitmemiz gerekiyor. Bundan 15–20 yıl önceye gittiğimizde karşımıza bir başka pozisyon olan Sysadmin çıkıyor.
System admin pozisyonundaki kişiler sistemin çalışması için gerekli yazılımsal parçaları bir araya getirip sistemin ayakta kalmasını sağlıyorlardı. Özellikle işletim sistemleriyle haşır neşir çalışıp, konfigürasyonlar, güncellemeler, paket dağıtımları, erişim ve yetkilendirmelerin ayarlanması gibi birçok konuya bakıyorlardı.
Yazılımcılar uygulamalar geliştirip bunu sisteme bırakıyor ve çalışmasını ümit ediyordu. Birbirinden farklı ihtiyaçları olan uygulamaları sistemcilerin çözmesi ve doğru şekilde yayınlaması zorlaşıyordu.
Çünkü geliştirme ile operasyon işlemlerinin birbirinden ayrık olması beraberinde iletişimsel problemler, yavaş yazılım teslim döngüsü ve olumsuz süreçler getiriyordu.
Kültür Oluşumu
Gereksinimler, kullanıcı yükü, veri boyutu, geliştirilen uygulama sayısı arttıkça şirketler yazılım ekiplerini geliştirme (development) ve operasyon (ops) süreçlerini birbirine yakınlaştırma ihtiyacı duydu.
İşte tam da bu noktada DevOps dediğimiz terim devreye girdi.
DevOps bridges the gap between development and operations by promoting a culture of collaboration, shared responsibilities, and continuous feedback using automation throughout the software development life cycle.
— Modern DevOps Practices
Kitapta da bahsettiği üzere DevOps, SDLC (Software Development Life Cycle) dediğimiz yazılım geliştirme yaşam döngüsü boyunca geliştirme ve operasyon süreçleri arasındaki boşluğu, iletişim kültürü, geri bildirim ve otomasyon ile kapatmayı sağladı.
Kendi tanımım olarak, DevOps rolünü tek kelime ile açıklamam gerekirse buna “otomasyon” derdim.
DevOps devreye, “bir uygulama yazdım, şimdi ne yapmam gerekiyor?” sorusuyla beraber giriyor. Uygulamanın yayınlanma süreciyle ilgili tüm otomasyonlar DevOps konusudur diyebiliriz.
👉 Uygulamaların çalışacağı ortamların kurulması ve hazırlanması, bunların otomatik oluşturulması, “Infrastructure as Code” mekanizmalarının kurulması ve çalıştırılması. Kubernetes, ArgoCD gibi platformların otomatik olarak kurulması, ölçeklenmesi, güncellenmesi vs vs…
👉 Uygulamaların canlı sisteme otomatik bir şekilde aktarılması, CI/CD ile deployment otomasyonu. İlgili pipeline altyapısının ve scriptlerin hazırlanması, bunların otomatik oluşması ve çalıştırılması.
Ve bunlara benzer sayabileceğimiz birçok konu DevOps alanına giriyor.
Konunun başında DevOps için bir pozisyondan ziyade yaklaşım demiştik, aynı “Software Architect” şeklinde bir pozisyon olmaması gerektiği gibi. Yazılım mimarisi, her yazılımcının sahip olması gereken bir yetenektir. Bu yeteneği gelişmiş olan kişiler doğru ve sağlıklı mimariler oluştururlar. DevOps da günümüzde geliştirme yapan herkesin sahip olması gereken bir yetenektir.
“Cross-functional team” yani çok fonksiyonlu ekipler dediğimiz, otonom yani kendi kendine hareket edebilen ekiplerin oluşturulması için ekipte çapraz disiplinlerde yetkinlik sahibi kişiler olması gerekmektedir.
Bir Pozisyon Olarak DevOps
Peki DevOps pozisyonu ne yapar? Madem bu bir kültür ve süreç, neden böyle bir pozisyon var, dediğinizi duyar gibim. Buraya da bir açıklık getirmek gerekir.
Her ekip ihtiyacı olan altyapısal ürünleri tekrar tekrar kendi başına kursa, her uygulama için en baştan pipeline ve diğer gereksinimleri geliştirse, sıfırdan monitoring ve diğer süreçleri oluştursa sanırım ne şirket açısından ne de geliştirici ekipler açısından efektif olmazdı.
Buradaki ihtiyacı gidermesi için geliştirici ekipleriyle senkronize çalışacak, onların SDLC süreçlerindeki ihtiyaçlarını otonom bir şekilde çözecek, gerekli ürünlerin kurulum, güncelleme, yönetimsel sorumluluklarını alacak kişilere ihtiyaç var. İşte DevOps ekipleri tam olarak o kişilerden oluşuyor.
Bu sorumluğu alan ekiplerin ismi şirketten şirkete değişkenlik gösterebilir. Bu noktada DevOps terimini bir “interface” olarak görebiliriz.
DevOps’un tanımına dair “Fundamentals of DevOps and Software Delivery” kitabından bir alıntı 👇
Metriklerle DevOps
Mühendisliğin ve yazılım geliştirmenin olmazsa olmazlarından birisi de ölçümleme yapmaktır. İzleyip ölçmediğimiz bir şeyi iyileştiremeyiz, durumu hakkında bilgi sahibi olamayız.
DevOps, DORA (DevOps Research and Assessment) dediğimiz 4 ana başlıkta bazı terimler ortaya koyar.
Deployment Frequency
Canlı ortama ne kadar sıklıkla yeni versiyon gönderildiği
Lead Time for Changes
Bir değişikliğin canlı ortama alınma süresi
Change Failure Rate
Yapılan değişikliklerin canlı ortamda hataya sebep olma oranı
Time to Restore Service
Bir hatadan stabil duruma geçme zamanı
SRE - (Site Reliability Engineering)
SRE Google’da ortaya çıkan bir pozisyon. Bu pozisyonu açıklamak için terimin fikir babası sayılan kişinin tanımına yer vermezsek olmaz:
SRE is what happens when you ask a software engineer to design an operations team.
— Benjamin Treynor Sloss
SRE, bir yazılım geliştiriciye operasyonel süreçleri işletecek ekibi tasarlaması istenildiğinde ortaya çıkan şeydir.
Site Reliability Engineering pozisyonundaki kişiler yazılım geliştirici tabanlı olup bunun yanında ek olarak güçlü bir sistem/network bilgisine sahiptirler.
Bu mesele Google SRE kitabında şu şekilde ifade ediliyor:
50–60% are Google Software Engineers, or more precisely, people who have been hired via the standard procedure for Google Software Engineers. The other 40–50% are candidates who were very close to the Google Software Engineering qualifications (i.e., 85–99% of the skill set required), and who in addition had a set of technical skills that is useful to SRE but is rare for most software engineers. By far, UNIX system internals and networking (Layer 1 to Layer 3) expertise are the two most common types of alternate technical skills we seek.
Site Reliability Yapı Taşları
SRE yapı taşları olarak geçen konu başlıkları şu şekildedir:
- Monitoring/Observability/Logging/Alerting
- Emergency Response
- Change Management
- Capaticy Planning
- Chaos Engineering
SRE ekipleri sistemlerin sağlıklı, hizmet verebilir, performanslı ve gözlemlenebilir olması üzerine çalışır. Sistem genelinde bir hata olduğunda ilk müdahale eden ekiplerin başında gelir.
Incident Management ve on-call süreçlerini yönetir aynı zamanda tüm bu sorumluluklar için gerekli geliştirmeleri yapar.
Change Management süreçlerinde aktif rol alır, sistemin stabil kalması değişikliklerin peyderpey ve sağlıklı yapılması için sürecin takibini yapar.
Chaos Testing ve Capacity Planning gibi süreçleri ilerletir, sistem kaynaklarını verimli kullanma ve herhangi bir hata durumunda nerelerin etkilenip nasıl bunlardan kaçınılacağı hakkında çalışmalar yapar.
Kısaltmalar Üçlüsü: SLI,SLO,SLA
SRE denildiğinde ilk akla gelen de sistemlerin performansını ve sağlığını doğru ölçümlemek için gerekli terimler olan SLI, SLO ve SLA’dir.
SLA: Service Level Agreements
Şirketlerin müşterilerine karşı verdiği söz, örneğin sistemin %99 erişilebilir olması
SLO: Service Level Objectives
Verdiğiniz sözleri tutabilmek için metriklerinize koyduğunuz hedefler
SLI: Service Level Indicators
Ölçümleme yapacağımız metrik, örneğin anlık istek sayısı (RPS), cevaplama süresi (response time)
Bunları yapabilmek için monitoring altyapısını kullanır (yoksa oluşturur) ve sürekli iyileştirmeye uğraşır. Herhangi bir anomali durumunda alarmlar ile hem SRE ekipleri hem de ilgili ekipler uyarıya geçirilir.
Zaman Yönetimi
Buraya kadar olan açıklamalara bakıldığında SRE hem yazılım geliştirme hem de operasyonel süreçleri işletme sorumluluklarına sahip.
- Peki bunlar arasındaki ağırlığı hangisine vermeli?
- Bir SRE zamanını nasıl yönetmeli?
Bu sorunun cevabı SRE kitabında yer alıyor 👇
Google places a 50% cap on the aggregate “ops” work for all SREs — tickets, on-call, manual tasks, etc.
Google’s rule of thumb is that an SRE team must spend the remaining 50% of its time actually doing development.
Kısaca söyleyebiliriz ki zamanını operasyonel süreçler ve yazılım geliştirme şeklinde yarı yarıya planlamalıdır.
DevOps ile İlişkisi
Bu iki terim oldukça karşı karşıya gelebiliyor. En başında DevOps için bir pozisyondan ziyade kültürel bir dönüşüm, paradigmalar olduğunu vurgulamamın sebebi de bundan kaynaklı.
Biri var ise diğeri olmamalı veya bu varken diğerine ne gerek var gibi bir durum söz konusu değil. Aksine, DevOps pratikler bütünü, SRE de bunu sistem genelinde reliability konularında uygulayan ekiplerden bir tanesi. Bir şirkette farklı konularla alakalı DevOps ekipleri bulunabilir (örneğin Kubernetes yönetimi için farklı, CI/CD ürünlerinin yönetimi için farklı ekipler olabilir) hepsi de DevOps paradigmalarını kendi odaklandıkları konular için sürdürebilir.
DevOps paradigmaları, bir şirkette farklı ekipler tarafından uygulanan bir “interface” olarak görülmelidir.
Konuyla ilgili Reddit’te yer alan bir konuşmayı buraya bırakıyorum 👇
Hem SRE konularında bilgi sahibi olmak hem de sağlıklı sistemler çalıştırmak için çeşitli konular barındıran Google SRE kitaplarına bakmanızı mutlaka öneriyorum.
Platform Engineering
Üç silahşörler arasında son yıllarda hakkında en çok konuşulan, makaleler yazılan pozisyon ise Platform Engineering.
Platform Engineering özellikle yazılım ekiplerinin büyümesi, yazılımsal ihtiyaçların artması, kullanılan araç gereçlerin sayısının ve karmaşasının artması ile hayatımıza giren bir kavram. Developer Experience alanı ile yakın temasta bulunan ve hem yazılımcılar için ortak bir deneyim sunmaya hem de şirketin hızlı hareket edebilmesi için altyapı oluşturmaya çalışan bir pozisyondur.
Nedir Bu IDP (Internal Developer Portal/Platform)
IDP, yazılım geliştiricileri araç gereç ve altyapı karmaşasından kurtarmaya çalışmak, tek bir yerden uygulama geliştirme ve yaşam döngüsün kontrol etmeyi hedeflemek için ortaya çıkan ürünlerdir.
Yazılımcıların görseldeki kişi gibi yanmasını (burnout) engellemek, sürekli konular arasındaki geçişi (context-switch) ve bilişsel yükü (cognitive-load) azaltmak hedefler arasındadır.
Birden fazla cloud ortamında çalışan bir şirket düşünün, tüm yazılımcıların farklı cloud özelliklerini öğrenmesi, uygulamalarını buna göre geliştirmesi ve yeniliklere adapte etmesi gerekir. Bu hem yazılımcılar açısından külfet hem de şirket açısından maliyet demektir.
Bu gibi sorunları Platform Engineering ekipleri arka planı soyutlayarak ortak bir deneyim sunan ve tek yerden yönetilebilir bir portal geliştirip yazılımcıların kullanımına verebilir. İşte bu tarz uygulamalar IDP olarak geçer.
Ürünler
Bu alanda yer alan bazı ürünlere örnek vermek gerekirse ilk akla gelenlerden Port ve Backstage söylenebilir.
Kendi içerisinde ihtiyaç duyulan tüm yazılım süreçlerini ve dokümantasyonları barındıran, özelleştirilebilir, farklı araç gereçlerle entegre edilebilir yapısı olan bu iki ürün sıfırdan kurulacak bir platform dönüşümü için göz önünde bulundurulması gerekenlerden.
Anlaşılacağı üzere Platform Engineering ekipleri de oldukça yoğun bir yazılım geliştirme sürecine sahip, aynı zamanda CNCF dünyası ve birçok cloud teknolojisi üzerinde de tecrübe gerektiren bir alan.
Araç Gereçler
Kullanılacak tüm araç gereçleri burada listelemektense yazının sonuna GitHub üzerinde yer alan “awesome” kaynaklarını koymaya karar verdim. Hemen hemen tamamında benzer ürünler yer alsa da çok güzel makaleler ve konseptleri de bulabileceğinizi düşünüyorum.
Listede yer alan bazı ürünleri kullanmak, alet çantanıza ve şirketinize katmak isteyeceğinize eminim 👇
Kaynakça
Özet
Tüm bu kavramları tek cümleye sığdırmak her ne kadar zor olsa da toparlamaya çalışacak olursak;
- DevOps geliştirme ve operasyon süreçlerine kültürel paradigmalar getirerek uygulama yayınlama sürecinde ihtiyaç duyulan otomasyonu her alanda sağlamak için yapılacak işlerin tümüdür.
- SRE, DevOps pratikleriyle yazılım geliştirme ve operasyonel işlemler yaparak sistemin tamamının güvenilir, stabil bir şekilde çalışmasını sağlayan pozisyondur.
- Platform Engineering ise yazılımcıların kullanacağı ürün ve platformlar geliştirip yazılımcı deneyimini iyileştirmek için geliştirmeler yapan pozisyondur.
ByteByteGo sitesinde bu konuyu özetleyen güzel bir görsel ekliyorum 👇
Umarım bu yazı sizler için bu üç pozisyonun görev ve sorumlulukları konusunda bir netlik sağlamıştır. Bir sonraki yazıya kadar sağlıcakla kalın, kodunuz performanslı, sistemleriniz stabil olsun :)
