Geliştirici self servisini başarılı kılma


Tüm yazılım geliştirici ekip liderlerinin amacı, geliştiricilerin günlerini kod geliştirip dağıtarak geçirecekleri mutlu bir yer bulmaktır. Platform ekibi, yazılım geliştiricilerin çalışmalarına destek vererek onların ihtiyaçlarını gözlemliyor ve yanıt veriyor.

Ancak günümüzde bir yazılım geliştiricisinin işi kod yazmaktan çok daha fazlasıdır. DevOps’un yaygınlığı sayesinde yazılım geliştiricilerin büyük bir sorumluluğu vardır: özellik geliştirme, hata düzeltmeleri, dağıtım hattı, performans izleme, bulut altyapısı ve kodlarının güvenliği onlara aittir.

Yazılım geliştirme eğilimleri, yazılım ekiplerinin giderek dijitalleşen toplumun artan gereksinimlerine ayak uydurabilmesine yardımcı olmak için sürekli olarak uyarlanıyor ve iş liderleri, yazılım destekli iş girişimlerinin değerinin farkına varıyor.

Self servis dahili geliştirici portalı (IDP) sağlamak, kod yazmalarına yardımcı olacak özel olarak seçilmiş bir dizi araç ve teknoloji arasından seçim yapma özgürlüğü isteyen yazılım geliştiriciler için iyi bir deneyim sunmanın bir yolu olarak görülüyor. Önemli olan bu araçların “seçilmiş” olmasıdır. Self servis için kılavuz raylar bulunur ve bu seçilmiş araçlar, siber güvenlik ve en iyi uygulamalara yönelik kurumsal standartları karşılar.

Analist Gartner, 2028 yılına kadar platform mühendisliği ekiplerine sahip kuruluşların %85’inin geliştirici deneyimini geliştirmek ve ürün inovasyonunu hızlandırmak için ÜİYOK’ler sağlayacağını tahmin ediyor. Gartner, dahili geliştirici portallarını, modern yazılım geliştirme ortamlarında self servis keşif, otomasyon ve yeniden kullanılabilir bileşenlere, araçlara, platform hizmetlerine ve bilgi varlıklarına erişim sağlayan araçlar olarak tanımlıyor.

Analist firması, bu portalların birden fazla ekip arasında merkezi yönetim ve ortak görünürlük sağlarken geliştirici deneyimini ve hizmet güvenilirliğini artırmaya yardımcı olduğunu belirtti.

Gartner’ın geliştirici self servisine yönelik IDP tanımı, yazılım katalogları ve bunların sahiplik, kalite ve güvenlik ölçümleri gibi özellikleri; iskele şablonları; ürün ve aletle ilgili belgeler; seçilmiş araçlara ve paketlere bağlantılar; ve ortamların sağlanması ve veri işlem hatlarının yürütülmesi gibi self servis eylemler.

Gartner, IDP’nin birden fazla ekip ve bu ekipler içindeki çeşitli iş rolleri için tek bir gidilecek yer sunması gerektiğini ve bu ekiplerin altyapıyı, uygulamaları, ortamları ve platform bileşenlerini kapsayan mühendislik faaliyetlerinin mevcut durumunu ve bunların kuruluş genelindeki sahipliğini anlamalarına yardımcı olması gerektiğini söylüyor.

Yazılımı hızlı, verimli ve güvenli bir şekilde geliştirmek için gereken varlıkların bu şekilde düzenlenmesi, doğru yönde atılmış mantıklı bir adım gibi görünüyor. Ancak PagerDuty’deki DevOps savunucusu Mandi Walls’un belirttiği gibi, bunu çalıştırmanın kolay olmadığını belirtiyor. Yazılım geliştirme modelinin her yinelemesinde, yeni araçların geleneksel yöntemlere, yönetime ve kültürel uygulamalara karşı sürtüştüğü diş çıkarma sorunları yaşanacaktır.

“Tam hizmet geliştirme modellerine giden yolculukta ekiplerin, operasyon odaklı ‘biz devreye alıyoruz’ yaklaşımından, geliştirici liderliğindeki ‘siz konuşlandırın, biz gözlemliyoruz’ yaklaşımına geçişte dikkatli bir şekilde ilerlemesi gerekiyor” diyor.

Walls, her boyuttaki ve türdeki işletmelerin geçiş sürecini izleme deneyimine dayanarak, platform ve güvenilirlik mühendisliğinin, her ne pahasına olursa olsun çalışma süresi ve güven sağlarken geliştiricileri güçlendirmek için birlikte gelişmesi gerektiğini belirtiyor.

