lombak şehidi

Never meet your heroes! Evet, tek cumlelik ozeti bu olabilir sanirim. Ama gercek hayatta cogu sey tek cumle ile ozetlenemeyecek kadar karmasiktir. Suanda pazar gunu kutuphanede oturmus bunlari yaziyorum. Bir taraftan da gelecek haftanin oncall'u var aklimda. Diger taraftan operasyonel islere bakiyorum ki pazartesi gunu deadline var.  Iyi Burasi bir okul. Teknik konular sonsuz, aradigin dokumantasyonu bulamiyorsun ama aramadiklarini okuyarak kor olabilirsin. Ama esas ogreneliecek sey teknik konular degil. Onlari chatGPT'ye de sorabilirsin. Esas konu: Operasyon.  Operasyon acayip birsey. Ben bugune kadar bu alanda hic calismamistim. Kodu yazariz, hadi deploy da ederiz, biraz da DevOps ama gereisi yoktu. Burada bir sistemi up and running tutmak icin gotler veriliyor. Gecenin 2sinde page'ler geliyor. Bu tecrubeyi kendi kendinize edinemezsiniz. O acidan cok cok degerli. Ama with the heat of the moment, cok cok kufurler ediyor insan tabi ki. Kendime not, buyuk resmi dusun, edini

There is no path to happiness, happiness is the path. - Buddha Son zamanlarda farkettim ki cok fazla sikayet ediyorum. Sikayet etmek bir virus gibi. Insandan insana gecebiliyor. Sikayet ettikce insan bunu kendisi de duyuyor. Kendi sikayetinizi duydukca da negatif duygular buyuyor. Ve daha fazla sikayet etmeye basliyoruz. Kisir bir dongu olusuyor. Her cycle'da siddetlenen negatif duygular. Ayrica da sikayet etmek hic bir ise yaramiyor. Eger ortada bir problem varsa, cozume yonelik aksiyon almak en pragmatik eylem. Sikayet etmek, cozume degil de probleme odaklanmaya zorluyor. Hal boyle olunca problemin cozulebilecegi, bir cozumunun oldugu, cozum icin adim atilmasi gerektigi gozden kaciyor. Eger bir cozum yoksa bile bosuna sikayet edilmis oluyor cunku zaten birsey degismeyecek.  Nasil ki dopamin orucu var, ve cok ise yariyor, ben de onumuzdeki uc gunluk sure icerisinde "sikayet orucu"na girmeye karar verdim. Sonuclari yine paylasirim.  Madem sadece tek bir hayatimiz var, bun

Hayir.  Su aralar araftayim. Hatta ki nasil bir araf, kitalar arasi. AWS calisiyorum bu aralar. Ama henuz yazamiyorum. Yazmaya/yayinlamaya ara verince gercekten insanin eli gitmiyor. Bu postu da zaten bu yuzden yaziyorum. To get the ball rolling. Neler Ogreniyoruz ? AWS ozelinde olsa da IaC (infrastructure as code) olaylari gercekten muazzam. Yillardir cloud ile ic ice olsam da, gercek anlamda cloud avantajlarini gormek icin IaC olaylarina gozatmak gerek. Neden daha once cikarmadilar bilmiyorum ama CDK (cloud development kit) gercekten inanilmaz. Python ile infrastructure yaziyorsunuz, testleri de cabasi. Lambda kullanarak kodumuzu da python ile yaziyoruz ve boylece fullstack uygulamalari aws uzerine deploy etmek tek satir cli komutuna bakiyor: cdk deploy . Bu kisim kendi basina bir blog post hakediyor sonuna kadar.  AWS Networking CDK guzel ama, biraz da AWS internals ogrenmek gerekiyor. Her zaman en zorlandigim konu networking olmustur. Belki de formal bir CS egitimim olmadigi icin o

gRPC server yazacagiz ve serverimizin cok guclu (o da ne demekse) olmasini istiyoruz. Bu yuzden, bir sekilde gelen requestleri paralel olarak isleyebilen bir yapiya ihtiyacimiz var. Python threading malum, CPU intensif isler icin uygun degil cunku GIL sebebiyle ayni anda birden fazla Python kodu calistirilamiyor. Dolayisi ile mevzubahis CPU gerektiren islemler ise, Python threading aslinda tek thread gibi davraniyor.  Bu durumda official ornege bakabiliriz. Tamam Python threading'de GIL engeli var ama multi-process yapar isek boyle bir engel yok. Ne de olsa her bir process kendi GIL'ine sahip olacak. Ama burada da yuku processlere nasil dagitaracagimiz problemi akillara geliyor.  Port Sharing Resmi ornekte, yuk dagitma islemini butun process'leri ayni porta bind ederek saglamislar. Bu sayede yuk TCP katmaninda, isletim sisteminin Kernel seviyesinde yapilmis oluyor. Port uzerine gelen istekler, TCP katmani tarafindan bu portu dinleyen processlere bir round-robin yapisi sekli

Cok fazla yuk altina girecek olan bir gRPC server isletiyoruz diyelim. Server'i de Python ile yazdigimizi dusunelim.  - Ne gini kisitlamalar yasayacagiz? - Serveri horizontal olarak scale etmek icin ne gini seceneklerimiz var? - Bir de gRPC server local'de calisip, diger desktop uygulamalarina hizmet veriyor ise isler nasil degisir?  Gelin bu kullanim alani uzerinden biraz beyin cimnastigi yapalim. 1. Network Load Balancing Server-side RPC, HTTP 2.0 uzerinde calisan bir iletisim protokolu oldugu icin, HTTP2.0 destekleyen standart load balancerleri kullanabiliriz. En populer secenekler ngix ve envoy proxy olarak gosterilebilir.  Yalniz burada temel bir problemimiz var. gRPC sessionlari sticky bir yapidadir. Yani bir client bir servere bir kere baglanir  ve uzun bir sure boyunca bagli kalir. Request ve response'lar bur mevcut baglanti uzerinden gerceklesmis olur. Bu sayede her request/response icin tekrardan baglanti kurmaya (ve dolayisi ile TCP handshake yapmaya) gerek kalma

Bu multithreading isini cok karistirdilar.  Thread ve Process Thread ve Process, birbirinden bagimsiz olarak calisabilen (teorik olarak) kod parcaciklaridir.  Aradaki fark, ayni program tarafindan olusturulan threadler ayni hafiza alanina erisebilir. Buna karsilik process kendi basina bagimsiz bir program olarak dusunulebilir, Kendine ait hafiza alani vardir.  Bu da demek oluyor ki, thread'ler kendi aralarinda haberlesebilmek icin ekstra bir efora ihtiyac duymazken, process'leri birbiri ile konusturabilmek icin ekstra birseler (gRPC?) yapmak gerekir. Yukarida ayni program tarafindan olusturulan threadler derken bile, aslinda buradaki program, bir process 'tir. Her process primary thread olarak adlandirilan en azindan 1 adet thread'e sahiptir. (Single threaded tabirini hatirlayalim).  Peki neden birden fazla thread'e ihtiyac duyalim?  Kullanici acisindan, birden fazla process'in ayni anda calistirilbilmesi demek, ayni anda birden fazla uygulamayi calistirabilme