microservices ^*

• son zamanlarin populer mimarisel dizayni^*. kullanim acisindan henuz cok yaygin olmamakla beraber su aralar sik sik gormeye basladim. ne olduguna gelince; bu dizayn buyuk olcekli projelerde tek buyuk bir uygulama^* yerine, uygulamayi olabildigince en mantikli ve kucuk parcalara bolup yayinlamayi tanimlar. amac, olasi bir refactoring'i, degisikligi uygulamaya yansitmak icin butun projeyi build/deploy^* surecine sokmamak, boylece zamandan kazanmak. herhangi yeni bir feature istendiginde diger parcalara olabildigince dokunmadan ayrica gelistirmek de bu tasarimin gerekliliklerinden biri. kisacasi pluggable bir yapi. her anlamli kucuk parcanin kirmizi cizgilerle cizilmis sinirlari, bu sinirlar icerisinde yapmasi gereken isler vardir ve sadece onlari yaparlar (yapmalidirlar).
  
  bunun icin buyuk uygulamadan bolunecek modullerin cok iyi tanimlanmasi ve api'in -bu kucuk moduller surekli birbirleriyle iletisim halinde olacaklari icin- generic yazilmasi gerekiyor.
  
  avantajlari arasinda application seviyesinde tek bir programlama diline bagli kalmamak, yani gerektiginde performans icin c kullanabilmek veya saglam bir orm icin java kullanabilmek veya yeri geldiginde erlang kullanabilmek gibi spesifik islerle o islerde daha "elegan" oldugu bilinen dilleri kullanabilme ozgurlugunun saglanmasi da yer aliyor.
  
  bir diger avantaji, yukarida belirttigim kirmizi cizgilerden -ideal sartlarda- hatanin da gecemiyor olusu. ornegin sunucuda erismemeniz gereken bir bellek alanina erismeye kalktiniz ve c++ ile yazdiginiz uygulama kapandi. tek bir uygulama ise downtime yasayacaktiniz, oysa bu yaklasim ile hata sadece o submodul icerisinde kalacak ve uygulamanin geri kalanina propagate etmeyecek. bunun icin her modulu buna uygun bir fault tolerant yapida yazmak gerekiyor. keza atiyorum ben odeme submoduluyum, kullanici rolu modulu offline oldugunda ne yapmam gerekiyor bunu bilmem gerekiyor.
  
  ilk anda mantiksiz gelmiyor, inversion of controlun kod bazinda degil de uygulama bazda yapilani. metod cagirmak yerine remote metod (genelde web servis, rpc, rmi) cagiriyorsunuz. session modulunde calisirken muhasebe modulu icerisinde neler donuyor bilmem gerekmiyor. ama network katmanini da dahil ettiginiz zaman uygulamaniza network tarafindaki yasanabilecek olumsuzluklari da inherit etmis oluyorsunuz.
  
  bu tasarimla ilgili en cok kafami kurcalayan sey sanki dry^* presibine aykiri olmasi. ben iki modulu konustururken bunu serialize edilmis json veya xml uzerinden yapacagim fakat bu iki modul farkli dilde yazildiysa iki farkli dilde mecburen ayni objeyi olusturmak gerekiyor ve bunlarin refactoring'i de oyle ide'den tek bir komutla olmayacak.
  
  bunu guzel bir sekilde uygulamak icin yazilimcidan analiste, sistem admin'e kadar her asamada kalifiye adam bulmak gerekiyor. orta olcekli uygulamalarda zaten bu metoda yakin bir sistematikle calismayan takim yoktur. illaki bir seviyeden en azindan uygulamayi uce dorde bolmeyi dusunuyoruz. ama submodul sayisi arttikca onlarin belirli bir harmoni icerisinde calismasini saglayacak tasarimi yapabilen mimar hakikaten sanat yapiyordur.
  
  (bkz: twitter)
• (bkz: hipster soa)
• eger bu microservice'lerinizi soyle bir sekilde izleme imkaniniz yoksa muhtemelen icine atlamamaniz gereken olay.
  
  sunlar da bir okunmali:
  http://martinfowler.com/…i/microservicepremium.html
  http://martinfowler.com/…s/dont-start-monolith.html
• http://martinfowler.com/microservices/
• e-bay'in arkasindaki node.js microservisler ve ci surecleri;
  
  http://www.technology-ebay.de/…og/nodejs-real-world
• tercih edilmesinin ve bu kadar yayginlasmasinin en buyuk sebeplerinden birisi de dagitik yapisi sayesinde yatay olceklenirligin^* cok kolay yapilabilmesidir.
  ekosistem icerisinde performans sikintisi olan noktalar tespit edilip sadece bu nodlarin sayisi arttirilarak sistem yukune ve zamanina gore^* otomatik olarak dahi yapilabilir bu isler.
  bir diger avantaji da kullanilan teknolojiye gore^* ha^* yapilarinin daha kolay kurulabilmesi ve deploy^* edilebilmesidir.
