Yazılım Sektöründe Ölçekleme Tuzağı

Yazılım ürününüz gittikçe daha çok kullanılıyor. Yeni sunucular kullansanız, yeni servisler alsanız yazılımınız daha performanslı çalışacak. Yeni çıkaracağınız ürün ya da özellik piyasayı sallayacak o yüzden en büyük paketi almalısınız. Yazılım ekibiniz kalabalık olsa sorunları daha hızlı çözeceksiniz. Ofisiniz daha büyük olsa daha verimli çalışacaksınız . . .

Dur yolcu! Bilmeden gelip bastığın bu toprak sayıların konuştuğu yerdir

İşinizi büyütmek istiyorsunuz, bu çok normal. Peki işinizi büyütürken ihtiyacınız olmayan yazılım, donanım, reklam, personel, ofis gibi şeylere kaynaklarınızı gereksiz yere harcamamak için, yani ölçekleme tuzağına düşmemek için, nelere dikkat etmelisiniz?

En büyük düşmanınız Tahminler. Elinizde sayılar yoksa durun ve derin bir nefes alın. Elinizdeki imkanlarla olabildiğince sayılara ulaşmaya çalışın. Eğer istediğiniz sayılara ulaşamıyorsanız ürününüze sayılara ulaşmak için gereken özellikleri ekleyin ve elinizde yeterli miktarda sayı olana kadar kararınızı vermeyin. Örneğin ürününüzde hangi özelliğin daha çok kullanıldığına dair elinizde sayılar var mı? Yoksa sadece tahminler mi var? Yeni geliştirmek istediğiniz özellik için kullanıcılarınıza anket yaptınız mı, kaçı bu özelliği kullanırım diyor, kaçı bunun için bir ücret ödemeye hazır?

Ölçmelisin ölçebildiğin her şeyi

Önceliklendirme ve risk analizi yapın.
Neler vazgeçilmez, neler feda edilebilir? Hizmet kesintisi yaşanmaması, veri kaybı olmaması, yazılımın  hızlı çalışması, istenen özelliğin geliştirilmesi, hataların düzeltilmesi . . . Hangisi daha önemli? Ne kadar veri kaybı işinizi tehlikeye sokar? 10 dakikalık kesinti ne kadar trafik kaybına neden oluyor? Bana sayılarla gelin.

Sorunu doğru tespit edin. Örneğin veri tabanında yaşanan ani yük yazılımsal bi hatadan dolayı mı, mimari bir yanlış mı, index yapısı mı yanlış, yoksa unutulmuş zamanlanmış bir görev mi var? Sorunun kaynağına odaklanmadan daha fazla işlemci ve bellek için para harcayarak sorunun etrafından dolaşmış olursunuz. Etrafından dolaştığınız sorun kapınızı yeniden çalacaktır. Hataları yeterince hızlı çözemiyorsanız yazılım ekibini büyütmek yerine önce kullandığınız araçları ve metodolojiyi inceleyin. Yeni sunucu kullandığınızda yazılımınızın performansı ne kadar artacak ya da artacak mı? Yeni sunucu için para ve zaman olarak ne kadar kaynak harcayacaksınız? Bu sunucuyu yönetmek için yeni teknolojiler gerekecek mi? Mevcut yazılımın ölçeklemeye uygun hale getirilmesi için neler gerekli? Kullanmak istediğiniz API servislerinde gecikmeler var mı? Kaynak harcamadan önce karşılaşabileceğiniz sorunları iyice araştırın.

Sorunu doğru çözün. Veri tabanında yaşanan ani yükün unutulmuş zamanlanmış bir görevden kaynaklandığını tespit ettiniz. Zamanlanmış görevin çalışma saatini değiştiriniz ve sorun çözüldü. Öyle mi? Peki bu zamanlanmış görev çalışırken neden fazla kaynak tüketiyor? Bu zamanlanmış görev gerçekten gerekli mi yoksa eskiden mi gerekliymiş? Bu görevin bakımı neden yapılmamış, ekip işin mi aksatıyor, yazılım metodolojiniz mi yanlış? Unutulmuş ama fazla kaynak tüketmediği için dikkatinizi çekmeyen başka görevler olabilir mi? Bu görev için dokümantasyonda açıklama var mı varsa güncel mi? Bu zamanlanmış görevin yerini yeni teknolojiler ile başka bir etkili çözüm alabilir mi?

Ey reklam kurtar beni! Kullanıcı kaybediyorsanız yeni reklamlar ve kampanyalardan önce bunun gerçek nedenini bulun. Sizi terkeden kullanıcılar ürününüz yavaş diye mi sizi terkediyor yoksa istedikleri özellikleri sizde bulamadıkları için mi . . . ? Sisteminize kullanıcı davranışlarını için size rakalmlar verebilecek analitik araçlar ekleyin. Sizi terkeden kullanıcılarınızı arayın ve sorun. A/B testleri yapın. Yeni kullanıcılar kazanmak için reklam yapacaksanız etkili reklam yollarını araştırın. Örneğin Google AdSense ile gelen kullanıcıların yüzde kaçı web sitenizde yeterli süre kalıyor, yüzde kaçı üye oluyor? Facebook'a reklam vermek işinizin sektörü için uygun mu? Promosyon kalem ve kupa yaptırmak size ne sağlıyor? Para ile röportaj yaptırmak faydalı mı?

