DevOps ile karakterize edilen yazılım geliştirme dünyası hızla gelişiyor; yeni bir araç bir sonrakini takip ediyor ve DevSecOps veya SRE (Site Güvenilirliği Mühendisliği) gibi yeni moda sözcükler ön plana çıkıyor. DevOps topluluğunda sıklıkla tartışılan bir soru, bir sonraki büyük şeyin ne olacağıdır. Platform mühendisliği, DevOps'un mümkün olan son alternatifi olarak büyük beğeni topluyor. Çevrimiçi konferans PlatformCon'un son baskısı dünyanın her yerinden binlerce katılımcının ilgisini çekti.
Duyuru
DevOps topluluğu oldukça açık fikirli bir topluluktur çünkü grup içi veya grup dışını tanımlayabilecek bir manifesto veya metodoloji yoktur. SRE veya Platform Mühendisliği gibi kavramlar, DevOps araç setinin tamamlayıcısı olarak görülüyor ve şirketlerin uygulamaların sunulma şeklini iyileştirmesine ve geliştirme ekiplerinin üretkenliğini artırmasına olanak tanıyor. Ayrıca üretkenlik, iş tatmininin iyi bir göstergesidir (anahtar kelime: geliştirici deneyimi). Uygulamada, geliştirme ekiplerinin iş yükü ve bilişsel yükü gibi faktörler genellikle üretkenlik üzerinde olumsuz etkiye sahiptir.
Platform mühendisliği diğer güncel trendlerden öne çıkıyor çünkü yakın zamanda odaklanılan bir sorunu ele alıyor: yazılım dağıtımının artan karmaşıklığı. Platform Mühendisliği, ekip üretkenliğini ve iş memnuniyetini artırmak amacıyla bu zorluğun üstesinden gelir. Bu kapsamlı yaklaşım aynı zamanda platform mühendisliğinin neden bu kadar hızlı popülerlik kazandığını da açıklıyor.
(Resim:
Julian Dolman HEADSHOT Fotoğrafçısı
)
Mirco Hering, Accenture'da genel müdür ve DevOps'un küresel başkanıdır. “Modern İşletmeler için DevOps” kitabının yazarıdır ve deneyimlerini “Artık Fabrika Değil” blogunda paylaşmaktadır.
Platform Mühendisliği bir sonraki DevOps mu? – HAYIR!
Peki platform mühendisliği yeni DevOps mu? Aksine değil. DevOps, BT topluluğuna sürekli olarak geliştirilen ve genişletilen çok çeşitli araçlar ve ilkeler sunmuştur. DevOps, güçlü bir kültürel boyutla karakterize edilir: Örneğin, “Suçsuz otopsiler”, tükenmişliğin önlenmesine ve kurumsal siloların yıkılmasına vurgu yapar. Bunlar bütünsel organizasyonel kaygılardır ve trend kavramların çoğu belirli bir boyuta bakar: DevSecOps güvenliğe, SRE ise modern işletim modellerine odaklanır. Platform mühendisliği, ekiplere artan karmaşıklıkla başa çıkabilecek teknik kapasiteyi sağlamayı amaçlamaktadır. Bu nedenle platform mühendisliği DevOps'a daha çok yeni bir bakış açısıdır. Odak noktasını geliştirici topluluğuna ve güvenlik ve altyapı operasyonları gibi iş çıkarlarına genişletir.
Artan karmaşıklığa karşı
Günümüzde uygulamaların ve BT altyapılarının konuşlandırılmasını bu kadar karmaşık kılan şey nedir? Yaklaşık 15 yıl önce, üç aylık yazılım sürümleri yaygındı ve her sürüm için geliştiricilerin çoğunlukla bireysel yazılım ve monolitik yazılım paketleri olmak üzere birkaç düzine sistem teslim etmesi gerekiyordu. Canlıya geçişten önce genellikle birkaç hafta süren sıkı bir kod dondurma dönemi gelirdi. Bir “savaş odasında” gerekli tüm unsurların ve bunların versiyonlarının bir envanterini içeren basılı bir proje planı vardı.
O zamandan bu yana bulut (yerel) teknolojilerin ortaya çıkmasıyla durum önemli ölçüde değişti (bkz. Şekil 1). Bulut sağlayıcı hizmetlerini dahil etmek daha kolaydır. Ancak açık kaynak yazılımın artan payı, kaynak kodunda yer alan öğeleri çoğaltan birçok geçişli bağımlılıkla birlikte yüzlerce açık kaynak öğesinin bir yazılım sürümüne dahil edilmesine yol açmıştır. Tipik sürüm döngüsü artık üç ayda bir değil, aylık, haftalık ve hatta çok daha kısa dönemlerdir. İlgili görevlerin yanı sıra hızla artan araç sayısı da karmaşıklığı artırıyor. Bir zamanlar işin çoğu manuel olarak yapılırken, bugün test, derleme, sürüm ve altyapı alanları da dahil olmak üzere düzinelerce araç bir sürüm döngüsüne dahil oluyor. Ekiplerin DevOps ve çevik yöntemler aracılığıyla geliştirilen kendi araçlarını seçmelerine izin verme uygulaması, özellikle büyük şirketlerde araçların güçlü bir şekilde çeşitlendirilmesine yol açarak daha da karmaşık hale gelmesine katkıda bulundu.
BT sunumunun bu yönleri son yıllarda önemli ölçüde değişti (Şekil 1).
(Resim: Mirco Hering/Accenture)
Savaş odası sürümlerinin olduğu günlerde bireysel yöneticiler teslim edilecek yazılım hakkında hâlâ tam bir anlayışa sahip olabiliyorken, günümüzde süreç ve araçların çokluğu ve giderek kısalan sürüm döngüleri göz önüne alındığında bu pek mümkün değil. Ancak karmaşıklığın artması kendi başına kötü bir şey değildir. Daha ziyade, yazılım geliştirmedeki önemli ölçüde daha kapsamlı dağıtım yeteneklerinin bir sonucu veya yan etkisidir. Ancak platform mühendisliği, aşırı karmaşıklık nedeniyle artan maliyet ve risklerin yanı sıra kontrol kaybı tehlikesine de etkili bir şekilde karşı koymak için yeterli araçlar sunar.
Platform mühendisliği, tekdüze yapı ve ortak kalıplarla karmaşıklığın üstesinden gelir. “Herkese uyan tek boyut” sloganını temel alan birleşik takımlama platformunun birçok başarısız uygulamasının gösterdiği gibi, bu göründüğünden daha zordur. Özellikle büyük, heterojen organizasyonlarda, çeşitli teknolojilerin ilgili herkes için tek bir çatı altında bir araya getirilmesi gerektiğinde standardizasyon ile esneklik arasında doğru dengeyi bulmak genellikle zordur.
Platform Mühendisliği, geliştiricilere güvenlik, altyapı veya uygulama sunumuyla ilgili yaygın sorunlara yanıt bulmaları için çeşitli seçenekler sunmak amacıyla kapsamlı belgeler ve çeşitli şablonlar içerir. Ayrıca şirket standartlarına uyum basitleştirilmelidir. Ancak geliştirme ekiplerinin aynı zamanda yeni araç ve uygulamaları deneme esnekliğine de sahip olması gerekir. Bu, temel olarak yazılım mühendisliğine yönelik bulut hizmet sağlayıcılarının sunduğu yeni hizmetleri ve işlevleri içerir. Platform mühendisliği, deneme yoluyla genişleme ve ardından gelen konsolidasyon arasında sürekli gidip gelen sarkaç için gerekli olan doğru dengeyi ve yönetimi sağlamalıdır. Geliştirme platformunuz için güvenilir bir işletim modeli bulmanın tek yolu budur. Platform mimarisi kurumsal uygulama mimarisini temel almalıdır (bkz. Şekil 2). Bunu başarmak için tüm yazılım geliştirme yaşam döngüsünün yalnızca gevşek bir şekilde bağlı olan entegre bir platforma dayanması gerekir. Bu, diğer şeylerin yanı sıra, örneğin belirli bir görev için yeni, daha iyi bir aletin mevcut olması durumunda, gerektiğinde bileşenleri değiştirme özgürlüğünü sağlar. Esnek bağlantı, deneyimli ekiplerin değişiklik yapmasını ve platforma bizzat katkıda bulunmasını kolaylaştırır.
Bir yazılım platformu mimarisinin bileşenleri (Şekil 2).
(Resim: Mirco Hering/Accenture)
Dahili geliştirme ekiplerine odaklanarak platform mühendisliğini ürün geliştirme ilkeleriyle uyumlu hale getirmek en iyisidir. Buna, eğer varsa harici geliştiriciler de dahildir. Platform mühendisliğinin kapsamı ve yaklaşımı, kullanıcı/müşteri ihtiyaçlarıyla empati kurmayı ve böylece platformun kabulünü arttırmayı amaçlamaktadır. Ancak platform paydaşları, güvenlik ve altyapı gibi süreç ve standartların bekçisi olmaya devam ediyor. Platform geliştirme ekibi daha sonra, katılan herkes için uygulanabilir bir çözüm oluşturmak amacıyla çeşitli paydaşlar arasında arabuluculuk yapmalıdır.
Duyuru
- Platform Mühendisliği, geliştirme ekiplerinin üretkenliğine ve iş memnuniyetine odaklanarak DevOps araç setine alternatif olarak kendini kanıtlıyor.
- Platform mühendisliği standardizasyon ve esneklik arasındaki dengeyi arar.
- Başarılı olmak için platform mühendisliğinin ürün geliştirme ilkelerini takip etmesi gerekir.
DevOps topluluğu oldukça açık fikirli bir topluluktur çünkü grup içi veya grup dışını tanımlayabilecek bir manifesto veya metodoloji yoktur. SRE veya Platform Mühendisliği gibi kavramlar, DevOps araç setinin tamamlayıcısı olarak görülüyor ve şirketlerin uygulamaların sunulma şeklini iyileştirmesine ve geliştirme ekiplerinin üretkenliğini artırmasına olanak tanıyor. Ayrıca üretkenlik, iş tatmininin iyi bir göstergesidir (anahtar kelime: geliştirici deneyimi). Uygulamada, geliştirme ekiplerinin iş yükü ve bilişsel yükü gibi faktörler genellikle üretkenlik üzerinde olumsuz etkiye sahiptir.
Platform mühendisliği diğer güncel trendlerden öne çıkıyor çünkü yakın zamanda odaklanılan bir sorunu ele alıyor: yazılım dağıtımının artan karmaşıklığı. Platform Mühendisliği, ekip üretkenliğini ve iş memnuniyetini artırmak amacıyla bu zorluğun üstesinden gelir. Bu kapsamlı yaklaşım aynı zamanda platform mühendisliğinin neden bu kadar hızlı popülerlik kazandığını da açıklıyor.
(Resim:
Julian Dolman HEADSHOT Fotoğrafçısı
)
Mirco Hering, Accenture'da genel müdür ve DevOps'un küresel başkanıdır. “Modern İşletmeler için DevOps” kitabının yazarıdır ve deneyimlerini “Artık Fabrika Değil” blogunda paylaşmaktadır.
Platform Mühendisliği bir sonraki DevOps mu? – HAYIR!
Peki platform mühendisliği yeni DevOps mu? Aksine değil. DevOps, BT topluluğuna sürekli olarak geliştirilen ve genişletilen çok çeşitli araçlar ve ilkeler sunmuştur. DevOps, güçlü bir kültürel boyutla karakterize edilir: Örneğin, “Suçsuz otopsiler”, tükenmişliğin önlenmesine ve kurumsal siloların yıkılmasına vurgu yapar. Bunlar bütünsel organizasyonel kaygılardır ve trend kavramların çoğu belirli bir boyuta bakar: DevSecOps güvenliğe, SRE ise modern işletim modellerine odaklanır. Platform mühendisliği, ekiplere artan karmaşıklıkla başa çıkabilecek teknik kapasiteyi sağlamayı amaçlamaktadır. Bu nedenle platform mühendisliği DevOps'a daha çok yeni bir bakış açısıdır. Odak noktasını geliştirici topluluğuna ve güvenlik ve altyapı operasyonları gibi iş çıkarlarına genişletir.
Artan karmaşıklığa karşı
Günümüzde uygulamaların ve BT altyapılarının konuşlandırılmasını bu kadar karmaşık kılan şey nedir? Yaklaşık 15 yıl önce, üç aylık yazılım sürümleri yaygındı ve her sürüm için geliştiricilerin çoğunlukla bireysel yazılım ve monolitik yazılım paketleri olmak üzere birkaç düzine sistem teslim etmesi gerekiyordu. Canlıya geçişten önce genellikle birkaç hafta süren sıkı bir kod dondurma dönemi gelirdi. Bir “savaş odasında” gerekli tüm unsurların ve bunların versiyonlarının bir envanterini içeren basılı bir proje planı vardı.
O zamandan bu yana bulut (yerel) teknolojilerin ortaya çıkmasıyla durum önemli ölçüde değişti (bkz. Şekil 1). Bulut sağlayıcı hizmetlerini dahil etmek daha kolaydır. Ancak açık kaynak yazılımın artan payı, kaynak kodunda yer alan öğeleri çoğaltan birçok geçişli bağımlılıkla birlikte yüzlerce açık kaynak öğesinin bir yazılım sürümüne dahil edilmesine yol açmıştır. Tipik sürüm döngüsü artık üç ayda bir değil, aylık, haftalık ve hatta çok daha kısa dönemlerdir. İlgili görevlerin yanı sıra hızla artan araç sayısı da karmaşıklığı artırıyor. Bir zamanlar işin çoğu manuel olarak yapılırken, bugün test, derleme, sürüm ve altyapı alanları da dahil olmak üzere düzinelerce araç bir sürüm döngüsüne dahil oluyor. Ekiplerin DevOps ve çevik yöntemler aracılığıyla geliştirilen kendi araçlarını seçmelerine izin verme uygulaması, özellikle büyük şirketlerde araçların güçlü bir şekilde çeşitlendirilmesine yol açarak daha da karmaşık hale gelmesine katkıda bulundu.
BT sunumunun bu yönleri son yıllarda önemli ölçüde değişti (Şekil 1).
(Resim: Mirco Hering/Accenture)
Savaş odası sürümlerinin olduğu günlerde bireysel yöneticiler teslim edilecek yazılım hakkında hâlâ tam bir anlayışa sahip olabiliyorken, günümüzde süreç ve araçların çokluğu ve giderek kısalan sürüm döngüleri göz önüne alındığında bu pek mümkün değil. Ancak karmaşıklığın artması kendi başına kötü bir şey değildir. Daha ziyade, yazılım geliştirmedeki önemli ölçüde daha kapsamlı dağıtım yeteneklerinin bir sonucu veya yan etkisidir. Ancak platform mühendisliği, aşırı karmaşıklık nedeniyle artan maliyet ve risklerin yanı sıra kontrol kaybı tehlikesine de etkili bir şekilde karşı koymak için yeterli araçlar sunar.
Platform mühendisliği, tekdüze yapı ve ortak kalıplarla karmaşıklığın üstesinden gelir. “Herkese uyan tek boyut” sloganını temel alan birleşik takımlama platformunun birçok başarısız uygulamasının gösterdiği gibi, bu göründüğünden daha zordur. Özellikle büyük, heterojen organizasyonlarda, çeşitli teknolojilerin ilgili herkes için tek bir çatı altında bir araya getirilmesi gerektiğinde standardizasyon ile esneklik arasında doğru dengeyi bulmak genellikle zordur.
Platform Mühendisliği, geliştiricilere güvenlik, altyapı veya uygulama sunumuyla ilgili yaygın sorunlara yanıt bulmaları için çeşitli seçenekler sunmak amacıyla kapsamlı belgeler ve çeşitli şablonlar içerir. Ayrıca şirket standartlarına uyum basitleştirilmelidir. Ancak geliştirme ekiplerinin aynı zamanda yeni araç ve uygulamaları deneme esnekliğine de sahip olması gerekir. Bu, temel olarak yazılım mühendisliğine yönelik bulut hizmet sağlayıcılarının sunduğu yeni hizmetleri ve işlevleri içerir. Platform mühendisliği, deneme yoluyla genişleme ve ardından gelen konsolidasyon arasında sürekli gidip gelen sarkaç için gerekli olan doğru dengeyi ve yönetimi sağlamalıdır. Geliştirme platformunuz için güvenilir bir işletim modeli bulmanın tek yolu budur. Platform mimarisi kurumsal uygulama mimarisini temel almalıdır (bkz. Şekil 2). Bunu başarmak için tüm yazılım geliştirme yaşam döngüsünün yalnızca gevşek bir şekilde bağlı olan entegre bir platforma dayanması gerekir. Bu, diğer şeylerin yanı sıra, örneğin belirli bir görev için yeni, daha iyi bir aletin mevcut olması durumunda, gerektiğinde bileşenleri değiştirme özgürlüğünü sağlar. Esnek bağlantı, deneyimli ekiplerin değişiklik yapmasını ve platforma bizzat katkıda bulunmasını kolaylaştırır.
Bir yazılım platformu mimarisinin bileşenleri (Şekil 2).
(Resim: Mirco Hering/Accenture)
Dahili geliştirme ekiplerine odaklanarak platform mühendisliğini ürün geliştirme ilkeleriyle uyumlu hale getirmek en iyisidir. Buna, eğer varsa harici geliştiriciler de dahildir. Platform mühendisliğinin kapsamı ve yaklaşımı, kullanıcı/müşteri ihtiyaçlarıyla empati kurmayı ve böylece platformun kabulünü arttırmayı amaçlamaktadır. Ancak platform paydaşları, güvenlik ve altyapı gibi süreç ve standartların bekçisi olmaya devam ediyor. Platform geliştirme ekibi daha sonra, katılan herkes için uygulanabilir bir çözüm oluşturmak amacıyla çeşitli paydaşlar arasında arabuluculuk yapmalıdır.