• yazılım mimari&tasarım modeli. kullanımı ülkemizde de yaygınlaşmaya başlamıştır.
  
  birçok büyük ölçekli firmanın bu mimariye geçmek için dijital dönüşüm projeleri var, birçoğu geçişini yaptı. talebin artması ve ihtiyaçların çeşitlenmesi ile projeler önü alınamaz şekilde büyümeye başlıyor. bu durum dönüşümü zorunlu kılıyor.
  
  modüler yapı yukarda da ifade edilen çok çeşitli avantajlar sunuyor. yazılımcı gözünden bence en önemlileri:
  -yatay ölçeklenirliğin kolay olması
  -olası bir sorunun takibinin ve düzeltmesinin kolay olması
  
  aşağıdaki kitaplardan bu mimari model hakkında detaylı bilgi elde edilebilir. konu hakkında mimarın ^* başucu kaynağı olabilecek yayınlardır.
  
  building microservices - sam newman - aralık 2014
  production-ready microservices - susan fowler - aralık 2016
• cloud ve containerization'la beraber son dönem hızla popülerleşiyor. servis odaklı mimari (bkz: soa)'nın yeni bir iterasyonu aslında.
  
  soa'nın tam tersine her bir mikroservisin tamamen otonom olması bekleniyor. her mikroservis kendi model yapısını tutuyor. servisler arası gerek model gerek işlevler için paylaşılan bir sınıf kütüphanesi mikroservis mimarisinin tamamen karşı olduğu bir alan. çünkü servisler arası dependency'ler onların birbirine sıkı sıkıya bağlanmalarına (bkz: tightly coupled) neden oluyor. sonuç olarak mikroservislerin birbirleri ile iletişme ihtiyacı kötü bir tasarım anlamına gelebiliyor. illa iletişmek zorundalarsa da messaging queue kullanmalılar. (bkz: rabbitmq)
  
  sonuçta bir hedef için bir araya gelmiş bu mikroservisleri çağıran ve birinden aldığı bilgiyi diğerine teslim eden ana mikro servisler/api gateway'ler bu mimarinin olmazsa olmazı.
  
  mikroservis geliştirmek zeka gerektiriyor. hem yazılım mimarinin hem programcının yaratıcı ve uyanık olması gerekiyor, aksi halde redundant bilginin çorba olması, veri paylaşımı, concurrency problemleri kaçınılmaz hale gelir. sadece bu yüzden geçici bir mimari olduğunu ve gelecekte yerini bu kadar akıl/mantık gücü gerektirmeyen mimarilere bırakacağına inanıyorum. klasik yazılım geliştirmede var olan merkezi ve paylaşımlı veritabanı mikroservislerde her bir servisin kendi veri tabanını tutması bekleniyor. bu otonomluk için gerekli. tabii ki mikroservisler arası bilgilerin senkron edilmesi büyük sorun haline gelebiliyor ve bu yüzden değişik veri modellemeleri mevcut.
  
  geliştirmesi bu kadar zahmetli olan mikroservis mimarisinin meyveleri uzun vadede toplanıyor. her bir mikroservis otonom olduğu için değişik takımlara verilebiliyor. bu mikroservisler tamamen farklı dillerde, platformlarda çalışabiliyor. dağıtık sistemler ve bulut bilişim için bulunmaz bir güzellik. inanılmaz bir ölçeklenebilirlik de cabası.
  
  mikroservis mimarisinin gerçek hayatta bir implementasyon örneği şu şekilde olabilir: bir e-ticaret web sitesinin (bkz: amazon) ürün arama ve listelemesi ayrı bir mikro servis, daha az yoğulukta kullanılması beklenen alışveriş sepeti ayrı bir servis, daha da az yoğunlukta kullanılması beklenen sipariş alma ve ödeme ayrı bir mikro servis olabilir. her bir sistem kendi data modelini tutar. bir servis çökse bile diğerleri etkilenmeden çalışmasına devam edebilir. örneğin alışveriş sepetindeki bir güncelleme yüzünden bütün yazılım monoblok olarak deploy edilmek zorunda kalmaz.
  
  mikroservis mimarisi büyük projeleri ekiplere bölmek için, bütün yazılımı değil sadece belli işlevleri scale edebilmek için, continious delivery amacıyla deployment süresince çalışan sistemin en küçük parçasını bakıma almak için düşünülmüştür. bu yolda ödenen paylaşımlı veri entegrasyonu ve mikroservisler arası iletişim problemlerinin çözümü de yazılım mimarının ve programcıların ne kadar yetenekli olduğuna bağlıdır.
• mikroservislerin esneklikleri ile ilgili bir makaleye gökhan gökalp'in blogundan ulaşılabilir mimari türü.
  microservice mimarisinde resiliency pattern’ları
  
  hakkında genel olarak bilgi sahibi olmak için okunabilir güzel bir medium makalesi burada.
• (bkz: serverless)