Önemli Noktalar
- Birkaç yıldır, sunucusuz bilgi işlemin, uygulamaları çalıştırmak için belirli bir işletim sistemi olmadan yeni bir çağ başlatacağı sözünü aldık. Bu yapının birçok ölçeklenebilirlik problemini çözeceği söylendi. Aslında her şey farklı.
- Birçok kişi sunucusuz çalışmayı yeni bir fikir olarak görse de kökleri, her ikisi de sunucusuz mimari kullanan Zimki PaaS ve Google App Engine'in ortaya çıktığı 2006 yılına kadar uzanıyor.
- Sunucusuz devrimin durmasının dört nedeni var; sınırlı programlama dili desteğinden performans sorunlarına kadar.
- Sunucusuz bilgi işlem o kadar da işe yaramaz değil. Hiç de bile. Ancak bunların doğrudan sunucuların yerini alması düşünülmemelidir. Bazı uygulamalar için kullanışlı bir araç olabilirler.
Sunucu öldü, yaşasın sunucu!
Bu, sunucusuz devrimin savaş çığlığıdır. Son birkaç yıldaki sektör basınına kısa bir bakış attığınızda, geleneksel sunucu modelinin öldüğü ve birkaç yıl içinde hepimizin sunucusuz mimarileri kullanacağı sonucuna varmak kolaydır.
Sektördeki herkesin bildiği gibi ve makalemizde de belirttiğimiz gibi , Bu yanlış. Esaslarla ilgili birçok makaleye rağmen , asla gerçekleşmedi. Aslında, bu devrimin çıkmaza girmiş olabileceği.
Sunucusuz modellere ilişkin vaatlerin bir kısmı kesinlikle gerçekleşti, ancak hepsi değil. Herkes değil.
Bu yazıda bu durumun nedenlerine bakmak istiyorum. Sunucusuz modellerin esnekliğinin olmayışı, belirli, iyi tanımlanmış durumlarda kullanışlı olmaya devam etmelerine rağmen neden hala daha geniş çapta benimsenmelerinin önünde bir engel oluşturuyor?
Sunucusuz bilişimin ustaları neler vaat ediyor?
Sunucusuz bilişimin zorluklarına girmeden önce, ne sağlaması gerektiğine bakalım. Sayıları çoktu ve zaman zaman çok hırslıydılar.
Bu terime aşina olmayanlar için işte kısa bir tanım. Sunucusuz bilgi işlem, uygulamaların (veya uygulama bölümlerinin) genellikle uzaktan barındırılan çalışma zamanı ortamlarında talep üzerine çalıştırıldığı bir mimariyi tanımlar. Ayrıca sunucusuz sistemler evde de barındırılabilir. Dayanıklı sunucusuz sistemler oluşturmak, son birkaç yıldır sistem yöneticileri ve SaaS şirketleri için büyük bir endişe kaynağı olmuştur; zira (iddia edildiği gibi) bu mimari, "geleneksel" istemci-sunucu modeline göre birçok önemli avantaj sunmaktadır:
- Sunucusuz modeller, kullanıcıların kendi işletim sistemlerini korumalarını ve hatta belirli işletim sistemleriyle uyumlu uygulamalar oluşturmalarını gerektirmez. Bunun yerine geliştiriciler paylaşılan kod oluşturur, bunu sunucusuz bir platforma yükler ve çalışmasını izler.
- Sunucusuz çerçevelerdeki kaynaklar genellikle dakika bazında (hatta saniye bazında) faturalandırılır. Bu, müşterilerin yalnızca kodu gerçekten çalıştırdıkları süre için ödeme yaptıkları anlamına gelir. Bu, makinenin çoğu zaman boşta olduğu ancak bunun için ödeme yapmanız gereken geleneksel bulut VM'ye kıyasla oldukça avantajlıdır.
- Ölçeklenebilirlik sorunu da çözüldü. Sunucusuz çerçevelerdeki kaynaklar, sistemin ani talep artışlarıyla kolayca başa çıkabilmesi için dinamik olarak atanır.
Kısacası sunucusuz modeller esnek, düşük maliyetli, ölçeklenebilir çözümler sunar. Bu fikri daha önce düşünmemiş olmamız şaşırtıcı.
Bu gerçekten yeni bir fikir mi?
Aslında fikir yeni değil. Kullanıcıların yalnızca kodun gerçekten çalıştığı süre boyunca ödeme yapmasına izin verme kavramı, tarafından tanıtıldığından beri ortalıkta dolaşıyor. 2006'da ve hemen hemen aynı sıralarda Google App Engine çok benzer bir çözüm sundu.
Aslında, şu anda "sunucusuz" dediğimiz model, artık "bulut yerel" olarak adlandırılan ve hemen hemen aynı şeyi sağlayan birçok teknolojiden daha eskidir. Belirtildiği gibi sunucusuz modeller aslında onlarca yıldır var olan SaaS iş modelinin bir uzantısıdır.
Her ne kadar ikisi arasında bir bağlantı olsa da sunucusuz mimarinin bir FaaS mimarisi olmadığını da bilmekte yarar var. FaaS aslında sunucusuz mimarinin bilgi işlem merkezli parçasıdır ancak sistemin tamamını temsil etmez.
Peki bu kadar yaygara ne için? Gelişmekte olan ülkelerde internet penetrasyon oranları hızla artmaya devam ederken, aynı zamanda bilgi işlem kaynaklarına olan talep de artıyor. Örneğin, hızla büyüyen e-ticaret sektörlerine sahip birçok ülke, bu platformlardaki uygulamalar için bilgi işlem altyapısına sahip değil. Ücretli sunucusuz platformların devreye girdiği yer burasıdır.
Sunucusuz Modellerle İlgili Sorunlar
Sorun şu ki, sunucusuz modellerin sorunları var. Beni yanlış anlamayın: Bunların başlı başına kötü olduğunu veya bazı durumlarda bazı şirketlere önemli bir değer sağlamadığını söylemiyorum. Ancak “devrimin” ana iddiası (sunucusuz mimarinin hızlı bir şekilde geleneksel mimarinin yerini alacağı) hiçbir zaman hayata geçmiyor.
Bu yüzden.
Programlama dilleri için sınırlı destek
Sunucusuz platformların çoğu yalnızca belirli dillerde yazılmış uygulamaları çalıştırmanıza izin verir. Bu, bu sistemlerin esnekliğini ve uyarlanabilirliğini ciddi şekilde sınırlamaktadır.
Sunucusuz platformların çoğu ana dili desteklediği kabul edilir. AWS Lambda ve Azure Functions ayrıca desteklenmeyen dillerde uygulama ve işlevlerin çalıştırılmasına yönelik bir sarmalayıcı sağlar; ancak bu genellikle bir performans maliyetiyle birlikte gelir. Dolayısıyla çoğu kuruluş için bu sınırlama genellikle önemli değildir. Ama olay şu ki. Sunucusuz modellerin faydalarından birinin, az bilinen, nadiren kullanılan programların daha ucuza kullanılabilmesi, çünkü yalnızca çalıştıkları süre için ödeme yapmanızdır. Ve az bilinen, nadiren kullanılan programlar genellikle... az bilinen, nadiren kullanılan programlama dillerinde yazılır.
Bu, sunucusuz modelin temel faydalarından birini zayıflatır.
Satıcı bağlayıcılığı
Sunucusuz platformlarla veya en azından şu anda uygulanma biçimleriyle ilgili ikinci sorun, bunların genellikle operasyonel düzeyde birbirine benzememesidir. Yazma işlevleri, dağıtım ve yönetim açısından pratikte hiçbir standardizasyon yoktur. Bu, özellikleri bir platformdan diğerine taşımanın son derece zaman alıcı olduğu anlamına gelir.
Sunucusuz bir modele geçmenin en zor kısmı, genellikle yalnızca kod parçacıkları olan bilgi işlem işlevleri değil, uygulamaların nesne depolama, kimlik yönetimi ve kuyruklar gibi bağlı sistemlerle nasıl iletişim kurduğudur. İşlevler taşınabilir ancak uygulamanın geri kalanı taşınamaz. Bu, vaat edilen ucuz ve esnek platformların tam tersidir.
Bazıları sunucusuz modellerin yeni olduğunu ve çalışma şekillerini standartlaştırmaya zaman olmadığını savunuyor. Ancak yukarıda belirttiğim gibi o kadar da yeni değiller ve konteynerler gibi diğer birçok bulut teknolojisi, iyi standartların geliştirilmesi ve yaygın olarak benimsenmesi sayesinde zaten çok daha kullanışlı hale geldi.
Proizvoditelnost
Sunucusuz platformların bilgi işlem performansını ölçmek zordur, bunun nedeni kısmen satıcıların bilgileri gizli tutma eğiliminde olmasıdır. Çoğu kişi, birkaç kaçınılmaz gecikme sorunu dışında, uzak, sunucusuz platformlardaki işlevlerin, dahili sunuculardakiler kadar hızlı çalıştığını savunuyor.
Ancak bireysel gerçekler bunun tersini gösteriyor. Daha önce belirli bir platformda çalışmayan veya bir süredir çalışmayan özelliklerin başlatılması biraz zaman alacaktır. Bunun nedeni muhtemelen kodlarının daha az erişilebilir bir depolama ortamına taşınmasıdır, ancak karşılaştırma testlerinde olduğu gibi çoğu satıcı size veri geçişi hakkında bilgi vermez.
Elbette bunun birkaç yolu var. Bunlardan biri, sunucusuz platformunuzun üzerinde çalıştığı bulut dili ne olursa olsun özellikleri optimize etmektir, ancak bu, bu platformların "çevik" olduğu iddiasını bir şekilde zayıflatmaktadır.
Diğer bir yaklaşım ise üretkenlik açısından kritik programların güncel kalmasını sağlamak için düzenli olarak yürütülmesini sağlamaktır. Bu ikinci yaklaşım elbette sunucusuz platformların daha uygun maliyetli olduğu, çünkü yalnızca programlarınızın çalıştığı süre için ödeme yaptığınız iddiasıyla biraz çelişmektedir. Bulut sağlayıcıları, soğuk başlatmaları azaltmak için yeni yollar sundu ancak bunların çoğu, FaaS'ın orijinal değerini zayıflatan "bire ölçeklendirme" gerektiriyor.
Soğuk başlatma sorunu, sunucusuz sistemleri şirket içinde çalıştırarak kısmen çözülebilir, ancak bunun kendi maliyetleri vardır ve iyi kaynaklara sahip ekipler için niş bir seçenek olmaya devam etmektedir.
Uygulamaların tamamını çalıştıramazsınız
Son olarak, sunucusuz mimarilerin yakın zamanda geleneksel modellerin yerini alamayacak olmasının belki de en önemli nedeni: (genellikle) uygulamaların tamamını çalıştıramamaları.
Daha doğrusu maliyet açısından pratik değildir. Başarılı monolitiniz muhtemelen sekiz ağ geçidi, kırk kuyruk ve bir düzine veritabanı örneğiyle birbirine bağlanan dört düzine işlevden oluşan bir diziye dönüştürülmemelidir. Bu nedenle sunucusuz yeni gelişmelere daha uygundur. Neredeyse hiçbir mevcut uygulama (mimari) taşınamaz. Geçiş yapabilirsiniz ancak sıfırdan başlamanız gerekir.
Bu, çoğu durumda sunucusuz platformların, yoğun bilgi işlem gerektiren görevleri gerçekleştirmek için arka uç sunucuların tamamlayıcısı olarak kullanıldığı anlamına gelir. Bu onları, uzaktan bilgi işlem gerçekleştirmek için bütünsel bir yol sunan diğer iki bulut teknolojisi türünden (konteynerler ve sanal makineler) çok farklı kılar. Bu, mikro hizmetlerden sunucusuz hizmetlere geçişin zorluklarından birini göstermektedir.
Elbette bu her zaman bir sorun değildir. Kendi donanımınızı satın almanıza gerek kalmadan, devasa bilgi işlem kaynaklarından periyodik olarak yararlanma yeteneği, birçok kuruluşa gerçek, kalıcı faydalar sağlayabilir. Ancak bazı uygulamalar dahili sunucularda, diğerleri ise sunucusuz bulut mimarilerinde bulunduğunda, yönetim yeni bir karmaşıklık düzeyine ulaşır.
Çok yaşa Devrim?
Tüm bu şikayetlere rağmen sunucusuz çözümlere bizzat karşı değilim. Açıkçası. Geliştiricilerin, özellikle de sunucusuz sistemi ilk kez keşfediyorlarsa, teknolojinin doğrudan sunucuların yerini alamayacağını anlaması gerekir. Bunun yerine ipuçlarımıza ve kaynaklarımıza göz atın. ve modelin en iyi nasıl uygulanacağına karar verin.
Kaynak: habr.com