Platform mühendisliği, ürün yönetimi ilkelerine ve dijital ve BT sistemlerine uygulanan ürün modeline dayanmaktadır. Hızlı hareket eden dijital ekipler, bilgi teknolojisi altyapı kütüphanesi (ITIL) ve BT hizmet yönetimi (ITSM) ve otonom dijital veya BT ürün ekipleri gibi katı süreç çerçevelerine karşı direnç gösterir ve geleneksel altyapı mühendislerine olan ihtiyacı azaltır.
Ürün yönetimi ilkelerine dayanan platform mühendisliği, BT operasyonlarını modernize etmek için bir yaklaşım sunmaktadır. Forrester, ürün düşüncesini platform ekiplerine enjekte ederek teknoloji organizasyonlarının kendilerini gelecek için konumlandırabileceğine inanıyor.
Platform mühendisliği nedir?
Forrester, platform mühendisliği için sıklıkla kapsanan teknik yönleri ve daha az sıklıkla kapsanan yönetim yeteneklerini içeren bir yetenek modeli derledi. Bu, sadece özel kuruluşları değil, aynı zamanda çapraz fonksiyonel süreçleri, etkinleştirme ekiplerini veya diğer mekanizmaları da içerebilecek, derinlemesine düşünmeniz ve organizasyonel kaynaklarınız aracılığıyla ele aldığınız şeylerin bir envanteridir.
Yetenekleriniz, müşterilerinizin platformu nasıl deneyimlediğidir. Onlar sizin ön kapınız, tabiri caizse. Müşterileriniz platformunuzu keşfedecek, üzerinde yer alacak, sağlayacak, uygulama programlama arayüzleri (API’lar) ile etkileşime girecek, güvenlik ve performans için kalıplardan yararlanacak ve bu yetenekler aracılığıyla yardım çağrısında bulunacaktır. Ve hayır, tamamen otomatik bir self servis platformu diye bir şey yok.
Kullanıcılar ve geliştiricilerin platformu ve hizmetlerini keşfedebilmeleri gerekir. Platformunuzu bir ürün gibi yönetmek, kullanıcıların işe alım yolculuğunu anladığınız ve bunları geliştirici platform özelliklerini tanımlama ve hatta katkıda bulunma sürecinin bir parçası olmaya davet ettiğiniz anlamına gelir.
Döngü içi insan iş akışı tabanlı onaylarla kolay, sürtünmesiz izin ve erişim bekleyeceklerdir. Sağlandıktan ve aktif olarak geliştikten sonra, tükettikleri hizmetlerin devam eden durumu hakkında bilgiye ihtiyaç duyacaktır.
Genellikle, daha büyük kuruluşlarda BT hizmetleri için bir hizmet kataloğu veya portal özelliği olacaktır. Bu yoksa, finanse etmeli ve yaratmalısınız. Geliştirici odaklı portallar-örneğin, Spotify sahne arkası, Dahili Geliştirici Portalı, Atlassian Pusulası-popülerlik kazanıyor. Örneğin, Kuzey Amerika Toyota, sarf malzemesi planları, keşfedilebilir bir yazılım kataloğu, eğitim ve öğretim kaynakları ve geliştirici portalındaki finoplar ve diğer metrikler için operasyonel raporlar içerir.
Platform hizmetlerine ve kaynaklarına erişim genellikle iki aşamalı bir süreçtir, ilk tedarikleme (hesapların ayarlanması) ve ardından günlük talep (sanal makineler, kümeler vb.). Hesabı kurmak bazı insan onayları gerektirse de, günlük talep API erişimi gerektirir.
API’ler aracılığıyla temel kaynakları sağlayamayan, yapılandıramayan ve yönetemeyen bir platform gerçek bir platform değildir. Tipik olarak, platformlar API’leri işleme düğümleri, veri depoları, kuyruklar, boru hatları ve gözlemlenebilirlik probları gibi gerekli kaynakları başlatmayı ve yapılandırmayı destekler. Önemli API tasarım soruları vardır. Birçok kuruluş genellikle API mühendislik yeteneklerine sahiptir, ancak self servis sunumunu destekleme nüanslarını araştırmamış olabilir.
Platform kullanıcıları ayrıca nasıl kullanılacağına dair belgelere hazır erişim gerektirir. Bunlar nasıl yaratılacak ve sürdürülecek? Tipik olarak, çekirdek sistem hızlı başlangıçları ve nasıl yapılır kılavuzları için bir wiki kullanılır. Forrester, kalıpların kod olarak belgelenmesini ve kaynak kontrolü yoluyla yönetilmesini önerir. Bu kaynaklardan sorumlu olanlar için süreçleri, rolleri ve sorumlulukları tanımlamak da tavsiye edilir. Bunun herkesin sorumluluğu olduğunu söylemek caziptir, ancak bu yaklaşım ölçekte veya uzun vadede çalışmaz.
Destek başka bir önemli özelliktir. Platformlar tipik olarak yüksek oranda kaldırılır. Kiracı uygulamaları oluşturan kullanıcılar sistemi anlamayabilir. Sistem beklendiği gibi davranmayabilir. Bunlar ve diğer nedenlerden dolayı, muhtemelen bir miktar çağrı üzerine desteğe ihtiyacınız olacaktır. Chatgpt çağında bile insan teması gereklidir.
Çoğu kuruluş, örneğin BMC Software ve ServiceNow gibi destek yönetimini biletlemiştir. Bu, temel platformları desteklemek için kullanılabilir ve kiracı uygulamaları bundan yararlanabilir. Bununla birlikte, Forrester’ın belirttiği gibi, daha azının sağlam bir büyük olay/kritik olay yönetimi kabiliyeti vardır, bu da gereklidir. Bu yetenekler Pagerduty veya Everbridge gibi ürünlere dayanmaktadır.
Operasyonel yetenekler
Birçok platform mühendisliği mimarisi ve çerçevesi için odak noktası operasyonel yetenekler, özellikle daha teknik olanlardır. Birçok tür altyapı platformu bileşeni olsa da, temel DevOps zincir yetenekleri çoğu platform mühendisliği tartışmasında ortaya çıkmaktadır.
Forrester, konuşlandırmaların ve operasyonel mimarilerin yönetişim ve politika için kontrol edilmesini önerir. Bu, açık politika aracısı ve benzeri yaklaşımlar gibi kod olarak yapılır. Gerekli tasarım kalıpları, konfigürasyonlar ve sertleştirme standartları kontrol edilmelidir. Yazılım-bono (SBOM) kontrolleri giderek daha zorunlu mu? Başarısız olurlarsa sonuçları nelerdir? Bir değişiklik yönetimi süreci varsa, risk nasıl hesaplanır? Kaos testleri politika tarafından öneriliyor mu yoksa gerekli mi?
Platformun doğrudan (idari/geliştirici) kullanıcıları tanımlanmalı ve yetkilendirilmeli ve oluşturdukları ürün ve uygulamalar, yöneticinin platforma erişimini kontrol eden hizmetlerden oldukça farklı olabilecek kimlik ve erişim hizmetleri gerektirecektir. Hangisini destekliyorsunuz?
Forrester, BT karar vericilerinin, ayrıcalıklı erişim yönetimi olup olmadığını ve multifaktör kimlik doğrulaması (MFA) kullanıldığını, tek oturum açma ve/veya dizin hizmetlerinin kiracı kullanıcıları için kullanılabilir olup olmadığını kontrol etmesini önerir. Boru hattının yazılım kompozisyon analizi, SBOM üretimi ve statik uygulama güvenlik testi gibi güvenlik testi sunması gerekmektedir.
Uygulamaların veya iş yüklerinin sağlandıktan sonra kaynaklara yüklendiği göz önüne alındığında, altyapı platformlarında tam bir geliştirme boru hattı kaynaklarına sahip olmak yararlıdır. Bunlar, belki de GitHub veya GitLab gibi bulut hizmetleri ile kaynak kontrol ve paket yönetimine erişimi içermelidir.
Ayrıca, iş yükünün dağıtıldığı BT altyapısı, yapılandırılması ve yönetilmesi gereken temel BT kaynaklarının sağlanmasını gerektirecektir. Bu genellikle altyapı otomasyonu ile elde edilir. BT karar vericileri, çalışma zamanı sağlanmasının Terraform’a dayalı olup olmadığını veya hiperscaler’a özgü olup olmadığını kontrol etmelidir. Platform bir bulut sağlayıcısına bir proxy katmanı sağlıyor mu?
Başlangıçta sağlandıktan sonra yapılandırma ayrı bir endişe olabilir – örneğin, kırmızı şapka, şef veya perforce yazılımı ile [Puppet] – bu da sürüklenmeyi kontrol edebilir. Teknik fizibiliteye bağlı geniş bir varyasyon vardır.
Dağıtım desteği
Platform mühendisliği AIOP’ları içerebilir, bu nedenle BT karar vericileri platformun kendisinin nasıl izlendiğine ve gözlemlendiğine ve operasyonel bilgilerlerin nasıl oluşturulduğuna bakmalıdır.
AIOP ve eylem arasındaki ilişki nedir (örneğin destek)? Forrester, BT karar vericilerinin kiracı başvuruları için mevcut olan izleme, günlüğe kaydetme ve izleme gibi hizmetleri değerlendirmesini önerir. Kullanıcı deneyimi nasıl anlaşılır? Örneğin, bir uygulama performansı yönetimi veya AIOP aracı, platformları kapsayan ve tüm BT mülkünü kapsayan gerçek zamanlı bilgiler için platformun bir parçası olarak mevcut olabilir. Bu bilgiler daha sonra bir geliştirici portalında yayınlanabilir.
Son olarak, Forrester platform güvenilirliğinin önemini not eder. BT karar vericileri, platformun kendisinin esneklik, kullanılabilirlik ve öğrenme için nasıl yönetildiğini değerlendirmelidir. Örneğin, site güvenilirlik mühendisleri platform yaklaşımını tanımlama, büyük olay tepkisi ve retrospektiflere öncülük etme ve operasyonları gözden geçirme konusunda özel bir işlevi olabilir. Retrospektif, bir kaos mühendisliği yaklaşımının kontrol olarak kullanılabileceği bir riskin belirlenmesine yol açabilir.
Genel olarak, Forrester, ekiplerin inovasyon ve çalışanlar için pazar taleplerini karşılamak için mücadele ettiği hesaplama, depolama, ağ oluşturma ve ara katman yazılımı gibi alanlarda geleneksel ekip siloları ile mücadele etmek için platform mühendisliğini, işbirlikçi ve duyarlı bir çalışma ortamını tercih ediyor. Bu nedenle, BT platformu yönetimi içindeki ürün merkezli düşünme, hizmet sunumunu geliştirmek için kullanılabilir.
Bu makale, bir alıntıya dayanmaktadır. Forrester Platform Mühendislik Yetenek Modeli. Yazar, Charles Betz, Başkan Yardımcısı Müdür Analisti ve Forrester’ın Kurumsal Mimarlık Ekibine liderlik ediyor.