Aslında Gartner, platform mühendisliği ekiplerinin geliştirici self-servis portalını ürün geliştirme ekiplerine sağlama sorumluluğunu üstlendiğini düşünüyor. Bağımsız bir platform olarak veya DevOps platformlarının ve daha geniş dahili geliştirici platformlarının entegre bileşenleri olarak sunulabilir.

Sektördeki bazı sesler platform mühendisliğinin gereksiz karmaşıklık kattığını veya kontrolü yeniden merkezileştirdiğini iddia etse de Walls için asıl sorun dengedir.

“Geliştiriciler operasyonel bağlamdan ve dağıtım ortamlarından korunmamalıdır. Üretim gerçeklerini anlamak daha iyi, daha dayanıklı yazılımlara yol açar. Bunu, hiç yol görmeden bir araba tasarlamak gibi düşünün; bu, performansı, aşınmayı veya gerçek hayattaki güvenliği tahmin etmeyi zorlaştırır” diyor.

Walls’a göre doğru yapılan platform mühendisliği cehaleti değil üretken özerkliği mümkün kılar. “Üretken ve dirençli bir ekibin, sundukları tüm mevcut kaynak ve özelliklerden yararlanabilmesi için üretim ortamları bilgisine ihtiyacı var” diyor.

Güvenilirlik sonradan eklenmemeli, tasarlanmalıdır

Walls için self-servis hedefi sadece daha hızlı teslimat olmamalı, sürdürülebilir teslimat olmalıdır. Güvenilirliği, geliştiricilerin üretimde kendi kodlarına sahip oldukları ve platform mühendislerinin araçları, korkulukları ve telemetriyi sağladığı bir takım sporu olarak görüyor. Güvenilirlik mühendisleri, tüm sistemin hizmet düzeyi hedeflerini ve anlaşmalarını karşılamasını sağlar. Wall, yerleşik güvenilirlik uygulamaları olmadan, self servisin hızlı bir şekilde operasyonel aşırı yüke ve uyarı yorgunluğuna yol açabileceği konusunda uyarıyor.

Geliştiricinin self-servisi norm haline geldikçe, güvenilirlik artık yalnızca operasyon silosunda yaşayamaz. En başarılı kuruluşlar, operasyonel hazırlığı ve sürekli çalışma süresini geliştirici deneyiminin bir parçası haline getiren kuruluşlar olacaktır.

Mandi Duvarları, PagerDuty

“Önemli olan, gerçek self servisin ilk günden itibaren gözlemlenebilirliği, uyarıları ve olay iş akışlarını içermesidir” diyor.

Walls, güvenilirliğin herkesin işi olduğuna inanıyor. “Geliştiricinin self-servisi norm haline geldikçe, güvenilirlik artık yalnızca bir operasyon silosunda yaşayamaz. En başarılı kuruluşlar, operasyonel hazırlığı ve sürekli çalışma süresini geliştirici deneyiminin bir parçası haline getiren kuruluşlar olacaktır” diyor.

Güvenilirliğin, geliştiricinin self-servis hizmetine yönelik sonuçları vardır ve Walls’a göre bu, “herkesin kendisi için” anlamına gelmemelidir. Şöyle diyor: “Paylaşılan sorumluluk, güçlü ve net bir süreçle desteklenir. Yönetişim ve hazırlık, geliştirici özgürlüğüyle bir arada var olabilir.”

Walls’un belirttiği gibi bu, kimin çağrıda olduğu ve kimin neyi koruduğu, katman katman açıkça tanımlanmış sahiplik anlamına gelir. Kusursuz otopsilerin, güvenilirlik retrospektiflerinin ve benzerlerinin tüm ekipler arasında paylaşılmasını tavsiye ediyor.

PagerDuty, geliştirici self-servis platformları için, BT operasyonlarının ve platform ekiplerinin, dağıtımları gerçekleştirmekten bunları gözlemlemeye ve desteklemeye odaklandığı bir model önermektedir. Walls bunun şunları gerektirdiğini söylüyor:

  • Birleşik durumsal farkındalık için merkezi gözlemlenebilirlik kontrol panelleri.
  • Hizmet sahipliğine göre otomatik uyarı yönlendirme.
  • Gerçek zamanlı olay görünürlüğü ve müdahale düzenlemesi.
  • Hizmetler genelinde gözlemlenebilirliği artırmak amacıyla uyarılar, günlük mesajları ve telemetri için kuruluş çapındaki en iyi uygulamaları koordine etti.

