Modern yazılım geliştirmenin talepleri, programcılardan daha fazla kod yazmalarının ve yeni işlevleri her zamankinden daha hızlı sunmalarının istendiği anlamına geliyor. “Tekerleği yeniden icat etmemek” atasözü, birçok kişiye kodu hızlı ve çoğu durumda güvenilir bir şekilde sunmak için ihtiyaç duydukları kısayolları verdi.
Bir yazılım geliştiricisinin sıfırdan bir şey yazmak yerine, bir programlama kitaplığında veya kaynak kod deposunda uygun bir şey bulması zorunludur. Günümüzde geliştiriciler mikro hizmetlerin kapsadığı güçten yararlanma seçeneğine de sahip.
Mirantis’in baş teknoloji sorumlusu Shaun O’Meara’nın açıkladığı gibi, mikro hizmetler, yazılım geliştirici ile istenen işlevselliğe ulaşmak için gereken kod arasındaki ilişkiyi kökten değiştiriyor: “Geçmişte, genellikle bir geliştiriciniz veya yazılım geliştiren küçük bir geliştirici ekibiniz vardı. Sistemin her bir bileşeni, her biri farklı bileşenler üzerinde çalışmayı kabul ediyor.”
Ekibin her şeyi sıfırdan oluşturması gerektiğini ancak yazılım kitaplıkları kullanıma sunulduğunda geliştiricinin önceden oluşturulmuş işlevsellikten yararlanabildiğini söylüyor. Mikro hizmetlerle ilgili en büyük değişiklik, yazılım geliştiricilerin zihniyetinin değişmesidir; artık başkaları tarafından geliştirilen çalışmaları tüketebiliyorlar ve bunu yaparak üretkenlikte büyük kazançlar elde edebiliyorlar.
Bunun etkisi, mikro hizmetleri kullanan kodun, daha geleneksel bir şekilde geliştirilen koda göre daha fazla miktarda BT altyapısı tüketme eğiliminde olması olduğunu söylüyor.
Kodlamada verimsizliğin yükselişi
Verimsizlik artık yazılım geliştirmede olağan bir durum. Canterbury Christ Church Üniversitesi’nin baş teknoloji sorumlusu Andy Powell, “Modern araçlar insanları tembelleştirdi” diyor. “Ben web siteleri yazarken – bu .Net ortaya çıkmadan önceydi ve klasik ASP’deydi [active server pages] – tüm nesnelerinizi kendiniz yazmanız gerekiyordu.”
İnsanlar düşük bant genişliğine sahip çevirmeli modem bağlantısı aracılığıyla web sitelerini ziyaret ettiğinde şunları söylüyor: “Görüntünün boyutu, stil sayfaları ve sayfa boyutları konusunda bilinçli olmanız gerekiyordu; Yükleme süresi önemli olduğundan, kanala ne kadar veri gönderdiğinizin bilincinde olmanız gerekiyordu.”
Powell’a göre uygulama geliştirme açısından bakıldığında bu, geliştiricilerin kod verimliliğini dikkate aldığı anlamına geliyordu. “Veritabanı katmanı ve API’niz konusunda gerçekten verimli olmanız gerekiyordu [application programming interface] katman” diyor.
İşlem sistemlerine yapılan sorgular, minimum geçerli veri kümesini döndürecek şekilde yazıldı; oysa şimdi şunu söylüyor: “100.000 kayıt veya tuple alıyorsunuz ve buradan ne istediğinizi seçerek yola çıkıyorsunuz” [dataset] bellek içi çünkü bellek çok ucuzladı.”
Kod şişkinliğiyle mücadele
Günümüzde geliştiriciler bant genişliğini neredeyse sınırsız bir kaynak ve işlem gücü olarak ele alıyor ve bellek ve depolama hem ucuz hem de bol miktarda bulunuyor. Bu durum, geliştiricilerin artık mümkün olduğu kadar verimli çalışan ve en küçük depolama, bellek ve işlem gücü ayak izini kullanan yazılım yazmaya odaklanmamasına neden olan kod şişmesine yol açtı.
Tricentis’in baş ürün ve strateji sorumlusu Mav Turner, kod şişkinliğinin genellikle aşırı ayrıntılı sözdizimi, gereksiz veya kullanılmayan özellikler ve geliştirme sırasında optimizasyon eksikliği gibi çeşitli kaynaklardan kaynaklandığına dikkat çekiyor. Ek olarak, eski kod tabanlarının zamanla teknik borç biriktirebileceğini, bunun da şişirilmiş ve karmaşık uygulamalara yol açabileceğini söylüyor.
Ancak Turner’ın açıkladığı gibi: “Geliştiriciler, temiz kodlama uygulamalarını, modüler tasarım ilkelerini ve düzenli yeniden düzenlemeyi benimseyerek kod şişkinliğini azaltabilir ve daha yalın, daha yönetilebilir kod tabanlarını koruyabilirler.”
BT liderlerinin, kod geliştiricilerin daha az verimli yazmasına neden olan faktörleri ve etkenleri dikkate alması gerekir. “Kimse kodun şişirilmesini istemez. Geliştiriciler çevreyi yok etmeye çalışmıyorlar” diyor Qt ürün müdürü Maurice Kalinowski.
Ancak Kalinowski’nin de belirttiği gibi, kasıtsız verimsizliklere neden olan çok sayıda faktör var. Örnek olarak şunu söylüyor: “Genellikle geliştirme ekiplerini kısa teslimat döngülerine zorlayan zaman baskısından dolayı prototipler bir üründe ortaya çıkıyor. Bu, geliştirme yaşam döngüsünün ilerleyen aşamalarında teknik borca yol açıyor ve bu da verimliliğe zarar veren zincirleme bir etkiye sahip.”
Kalinowski’ye göre geliştirilecek kodun uygulama alanı ve kullanım senaryosunun dikkate alınması önemli. “’Genel amaçlara’ yönelik kod geliştiriyorsanız, giriş verilerinin anlamsal kontrole ihtiyacı var mı? Kod, hiçbir zaman gerçekleşmeyecek olanlar da dahil olmak üzere tüm olası senaryoları kapsıyor mu?”
Yüksek verimli kod bile farklı kontrol ve işleme gerektiren ek kullanım durumlarına maruz kalabilir. Kalinowski, bunun, bu istisnaları desteklemek için kodun yazıldığı giderek daha fazla duruma yol açtığı konusunda uyarıyor. Bunlar biriktikçe kod, başlangıçta tasarlanan performans avantajlarının kaybolabileceği bir noktaya ulaşır.
Kalinowski, BT liderlerinin kodun şişirilmiş kısımlarını yeniden düzenlemeyi düşünmesi gerektiğini söylüyor. “Elbette öncelikle hangi projelerinizin şişirildiğini bilmeniz gerekiyor. Statik ve dinamik kod analizi, profil oluşturma ve gelişmiş örnekleme gibi birçok geliştirici aracının devreye girdiği yer burasıdır” diye ekliyor.
Testlerdeki verimsizlikler
Tricentis’ten Turner, BT karar vericilerini sürdürülebilir bir BT metodolojisi olarak test odaklı geliştirmeyi (TDD) benimsemeye çağırıyor. Deneyimine göre TDD, daha yüksek kalite ve verimlilikle karakterize edilen yeşil kodun oluşturulmasına önemli ölçüde katkıda bulunabilecek güçlü bir teknik sunuyor.
Turner, “Kod yazmadan önce testlerin oluşturulmasını vurgulayan TDD, geliştiricilerin kodlarının beklenen davranışını ve işlevselliğini en başından itibaren net bir şekilde anlamalarını sağlıyor” diyor.
Uygulama geliştirme sırasındaki testlere bakıldığında, TCS Birleşik Krallık ve İrlanda’da inovasyon başkanı Ved Sen, BT liderlerinin regresyon testinin çevresel etkisini de dikkate alması gerektiğini söylüyor.
“Regresyon testlerini çalıştırdığınızda, sırf programın bozulup bozulmadığını görmek için birçok şeyi tekrar tekrar test etmek zorunda kalırsınız” diyor. “Fakat her regresyon testi yaptığınızda, daha fazla kaynak tüketiyorsunuz ve bunların her biri bir miktar karbon ayak izi oluşturuyor.”
Sen’e göre, geliştiricilerin aynı kullanım senaryosunu tekrar tekrar test etmeye devam etmelerine gerek kalmaması için daha akıllı test yöntemleri oluşturmak mümkün olmalı.
Sen, yazılım geliştiricilerin kaba kuvvet testi yapmaktan kaçınmaları halinde, BT testi ve geliştirme ortamının ayak izini küçük ama önemli miktarda azaltabileceklerini, bunun da BT’yi daha çevreci ve daha az karbon yoğun hale getirme konusunda kümülatif olarak daha büyük bir etki anlamına geldiğini belirtiyor.
BT liderleri, kodlamanın ötesinde, geliştiricilerinin ihtiyaç duyduğu yazılım geliştirme ve test ortamlarının genel çevresel etkisini ele almaya da bakabilir.
Mart ayında Paris’te düzenlenen KubeCon + CloudNativeCon’da konuşan Deutsche Bahn’ın platform etkinleştirme ve strateji baş danışmanı Gualter Barbas Baptista, demiryolu operatörünün bulut tabanlı uygulamalarının ekolojik etkisini izleme ve en aza indirme yönünde devam eden çabalarını anlattı. Baptista, geliştiricilerin güçlendirilmesinden bahsetti ve yazılım geliştiricilerini, yazılıma ne konulduğu açısından “etkili bir şekilde günlük karar vericiler” olarak tanımladı.
“Geliştiricilerle etkileşime geçmezsek ve onlara gerekli araçları vermezsek, kod geliştirme ve altyapıyı yönetme şeklimizde bir değişiklik yapamayız” diyor.
Geçtiğimiz birkaç yılda Deutsche Bahn, standardizasyonu uygulamak için tüm yan kuruluşları birleştirmeye odaklandı. Bunun, “etkilerden yararlanabileceğimiz ve daha yüksek düzeyde standardizasyon sağlayabileceğimiz” anlamına geldiğini söylüyor.
Kubernetes, Deutsche Bahn’da kullanılan platform oluşturma aracıdır. İzleme, BT yöneticilerinin işlemci kullanımını görmesine ve konteyner iş yüklerini otomatik olarak ayarlayarak bunları iş yüklerinin ihtiyaçlarına göre optimize etmesine olanak tanır.
Planlama aynı zamanda Deutsche Bahn’ın, geliştiriciler çalışmadığında geliştirici ve test ortamlarının uyku moduna alınabilmesini sağlamasına yardımcı olmak için de kullanılıyor; bu da işlem gücünden tasarruf sağlıyor.
Yapay Zekayı Yeşillendirme
BT ortamı sürekli olarak gelişmektedir, bu da BT sürdürülebilirliğinin hareketli bir hedef olduğu anlamına gelmektedir. KubeCon + CloudNativeCon etkinliğindeki bir panel tartışmasında RedHat OpenShift’in doğrudan ürün pazarlama sorumlusu Chuck Dubuque, yapay zekanın (AI) Kubernetes’i daha önce olmadığı bir yere götürdüğü konusunda uyardı.
“Bir uygulamaya yapay zeka eklediğinizde güç kullanımını 10 kat artırırsınız” dedi.
SmartR AI CEO’su Oliver King-Smith, yapay zekayı daha yeşil hale getirmeye yönelik yaklaşımlara bakarak, araştırmacıların modelin yeniden kullanımı, ReLora, Uzmanların Karışımı (MoE) modelleri ve nicemleme gibi yapay zeka yapımı ve kullanımına yönelik etkili yöntemler geliştirdiğini söylüyor.
Modelin yeniden kullanımını tartışan King-Smith, tekniğin halihazırda eğitilmiş bir modelin yeni bir amaç için yeniden eğitilmesini içerdiğini, sıfırdan eğitime kıyasla zaman ve enerji tasarrufu sağladığını söylüyor. “Bu yaklaşım yalnızca kaynakları korumakla kalmıyor, aynı zamanda çoğu zaman daha iyi performans gösteren modellerle de sonuçlanıyor” diyor. “Hem Meta hem de Mistral, yeniden kullanılabilecek modelleri piyasaya sürme konusunda iyi davrandılar.”
ReLora ve Lora’ya bakan King-Smith, bunların modelleri yeni kullanımlar için yeniden eğitirken gereken hesaplama sayısını azaltmak için tasarlandığını söylüyor. Bu, enerji tasarrufu sağlar ve daha küçük, daha az güç harcayan bilgisayarların kullanılmasına olanak tanır. “Bu, Nvidia’nın DGX’i gibi büyük, enerji yoğun sistemlere güvenmek yerine, mütevazı bir grafik kartının yeniden eğitim için genellikle yeterli olabileceği anlamına geliyor” diyor.
Mistral tarafından yakın zamanda piyasaya sürülenler gibi MoE modelleri, geleneksel modellere göre daha az parametreye sahiptir. King-Smith bunun daha az hesaplama yapılmasına ve enerji tüketiminin azalmasına yol açtığını söylüyor. “MoE modelleri, tıpkı kullanılmayan odalardaki ışıkları kapatmak gibi, yalnızca kullanım sırasında gerekli blokları etkinleştirerek enerji kullanımında %65’lik bir azalmaya yol açıyor.”
King-Smith, nicelemeyi yapay zeka modellerinin boyutunu küçülten bir teknik olarak tanımlıyor. “Bir modeli nicelemek, her bir parametreyi temsil etmek için gereken bit sayısını azaltır. Bu, model boyutunu küçülterek daha az güçlü ve enerji açısından daha verimli donanımların kullanılmasına olanak tanıyor” diyor.
Nicelemenin model doğruluğu üzerinde küçük bir etkisi olsa da King-Smith, birçok pratik uygulamada bu ödünleşimin fark edilmediğini iddia ediyor.
Kod şişkinliğiyle mücadele etmek ve gereksiz düzeydeki regresyon testi, kodlamayı daha yeşil hale getirmeye yardımcı olur. Daha verimli mikro hizmetler veya algoritmalar kullanma seçenekleri de vardır. Ancak sektör uzmanları arasındaki genel fikir birliği, yazılım geliştiricilerin alıştığı bir şeyi değiştirmenin çok zor olduğu yönünde.
Mirantis’ten O’Meara, yazılım geliştirmede yeşil BT’yi BT altyapısı perspektifinden ele alma fırsatını görüyor. “Karmaşıklığı ortadan kaldırabilir ve yalnızca gerekli olan BT altyapısı bileşenlerini sunabilirsek, tüm BT altyapısında ince bir katman oluşturabiliriz” diyor.
Kubernetes, yazılım geliştirme ve test ortamlarının BT kaynaklarını gereksiz yere kullanmamasını sağlamak için de kullanılabilir.
Bu tür teknikler BT altyapısının hafif ve enerji açısından verimli olmasını sağlar. Qt’dan Kalinowski’nin işaret ettiği gibi benzer bir teknik, geliştirilmekte olan kodun ele alması gereken istisnalara yol açan farklı senaryoların sayısını azaltmak için kodlamada kullanılabilir.