AKF

Developerlerin Seçimleri Teknoloji Stratejinizi Nasıl Etkiler?

Developerler bir çok işletmede yazılım geliştirme haricinde, operasyondan ve altyapıdan da sorumlu. Bu yeni “DevOPS” pozisyonu, onların önemli kararları almasını gerektiriyor.  Fakat, Developerlerin teknoloji seçimleri, şirketin tüm teknoloji stratejisini, mevcut alt yapısını, verimliliğini ve geleceğini etkileyebilir. 

İşletmeler  bulut ve Api teknolojilerinin sunduğu faydaların peşindeler. Dolayısıyla her şirket bir teknoloji şirketi olarak doğuyor veya bir teknoloji şirketine evriliyor. 

Çoğu işletmenin en azından bir web sitesi, bir müşteri veri tabanı ve dahil olduğu bir e-ticaret sistemi var. 

Piyasada, işletmelerin bu ihtiyaçlarını karşılamak için üretilmiş binlerce API ve devasa bir teknoloji yığını var. 

Şirketler bunların arasından teknoloji stratejilerine en uygununu seçmek,  kendi yazılımlarını hızla üretmek ve operasyonlarını en sağlıklı biçimde yürütmek zorunda. 

Bu oldukça komplike ve farklı uzmanlıklar gerektiren bir iş. Yapılan işin hacmine göre, en az bir developer, bir sistem güvenliği uzmanı ve elbette bir sistem yöneticisi ile, yani bir DevOps ekibiyle çalışılmak gerekiyor. 

Diğer seçenek, DevOps mühendisleri. Bu iş yüklerinin hepsinin altından tek başına kalkabilecek yetenek, bilgi ve tecrübeye sahip kişilere DevOps mühendisi deniyor. 

Kısaca tanımlamak gerekirse, sistem yönetmeyi profesyonel anlamda bilen geliştirici anlamına geliyor. Bugün dünyanın en çok aranan meslek gruplarından biri. Çünkü gerçek DevOps mühendislerinin sayısı hayli az ve ücret beklentileri çoğu firmanın karşılayabileceğinden oldukça yüksek. 

Multi fonksiyonel Developer

 

Peki pratikte ne oluyor?  

Ne yazık ki, DevOps mühendisinin veya DevOps ekiplerinin yapacağı iş, sadece Dev kısmına yani Developerlere (Geliştiricilere) yükleniyor. 

Yazılım geliştirmek için işe alınmış geliştiricilerin  hem kod yazması hem de geliştirdiği yazılımın tüm hayat döngüsünü en sağlıklı şekilde sürdürmesi; altyapıyı ve operasyonu sorunsuz bir biçimde yönetmesi, çıkabilecek sorunları önceden tespit edip önlem alması, sorun çıktığında çözmesi ve güvenlik konusunda açık vermeden ilerlemesi vs. gerekiyor.

Kısacası şirket için isviçre çakısı gibi multi fonksiyonel olamaları bekleniyor.

Dolayısıyla bir çok şirkette Developerler yukarıdakilerin altından kalkabilmek için, veri tabanı ve bulut sağlayıcısı seçiminden, mikro mimari ve Serverless teknolojileri adaptasyonuna, hangi eski uygulamaların buluta taşınıp, hangi yeni uygulamaların sisteme dahil edilebileceğine kadar tüm IT karalarını verir pozisyonda bulunuyor.

Bu durum developerlerin omzuna kaldırılması çok zor bir sorumluluk yüklediği kadar, işletmelerin geleceğe dönük teknoloji stratejileri için de kritik önem taşıyor. 

Çünkü doğal olarak bu kararları üzerinde çalıştıkları yazılımı ve kendi uzmanlık alanını ön plana alarak, bireysel olarak değerlendirip veriyorlar. 

Yapılan seçimlerin sonuçları daha sonra; orta ve uzun vadede, işletmelerin özenle inşa edilmiş olması gereken tüm teknoloji stratejilerini etkileyebiliyor.

Kolaylık, virallik, aşinalık

 

Elbette bulut teknolojisi, API’ler ve kurumsal düzeydeki açık kaynaklı platformlar  her düzeydeki geliştiriciye, mesela Google’nin veya Microsoft’un kendi ürünlerini geliştirirken kullandığı, bazıları yapay zeka destekli engin bir teknoloji yığınına ulaşma imkanını veriyor.