“Geliştiricilere, hizmetleri izole etmeden kendi hizmetlerine sahip olmalarını gerçekten sağlamak istiyorsanız, işbirliğinin gözlemlenebilirliğe dahil edilmesi gerekir” diye ekliyor.

Prosedür değişikliğinin vurgulanması

Adaptavist DevOps başkan yardımcısı Matt Saunders, BT operasyonları ve platform mühendisliği ekiplerindeki değişikliklerin yanı sıra, yazılım geliştirici self-servis hizmetinin de organizasyonel ve kültürel bir değişim gerektirdiğini söylüyor.

En iyi geliştirici araçları bile dikkatli kültürel ve prosedürel değişiklikler olmadan istediğiniz etkiyi sağlayamaz.

Matt Saunders, Adaptavist

“Kendi kendine hizmet veren araçların başarılı olması için geliştirme ekiplerinin bunları kullanmayı istemesi gerekir. Benzer şekilde, geliştirici araçlarını başarıyla oluşturan ekipler de uygun kullanıcı araştırması yürütüyor, özelliklere öncelik veriyor ve sürekli destek sunuyor” diyor.

“Başarılı platform ekipleri sürekli yinelenen bir yaklaşım kullanıyor, geliştiricilere gerçek müşteriler gibi davranıyor ve bu işin bir yan proje olmasına izin vermiyor. Ayrıca benimsemeyi dikkatle ölçüyor, kullanılmayan özellikleri kullanımdan kaldırıyor ve varsayımlara değil, gözlemlenen davranışlara dayalı kasıtlı iyileştirmeler yapıyor.”

Saunders’a göre, dahili geliştirici platformları aracılığıyla kullanılabilen paylaşılan bilgi tabanı, geçici destek veya belgelenmemiş kabile bilgisinden çok daha iyi ölçeklenen canlı bir varlık haline geliyor. Ancak değişim yönetimi çok önemlidir.

“En iyi geliştirici araçları bile, dikkatli kültürel ve prosedürel değişiklikler olmadan istediğiniz etkiyi yaratamayacak. Kültürel uyumun sağlanması ve iş akışlarının ve karar alma çalışma süreçlerinin bunu sağlayacak şekilde ayarlanması, başarılı bir platform oluşturmada araçlar kadar önemlidir” diye ekliyor.

Kurumsal yapay zeka benimsenmeyi teşvik ediyor

Kurumlarda yapay zekanın (AI) kullanımına ilişkin sektördeki tüm heyecan göz önüne alındığında, yazılım geliştirme ekipleri, yapay zekanın kurumsal uygulamalar oluşturmaya kattığı karmaşıklık konusunda ihtiyatlı davranıyor.

Bir Gartner araştırması, yazılım geliştiricilerin uygulamalara yapay zeka yetenekleri eklemenin en büyük zorluk olduğundan endişe duyduğunu öne sürüyor. Gartner’a göre, büyük kuruluşlarda, onları seçilmiş araçlar, yeniden kullanılabilir bileşenler ve standart iş akışı önerileri sunmak için kullanan ÜİYOK’lere olan ilginin büyük olmasının nedeni budur.

Gartner, self-servis keşif ve yapay zeka modellerine, orkestrasyon çerçevelerine, gözlemlenebilirlik araçlarına ve ModelOps platformlarına erişim olanağı sağlayarak bu yeteneklerin, bir IDP’nin birden fazla ekibin GenAI yeteneklerini oluşturmanın teknik karmaşıklığında gezinmesine yardımcı olabileceği anlamına geldiğini belirtiyor.

Ancak Gartner’a göre Büyük işletmeler için 2025 için teknoloji benimseme yol haritasıteknik uyumsuzluk veya mimari karmaşıklık, dahili geliştirici portallarının başarıyla benimsenmesini etkileyen birincil risk faktörüdür.

Bu, kurumsal yapay zekanın büyümesi ve yazılım ekiplerinin kurumsal BT sistemlerini yapay zeka ile donatma ihtiyacının artmasıyla birlikte, IDP aracılığıyla yazılım geliştirmede self servisin muhtemelen daha yaygın hale geleceği anlamına geliyor. Ancak yapay zeka uygulamaları oluşturmanın karmaşıklığını bir kenara bırakırsak, yazılım geliştiricinin self-servis hizmeti için bir IDP’yi kullanıma sunmak, birçok kurumsal BT liderinin karşılaşacağı ilk engel olacaktır.



Source link