Platform mühendisliği nedir? Ekipler için pratik rehber
Summary
Platform mühendisliği, geliştiricilerin ortam, pipeline, servis ve dokümantasyona self-servis erişebildiği iç bir platformu kurup işletmektir. Platform ekibi bu platformu bir ürün gibi yönetir ve geliştiricileri müşteri olarak görür. Hedef daha az bekleme ve daha az ticket. Yaklaşık 30 mühendisten küçük ekiplerde tam zamanlı bir platform ekibi genellikle gereksizdir; en küçük kullanışlı platformla başlayın.
Platform mühendisliği, geliştiricilere kendi kendine hizmet alma imkânı veren bir iç platformu kurup işletme pratiğidir. Bu platform; ortamları, pipeline'ları, servisleri, dokümantasyonu ve güvenlik kurallarını kapsar. Platform mühendisliği nedir pratikte? Küçük bir ekip, "bir fikrim var" ile "production'da çalışıyor" arasındaki yolu bir ürün gibi ele alır ve geliştiriciler bu ürünün müşterileridir. Hedef; daha az bekleme, daha az ticket ve öğrenilmesi gereken daha az araçtır.
Muhtemelen bu sorunu zaten yaşadınız. Yeni bir servis için bir repo, bir pipeline, bir veritabanı, secret'lar, dashboard'lar ve bir nöbet çizelgesi gerekir. Bunların her biri farklı bir wiki sayfasında ya da Slack'te farklı bir kişide saklıdır. Yeni işe başlayan bir mühendis ilk haftasının büyük kısmını doğru sayfayı, doğru kişiyi ve doğru anahtarı aramakla geçirir.
Platform mühendisliği neden ortaya çıktı?
"Yazan işletir" ilkesi, bir ekip tek bir servise ve birkaç araca sahip olduğunda iyi çalıştı. Araç zinciri Kubernetes, Terraform, üç farklı CI sistemi, bir secret yöneticisi, bir service mesh ve bir gözlemlenebilirlik yığınına büyüyünce ise ölçeklenmeyi bıraktı. Her ürün geliştiricisinden artık yarı zamanlı bir altyapı mühendisi olması bekleniyordu.
Bu maliyet bütçe satırında değil, bilişsel yükte görünür. 90 dakika boyunca hangi Helm chart'ının "doğru" olduğunu bulmaya çalışan bir geliştirici, beceri eksikliği yüzünden yavaşlamış değildir. Varsayılanların olmamasından yavaşlamıştır.
Platform mühendisliği bu soruna verilen cevaptır. Her ekibin aynı yığını sıfırdan kurmasını istemek yerine, özel bir ekip onu bir kez kurar, kolay seçenek haline getirir ve sağlıklı tutar. Analistler de aynı eğilimi görüyor: Gartner, büyük yazılım mühendisliği kuruluşlarının yüzde 80'inin 2026 yılına kadar platform mühendisliği ekipleri kurmasını bekliyor. Bu oran 2022'de yüzde 45 idi.
Bir platform ekibi aslında neler inşa eder?
Satıcıların diyagramlarını bir an bir kenara bırakın. Çoğu şirkette bir platform ekibi dört şey üretir.
Dahili geliştirici platformu (IDP). Bulut ve CI'ın üzerindeki self-servis araçlar ve iş akışları kümesidir. Bir Backstage portalı, bir ürün ya da iyi bakımı yapılmış bir template repo ve bir CLI'dan oluşabilir.
Golden path'ler. "Yeni bir API servisi oluştur" ya da "bir kuyruk ekle" gibi yaygın işler için görüşlü ve desteklenen yollar.
Guardrail'ler. Politika, tarama ve maliyet limitleri varsayılan olarak uygulanır. Böylece güvenli seçenek aynı zamanda en kolay seçenek olur.
Dokümantasyon ve keşif. "Bu servisin sahibi kim, runbook'u nerede ve neye bağımlı?" sorularını yanıtlayan bir katalog.
Bunların hiçbiri yeni bir ürün kategorisi gerektirmez. İyi platformların çoğu, birinin güncel tuttuğu bir cookiecutter şablonu ve bir README olarak başladı.
Golden path nedir ve ekipler neden onları yok sayar?
CNCF, golden path'i "hızlı proje geliştirme için iyi entegre edilmiş kod ve yeteneklerin şablonlanmış bir kompozisyonu" olarak tanımlar. Bu tanımı Google Cloud, bir Spring Boot örneği üzerinden adım adım anlatıyor. Sade bir dille söylemek gerekirse, yeni bir servise ilk gününde repo, pipeline, loglama ve deploy yapılandırması veren bir şablondur.
Başarısızlık biçimi de aynı derecede basittir. Kimsenin istemediği, yolu kullanacak ekiplerle konuşulmadan inşa edilmiş bir path, tek haneli benimseme oranlarında takılır. Platform ekibi de geliştiricilerin neden hâlâ ticket açtığını merak eder. Path, geçici çözümden daha kısa olmalıdır. Değilse insanlar geçici çözümü seçer.
Golden path'leri canlı tutan iki kural vardır:
Çit değil, döşeli yol. Geliştiriciler yoldan ayrılabilir, ama yoldan çıkıp inşa ettikleri şeyin destek yükünü üstlenirler.
Bir ürün gibi sahiplenilir. Birisi geri bildirimleri okur, benimsemeyi takip eder ve kimsenin kullanmadığı path'leri siler.
Platform mühendisliği sadece yeni adıyla DevOps mu?
Kısmen öyle, ve dürüst cevap pazarlama cevabından daha faydalı. DevOps bir kültürdür: geliştirme ve operasyon arasında paylaşılan sahiplik, kısa geri bildirim döngüleri. Platform mühendisliği ise bu kültürü ölçekte sürdürülebilir kılmanın yollarından biridir. Tekrarlayan operasyonel işi bir ürüne dönüştürür.
SRE ise başka bir disiplin. SRE'ler güvenilirlik hedeflerini tanımlar, ölçer ve bu hedefleri korumak için ne zaman yeni özellik göndermeyi durduracaklarına karar verir. Platform ekibi döşeli yolu sağlar. SRE ekibi ise o yolda ne kadar risk alabileceğinizi söyler.
DevOps bir kültür ve pratikler bütünüdür. Çıktısı paylaşılan sahiplik ve otomasyondur. Genellikle bir unvana ve bir ticket kuyruğuna dönüşerek başarısız olur.
SRE bir güvenilirlik disiplinidir. Çıktısı SLO'lar, hata bütçeleri ve bir olay süreci olur. Genellikle yetkisiz bir nöbet çizelgesine dönüşerek başarısız olur.
Platform mühendisliği bir iç ürün ekibidir. Çıktısı self-servis bir platform ve golden path'lerdir. Genellikle kimsenin kullanmadığı bir platforma dönüşerek başarısız olur.
Başarısızlık biçimlerini iki kez okumaya değer. Ticket alıp istenen her şeyi inşa eden bir platform ekibi, yeniden adlandırılmış bir operasyon ekibidir ve eski kuyruk sorunlarının tamamını miras alır.
Bir platform ekibi kadroya ne zaman değer?
Yaklaşık 30'dan az mühendisiniz ve bir iki servisiniz varsa bunu atlayın. Bu büyüklükte iyi bir template repo ve ortak bir Terraform modülü işi görür. Tam zamanlı bir platform ekibi bu noktada gereksiz yüktür. On kişilik bir ekipte birkaç kişi sessizce platformun kendisi haline gelir ve bu da sorun değildir.
Aynı sinyallerin tekrarladığını gördüğünüzde yatırım geri dönmeye başlar:
Yeni servisler, çoğunlukla başkalarını beklediği için üretime çıkmak haftalar sürer.
Üç ekip aynı deploy sorununu üç farklı yöntemle çözmüştür.
Yeni bir mühendisi işe almak, bir yığın sözlü bilgi ve bolca "Ayşe'ye sor, o bilir" demek anlamına gelir.
Güvenlik ve uyumluluk incelemeleri sonda, ekip ekip ve elle yapılır.
Team Topologies'in thinnest viable platform dediği en küçük kullanışlı sürüm, en büyük tekrar eden acıyı gidermeye yetecek kadar şeydir. İyi belgelenmiş olur ve başka bir şey içermez. Ekipler arasında en çok saat yiyen tek bir iş akışıyla başlayın. Bu genellikle "yeni servis oluştur" ya da "önizleme ortamı al" olur.
Feature management, her ekibin kendi özel versiyonunu yazmasından daha ucuz olan bir ortak servisin iyi bir örneğidir.
Her ekibin çağırabildiği, aynı denetim izine ve aynı temizlik kurallarına sahip tek bir flag servisi, her ekibi yarım çalışan kendi toggle sistemini yazmaktan kurtarır. Satın alsanız da inşa etsiniz de bu, her repo'nun içinde değil platformun üzerinde durmalıdır.
Bir platformun kodu okumakla ne ilgisi var?
Diyagramların itiraf ettiğinden çok daha fazla. Bir platform, çevresindeki bilgi kadar kullanışlıdır. Bir geliştirici "A servisi B servisine nasıl kimlik doğrular?" diye sorduğunda cevap kodda, yapılandırmada ve belki altı aydır güncellenmemiş bir runbook'ta yaşar.
Platform ekipleri burada sessizce zaman kaybeder. "X nerede yapılandırılmış?" diye başlayan Slack sorusunu onlar alır ve bu haftanın beşinci kez, yine ezbere cevaplarlar. Bir repo 80 bin satırı geçtiğinde ve platform ekibi bir insan arama indeksine dönüştüğünde bu etki açıkça görünür.
Burada birkaç araç yardımcı olur ve sorunun farklı yarılarını çözerler. Docs-as-code araçları yazılı kısmı kaynağa yakın tutar.
Kodu bilen asistanlar ise kodun kendisi hakkındaki soruları yanıtlar. Sourcegraph'ın asistanı büyük, çok repolu kuruluşlara yöneliktir ve kurumsal müşterilere teklif üzerine satılır. Bu yüzden on beş kişilik bir ekipten çok, geniş altyapılara sahip platform ekiplerine daha uygundur.
Editör içindeki günlük iş için genel bir asistan çok alanı kapsar. Tek çekincesi, yalnızca ona verdiğiniz bağlamı bilmesidir.
Kopyalamaya değer model şudur: golden path şablonlarını, sahiplik kataloğunu ve kodun aranabilir bir indeksini aynı yerde tutun. Yeni mühendislerin bir kişiye sormadan önce sorularını orada sormasına izin verin. Bunun etkisi saatlerle ölçülebilir. Bunu yaptıktan sonra platform ekibiniz haftada on "bu nerede yapılandırılmış?" sorusundan daha azına cevap veriyorsa, işe yaramıştır.
Bir katedral inşa etmeden nasıl başlarsınız?
Başarısız olan platform çabalarının çoğu araçla başlar. Daha iyi sıra şudur: önce insanlar, sonra yollar, en son araçlar.
On geliştiriciyle görüşün. Birleştirilmiş bir PR ile çalışan bir özellik arasında nerede zaman kaybettiklerini sorun. Aynı üç cevabı duyacaksınız.
Bir path seçin ve bir ayda çıkarın. Uçtan uca çalışan tek bir "yeni servis" şablonu, 40 boş kutucuğu olan bir portaldan iyidir.
Öncesi ve sonrasını ölçün. Yeni bir servisin ilk deploy süresini ve yeni bir işe alınanın ilk birleştirilmiş PR süresini takip edin. Bu iki sayı, herhangi bir memnuniyet anketinden daha fazlasını söyler.
Yol haritası ve değişiklik günlüğü yayınlayın. Platform işi görünür kılınmazsa görünmez kalır.
Bir şeyleri silin. Kimsenin kullanmadığı path'leri ve araçları emekliye ayırın. İnsanların etrafından dolanmak yerine güvendiği daha küçük bir platform, daha büyük ama güvenilmeyen bir platformdan iyidir.
Portal almayı önce düşünmeyin. Dağınık bir iş akışı kümesinin üstündeki bir portal, daha güzel görünen bir dağınıklıktır. Yarısı güncel olmayan 247 girdiden oluşan bir katalog ise hiç katalog olmamasından daha kötüdür.
Neyin ters gittiğini erken nasıl fark edersiniz?
Başarısız olan üç örüntü tekrar tekrar ortaya çıkar.
Yardım masası platformu. İstekler ticket ile gelir, ekip bunları elle karşılar ve buna self-servis adını verir. Test: Geliştirici yaygın bir işi kimseyle konuşmadan bitirebiliyor mu?
Zorunluluk platformu. Yönetim, platform iyileşmeden her ekibi ona geçmeye zorlar. Benimseme sayıları harika görünür, ama memnuniyet çöker. İlk altı ay kullanımın kazanılmasına izin verin.
Her şey platformu. Her talep bir özelliğe dönüşür, yüzey alanı şişer ve kalite düşer. Gerekçeleriyle birlikte, yazılı olarak hayır deyin.
Erken uyarı için kullanışlı bir oran, Slack sorularının belgelenmiş cevaplara oranıdır. Aynı soru bir ayda üç kez gelir ve ona dair ne doküman, ne şablon, ne de otomasyon varsa, bu sizin bir sonraki backlog maddenizdir.
Pazartesi sabahı gerçekte ne yapardık?
Ekipler arasında en çok zaman kaybettiren tek şeyi seçin ve onu sıkıcı hale getirin. Çoğu şirket için bu, yeni bir servis oluşturmak ya da bir test ortamı almaktır. Path'i yazın, insanların bulacağı bir yere koyun, kazandırdığı saatleri sayın. Ancak ondan sonra daha büyük bir ekibe ihtiyacınız olup olmadığına karar verin.
Platform mühendisliği kurup yüklediğiniz bir araç zinciri değildir. İç geliştiricilerinizi müşteri olarak görme kararıdır. Bu kararı verdiğinizin kanıtı, yeni bir çalışanın ilk gününden ilk birleştirilmiş değişikliğine kadar geçen mesafenin kısalmasıdır.