şükela:  tümü | bugün
  • ozunde mantiklida olsa oldukca "genc"* olan bir "sistemimsi" sey. ha bulut bilisime giriyor kafayi yormamak lazim.

    tamamen 0 dan baslayan bir sistem icin uygun olmasina olan; fakat mevcut, sistemi oturmus firmalarda pekte kullanisli olmayan hede.

    bunun birsuru nedenleri var; fakat nedenlerinden oturu, once serverless sistemin calisma prensibi nedenine bakarsak:

    1) microservices de teknik olarak limitleyen hic bir durum yokken; bu sistemde, yazilan kod sadece bir sey icin yazilmak zorunda. bu konuda zorlama var.

    2) yazilan kod, application lifecycle'dan bagimsiz yaziliyor. yani, infrastructure dedigimiz, yazilimin altyapisi ile ilgili hic birsey icermiyor.

    3) ucretlendirme, sure ve bellek kullanimi uzerinden yapiliyor. hani universitede comptuational complexity konusu vardi, orda hem computational hemde bellek olarak hesapladigimiz runtime complexity si vardi ya, iste o burda cok ise yariyor.

    ozetle bu 3 ana prensipten dolayi, serverless size, hizli calisan, tek bir gorevi olan (sonucta yazdigimiz kodun ana bir metodu i/o isleyecek) bir sey yazmanizi; ama multi-thread, stateful (sonucta paylasilan bir bellek yok), fault-tolerant, uygulama konfigurasyonu, ozel monitorleme sistemleri, interceptorlar, db pool, circuting gibi konularda ise hicbir sekilde kullanilmasina musait degildir.

    fault-tolerant olayina girersek sundan oturu. yazdiginiz kod basit olmali, eger bir hata olustuysa, bu hatayi duzeltmek yerine (misal exception u handle etmekten oturu) dogrudan bu execution u fail etmek daha mantiklidir. zira fail olan bu serverless execution, bu execution u cagiran neyse, onun tarafindan tekrar denenmelidir.

    tum bunlarin ustune, serverless sistem, sizin elinizden kontrolu daha cok aldigi icin, yarin bir gun dur amazondan google a geceyim dediginizde ortada kalmaniza yol acabilir. bence kismen, aws tarafindan bu kadar desteklenmesinin ana nedeni bu.

    bu arada zaman olayina deginmek istiyorum; misal aws de 100ms ve katlari olarak ucretlendirme yapiliyor; default timeout ise 60 saniye. max olarak ise bu sure 5 dk ye kadar cikabiliyor. yani kesinlikle; back-off vs tarzi bir sey yazmaya musait degil.
  • gecen ay milyor request karsilayan servislerimizi buna(aws lambda olani) tasidik.

    durum neydi
    bizim halihazirda ec2 uzerinde dockerize edilmis 20'ye yakin mikroservisimiz vardi. bu servisler restfull api'lar ve email gonderen, rapor hazirlayan, fatura filan olusturan ve gerekli gereksiz bir suru seyler yapan workerlardan olusuyordu. tum yapi jenkins uzerine kurguladigimiz ci/cd pipelinelari ile deploy aliniyordu.
    tum servislerimizi handlerlara ayirip integration + unit testleri ivir ziviriyla lambdaya tasimamiz 2 backend developerin 2 haftasini aldi. burda bir parantez acmak lazim, workerlarin hepsi halihazirda sqs ve onun nimetlerinden faydalaniyorlardi. yani baska durumlarda atiyorum redis kullanan bir queue workeriniz varsa ve onuda lambdaya tasiyacaksaniz burda baska refactoring maliyetlerini hesaba katmak lazim. iki developerda serverless hakkinda daha once pek bisey bilmiyorlardi bu iki haftaya yolda ogrenme suresinide katabilirsiniz.

    avantajlar

    1. aylik 20k dolares olan aws ec2 masraflarimiz 1k seviyelerine dustu. bu ne yazikki sadece lambdanin marifeti degil. infra tarafinda bazi seyleri yanlis bicimlerde cozmeye calismamizdan kaynaklaniyordu. isimiz geregi surekli degisken ve ongorulemez bir trafigi karsilayan, gelen tum requestlere gercek zamanli cevap vermek zorunda olan servislerimiz var. tum bu ongorulemez durumlarin yarattigi stres ve gecmiste ekibin yasadigi tatsiz tecrubeler bazi noktalarda gereginden fazla guclu cozumler kullanilmasina neden olmustu. herkes icin boyle dramatik bir dusus beklemek muhtemelen hayal olur.

    2. mikroservisleri lambdaya deploy almak cok basit. cok az bi ugrasla endpointlerinizi handlerlara paylastirip deploy alabiliyor halihazirdaki kodunuzu cok degistirmeden kullanmaya devam edebiliyorsunuz.

    hatta halihazirda yazilmis monolitik bir uygulamayida oldugu gibi tek parca halinde bir fonksiyon olarak tanitip deploy alabilirsiniz. he diyebilirsinizki benim 50 tane endpointi olan soyle boyle seyler yapan bir servisim var nasil bunu 3gb lik(tarih itibariyle en buyuk memoryli lambda) bir lambda handlerinda kosturayim? scaling ayarlarida sizin elinizde oldugu icin eger boyle bir yaklasimla gelecekseniz, bi tane yuk testi yapip fonksiyonunuzun saniyede kac request karsilayabildigini ogrenin, daha sonra bu bilgiyle aws panelde scaling ayarlariyla istediginiz gibi oynayarak dogru noktayi bulun. ben yine'de lambdayi boyle kullanmayi cok dogru bulmuyorum. trafigi en yuksek endpointleri ayri birer handler olarak tanitip az kullanilanlarin(mesela admin endpointleri olsun bunlar) hepsini toplayip bi handlera koymak daha mantikli olabilir gibi.

    3. tum ci olayindan ve dolayisiyla onunda getirdigi maintenance yukunden sonsuza kadar kurtulduk. aws codepipeline alip yuruyor burada, zaten yaptigi pek biseyde yok. production env deploymentlarinin onayi icin slack bot yazdik bi tane, sadece belli userlar sistemi şırrak diye proda deploy alabiliyorlar. bizede boyle oynamalik seyler cikiyor sozluk.

    dezavantajlar

    1. amazon api gateway cok super hizli degil.

    2. amazon api gateway donen json response'u string olarak istiyor, bu durum ne yazikki her http request icin cpu intensive bi is daha cikariyor. hem maliyet artiyor hem sistem bos yere yavasliyor.

    3. coldstart olayi var, bu sizin icin cok onemliyse yukarda yazdigim gibi bi kac endpointi bi handler'a koyarsaniz, bu durumda sistemin surekli sicak kalma ihtimali dahada yukseliyor, handler daha cok request alacagi icin. ama sanirim coldstartla en guzel bas eden mimari graphql mimarisi oluyor, cunku zaten tek handleriniz olacagi icin herzaman daha avantajli durumda. yada bir diger cozum bir cron zamanlayip handlerlari 5 dk'da bir calistirabilirsiniz.

    4. sqs'den long-polling yapamiyorsunuz, ama yine bi tane cron kurup lambda fonksiyonunu atiyorum her dakikada 1 kere calistirip queue'da ne var ne yok diye bakabilirsiniz, biliyorum kulaga bok gibi geliyor ama durum boyle, neyseki maliyeti yuksek degil. cok yuksek hacimli bir queue varsa ve realtime islenmesi elzem ise bu durumda kinesis'e gidilebilir ama bu yazinin konusu degil bu, geciyoruz.

    serverless frameworku

    aws cloudformation templateleriyle kafayi bozmak istemiyor, "ben aws filan bilmem abi koduma odaklanmak istiyorum, yarin birgun aws'e kizarim google functions'a tasinirim azure'e gecerim" diyorsaniz, herokudan filan geliyorsaniz, bu frameworku kurup baslayin derim. biz bunu kullanmadik aslinda, kendi templatelerimizi yazdik, ama simdi geriye donup bakiyorumda, cok gereksiz aws bilgileri ogrenmisim gibi geliyor sunun gibi bi guzellik varken.

    frameworku yazan elemanin surda guzel bi konusmasida var.