Fazla mühendisleştirmek! (Over engineering) Küçük bir projeyi baştan itibaren büyük trafik ve veriyi kaldıracak bir şekilde tasarlamak gerçekten gerekli mi? Projenin birden fazla bölgedeki sunucularda eş zamanlı olarak çalışması gerçekten bir ihtiyaç mı? Kodların gereğinden fazla soyut yazılması gerekli mi? Bu kodların anlaşılmasını ve bakımını zorlaştırır, azda olsa performansı düşürür. Kullanıcı ihtiyacını çözecek, bakımı ve geliştirmesi kolay, teknik borcu olmayan bir tasarım için sürekli kendinizi sorgulamalısınız.

Hype'lara kandım ben! Çıkan yeni teknolojiler aklınızı mı çeliyor, sorununuzu çözecek sihirli değnek mi buldunuz? Yeni teknolojiler kullanmak hem sizin hem de yazılım ekibinizi motive edecektir ama her yeni teknoloji öğrenme çabası gerektirir ve yeni teknolojinin olgunlaşması zaman alabilir. Yeni teknolojileri mevcut yazılım ürününüze dahil etmeden önce, kullanıcı ihtiyacını çözme konusunda yeni teknolojiler ile yeni ürünler yapıp yapamayacağınızı araştırın. Bazen yeni teknolojinin mevcut projeye dahil edilmesi sıfırdan bir proje yapmaktan daha maliyetli olabiliyor.

Güvendiğim dağlara kar yağdı. Amazon AWS, Microsoft Azure, Google Cloud gibi bulut hizmet sağlayıcılarında hizmet kesintisi olmaz mı? Sunucu barındırma hizmeti aldığınız firmada kesinti olmaz mı? Türkiye'nin yurt dışı bağlantısında sıkıntı olmaz mı? Güvenlik önlemleriniz tam olsa bile DDOS saldırısına maruz kalabilir misiniz? Sunucularda gürültücü komşular nedeniyle trafik yavaşlayabilir mi? Bunların hepsi olabilir. Ölçekleme ve replikasyon ile çözemeyeceğiniz problemler olacaktır. Teknik konularda ölçekleme belli bir seviyeye kadar ürününüzün kalitesini artıracaktır. Daha sonra ürününüzün kalitesini belirleyen unsur firmanızın kriz yönetimi politikaları ve becerileri olacaktır. Her zaman teknik konularda yedek planlarınız olmalıdır, özel günlerde ve belli periyotlarda artacak olan trafik için önlemler alınmalıdır, yük testleri yapılmalıdır, otomatik ölçekleme sistemleri kullanılmalıdır. Kriz anında kimin neye müdahale edeceği, kullanıcılarla nasıl iletişim kurulacağı, yedek sistem ve servislerin devreye nasıl alınacağı belirlenmelidir.

Ekip büyüsün işler çözülsün. İlk adım olan iş ilanı açmak bile tahmininizden fazla zaman ve para isteyecektir. Adaylar ile iletişim kurmak, görüşme ayarlamak, mülakatlar yapmak sizin en değerli kaynağınız olan zamanınızı alacak. Uygun adayları belirlemek, onları kazanmaya çalışmak, teklif verdiğiniz bazı adayların cevap bile atmadığını görmek . . . ve en sonunda işe aldığınız kişinin firma kültürüne ve kodlama tarzına ayak uydurması enerjinizi alacak.

Ofisinizi büyütmek aklınıza gelen ilk seçeneklerden biri. Firma kültürünü daha iyi yansıtacak, gelen misafirleri etkileyecek, personeli rahatlatacak bir ofis ya da binayı herkes ister. Büyük bir ofisin verimliliğinize ne kadar katkı sağlayacağını rakamlarla ifade edebilmek pek mümkün değil. Yazılım sektöründe koca koca firmalar evden çalışma seçeneğine yönelirken ofis için kaynak harcamayı iyice gözden geçirmek gerekiyor. İşler kötüleştiğinde ofis maliyetleri ciddi bir gider kalemi olabilir.

Kiralama seçeneğini satın alma seçeneğinden önce değerlendirin. Satın aldığınız her şey bakımıyla hatta en sonunda satış süreciyle sizi asıl işinizden uzaklaştıracak. Ayrıca satın alma işlemiyle daha fazla nakit para çıkışı yaşanacaktır.

Uzun lafın kısası kaynak harcamadan önce iyice araştırın, sayılarla karar verin. Para harcamak sihirli bir değnek değil, sorunu doğru tespit edin ve sorunu doğru çözün.

Yorumlar

Bu blogdaki popüler yayınlar

KPSS Çalışan Yazılımcı

On-Prem Çilesi

Yeteneğini Kaybeden Yazılımcı