Ancak bu aynı zamanda, developerlerin kolaylık, aşinalık, kişisel ilgi, ilginç görüneni seçmek, ürün popülerliği ve geliştirdikleri ürüne yönelik olmak gibi etkilere göre seçim yapılabileceği anlamına da geliyor.

Şüphesiz developerlerin yaptığı seçimler her zaman kusurlu değil. 

Birçok durumda geliştiricilerin denediği ve etkili bulduğu teknoloji seçimleri, işletmelerin yeni teknolojileri ve teknikleri benimsemesini ve çevikliği hızlandıran en önemli unsur olarak karşımıza çıkıyor.   

Ancak söylediğimiz gibi, eninde sonunda, seçimler tek bir kişinin bakış açısına göre yapılıyor ve şirketlerin ileriye dönük teknoloji stratejisini -olumu veya olumsuz- mutlaka etkiliyor. 

Bulut sağlayıcısına karar vermek

 

Örneğin, bulut sağlayıcı seçimi… Genel bulut sağlayıcıların sunduğu hizmetlerin sağladığı kolaylıklar şüphesiz  benzersiz. Fakat herbiri dev teknoloji şirketlerine ait olan bu hizmetler bireysel geliştiriciler arasında viral olarak yayılması planlanarak pazarlanıyor. 

Doğal olarak,  üzerinde çalıştığı yazılımı geliştirme haricinde, sırtında alt yapı kurma ve operasyonları yönetme sorumluluğunu da taşıyan developerler, bu büyük sağlayıcıların güvenli konfor alanı vaadine kapılabiliyorlar.

Hizmeti satın aldıktan kısa bir süre sonra, kapasite arttırma ve bir sistemi yönetebilmek için gereken temel fonksiyonlara olan ihtiyaçlar ortaya çıkıyor. 

Developer, sağlayıcının sonsuz genişlikteki hizmet menüsünde sunulanları anlamak, aşırı karmaşık maliyet hesaplama araçlarından bir sonuç elde etmek ve  en doğru(?) seçimi yapabilmek için müthiş bir çaba ve zaman harcamaya başlıyor. 

Sonunda gücü tükeniyor ve bu sıkıntılı süreci kısaltmak ve geliştirmeye bir an önce geri dönebilmek için, ya ücreti karşılığı bir uzmana, ya da eşe dosta danışıyor. 

Fakat kime danışırsa danışsın,  uzun vadede kaçınılmaz olarak seçilen bulut hizmetinin astronomik maliyeti, ihtiyaç olduğunda muhatap bulunamaması, vendor lock-in problemi ve son zamanlarda yaşananlar gibi hizmet kesintisi gibi sorunlar ile yüz yüze geliniyor. 

Bu defa başta yapılan seçim hatasını telafi etmek için genel bulut sağlayıcısından çıkmak için çözümler aranıyor. 

Ancak ne yazık ki çoğu zaman bu, seçimi yapan developerin ve işletmenin baş edebileceğinden çok daha büyük başka problemlerin kapıları aralanıyor.

Dolayısıyla işletmelerin bulut stratejilerini belirlerken, genel bulut sağlayıcılarına sorgusuz sualsiz güvenip güvenemeyeceklerini ve ihtiyaçlarına göre nasıl bir altyapıya sahip olmaları gerektiğini, geliştiricilerle birlikte sistem yöneticileri ve güvenlik uzmanlarıyla beraber  karara bağlaması gerekiyor.

Mimari Seçimi Kararlarının Etkisi Daha Büyüktür

 

Diğer bir örnek mikro servis seçiminde yaşanıyor.

Yazışımınızı mikro servislere göre dizayn etmeniz oldukça zor ve maliyetli bir karar. Mikro servisler, geliştiricilerin üzerinde çalıştıkları kodlarını, tek bir yazılım parçasından değil daha küçük parçalardan oluşturması demek.

Mikroservis mimariye uygun yazılım geliştirmek istiyorsanız 12 Faktör manifestosunu okumanızı tavsiye ederim.

Mikroservisler, yazılımların ölçeklenebilirlik ve kullanılabilirlik sağlayan daha büyük sistemlerde düzenlenebilecekleri işlevsel birimlere ayrılmasını sağlar. 

Şüphesiz bu, Agile ve esneklik ihtiyacındaki geliştiriciler ve işletmeler için günümüz şartlarında önemli bir potansiyelin kapılarını açar.

Fakat bu tercih aynı zamanda, yönetmek, ağla ilgilenmek, güncellemek ve tutarlılık modellerini anlamakla ilgilenmeniz gereken, potansiyel olarak karmaşık bir dağıtılmış sisteme geçtiğiniz anlamına da gelir. 

İşletmenizin teknoloji mimarisinin gelişmesi için belki de en doğru yönü saptamış olursunuz, ancak bunun bireysel geliştiriciler tarafından yapılan bir seçimden ziyade stratejik bir karar olması gerekir. 

Yukarıda bahsedilen yanılsamalar bu seçim için de geçerlidir ve daha derin etkileri olabilir. 

Söz gelimi bireysel developerler, Startup’lar, küçük ve orta boy işletmeler için çoğu durumda Docker son derece yeterliyken, viralliği, popülerliği, büyük sağlayıcıların vaadleri vs. gibi bir çok nedenle developerler mikro servis tercihlerini Kubernetes’den yana kullanabilir. 

Bunu anlamak için Şenol Çolak’ın şu benzetmesi son derece yerindedir:

K8s seçimi şuna benzer:
Buradan bakkala gitmek istiyorum.
Çözüm: Uçak!
Berlin’den Shangai’ye gitmek istiyorum.
Çözüm: Uçak!”

Kısacası,  Kubernetes’in karmaşıklığı ve getirdiği yoğun iş yükü nedeniyle  kısa sürede büyük aksamalara ve içinden çıkılması çok zor durumlara neden olabilir. 

Kullanmaya karar verdiğiniz aracın yapısı itibariyle, işinizin ihtiyaçlarına değil, mecburen Kubernetes’in ihtiyaçlarını karşılamaya odaklanırsınız. 

Ne Yapılmalı

 

Şirketler açık kaynak ve diğer teknoloji seçenekleri için, geliştirici seçimlerini yönetmeye ve doğru politikaları belirlemeye yardımcı olacak araçlar ve uygulamalar aramalıdır.

Açık kaynaklı projeler için lisansları, kaynak konumları ve güvenlik sorunları takip edilmelidir.

DevOps döngüsü içinde kullanmayı seçeceğiniz tüm teknoloji bileşenlerinin, barındırdığı mühendislik, teknolojik yetenekler, kısa, orta ve ileri vadede büyümeye ve gelişmeye uygun olup olmadığı, potansiyel güvenlik açıkları, kurumsal olarak kimliği ve bağlantıları, herhangi bir kilitlenmeye neden olup olmadığı gibi bir çok bakımdan değerlendirilmesi gerekir.

Developer’lerin seçimleri elbette çok doğru, öncü ve vizyoner olabilir. Fakat şirketlerin teknoloji stratejileri, tek kişinin seçimlerine bırakılamayacak kadar detaylıdır. 

Operasyonların ve altyapının yönetimi, güvenlik ve API seçimleri  konusunda mümkünse SRE’ler (Site Reliability Engineer) ile çalışmak, onların seçimlerine kulak vermek gereklidir.

Çünkü burada söz konusu olan, geliştirdiğiniz yazılımın haricinde, işinizin her alanını etkileyen ve güvenmeniz gereken tedarikçileri bulmaktır.

2 thoughts on “Developerlerin Seçimleri Teknoloji Stratejinizi Nasıl Etkiler?”

  1. Bilgilendirici ve ufuk acici yazilariniz icin tesekkurler.
    Sizden ricam, karsiligi dilimizde bulunan yabanci kelimeler yerine Turkcelerini kullanmaniz.

    1. Merhaba,
      Güzel sözleriniz ve haklı eleştiriniz için teşekkürler. Türkçe dilinde kaliteli teknoloji içeriği üretmek için çabalıyor, elimizden geleni yapıyoruz, fakat bazen daha fazla dikkat etmemiz gerekiyor.

Şenol Çolak için bir cevap yazın Yanıtı iptal et

E-posta hesabınız yayımlanmayacak.

Kurumsal teknoloji trendlerinin her hafta tarafsız bir yorumunu edinmek ister misiniz?

Raporumuza Abone Olun