Microservice nedir?

Bu gibi konuları anlattığım ve anlatmaya devam ettiğim Patreon kanalımı da buyrun: patreon.com/tarikguney.

Bu kadar basit bir başlık atmamın sebebi bu konu hakkında insanların çok fazla teknik bilgilendirilip aslında doğru düşünce ve bakış açılarını öğrenemiyor olmaları. Onun için diğer yazılarımda da yaptığım gibi sizinle biraz geriden başlayacağım. Bu yazıyı yazdığım zamanda Patreon üzerinde yaptığım bir canlı yayın için soruldu microservice ile alakalı bazı tıkanıklıklar. Öğrenme sırasında insanların yaşadıkları tıkanıkların başında öğrendikleri konuyu içselleştiremedikleri gelir. Konu soyut kalır ve ellerini kire pasa bulamadan o konuyu adam akıllı öğrenmekte zorluk yaşarlar. Ama bu sorunları bir nebze olsun belki benim gibi yıllardır bu işi yapan insanlardan benzetmeler ile duyunca aslında korktukları konuların ne kadar da basit olabileceğini görüyor insanlar. Neyse haydi başlayalım.

İnsanlar olarak aslında hayatımızı devamlı SOA yani Service Oriented Architecture içinde yaşarız. Evet, çok geriden başladım, ama bu güzel konuların biraz tadını çıkaralım. Marketten bir servis alırsınız, ya da posta ofisinden, veyahut restorantlardan. Sizler de çalışanlar olarak birilerine servis verirsiniz. İşte en temel manada SOA budur. Peki restorandan sadece yemek alıyor, marketten alışveriş yapıyor, ve posta ofisinden sadece posta almak ve göndermek gibi hizmetler alıyorsanız, bunların aslında bir konu hakkında özelleşmiş servis sağlayıcıları olduklarını gösterir. Sadece bir tane sorumluluğu yerine getiriyor ve bunu da en iyi şekilde yapmaya çalışıyorlar. Biz de bunlara yazılımda microserviceler diyoruz. Microservice mimarisi SOA altında daha specific bir mimari şeklidir. Peki posta ofisine gittiğinizde iş yapmak için gerekli formlar ve anlaşma biçimi ile market aynı mı? Hayır! Birinde başka bir form dolduruyor diğerinde ise farklı şekillerde alış veriş yapıyorsunuz. Doldurduğunuz form bir HTTP requestinin headerları, postacıya verdiğiniz kutu ise POST ile gönderdiğiniz body içindeki payload. Bunları konuşurken kullandığınız ifade ise bir endpoint: Bir tane kutu postalamak istiyorum (POST htttp://usps.com/mail). Ya da ofisten bir tane mektup almak istediğinizde (GET https://usps.com/mail).

Biraz daha geri gelelim. Amerika’da bazı marketler içerisinde hem posta servisi, hem banka, hem de restoranlar olabiliyor. İşte bu da SOA dır ama artık microservice mimarisi değil. Çünkü birden fazla sorumluluğa sahiptirler. Biraz daha geriye gelelim, eğer siz market içinde yaşayan ve evi orası olan bir insan iseniz, artık SOA değil, monolithic bir mimari içindesiniz demektir. Herşey aynı yerde. Markete gitmek için evinizden çıkıp araba sürmüyor ve trafikte yol almıyorsunuz. Eğer bir servisi çağırmak için kablo trafiği üzerinde istekleriniz bir yerlere gitmiyorsa büyük bir ihtimal monolithic bir uygulamanız vardır. Tamam, local bilgisayarınızda da SOA taklit edilebilir ama redundancy, failover, vs. gibi olayın faydaları yok olmuştur. Yani bilgisayarınız single point of failure olmuş olup, o bilgisayar göçerse uygulama da göçecek demektir.

Peki yine aynı örnek üzerinden microservicelerin artılarını eksilerini anlamaya çalışalım. Eğer monolithic bir uygulama içinde iseniz trafik derdiniz yok demektir. Direk pencereden elinizi uzatmak suretiyle bir krem peynir, bir kilo kıyma gibi ihtiyaçlarınızı giderebilirsiniz. Ama market yıkılırsa altında kalırsınız ve siz de onunla beraber hayata veda edersiniz. Peki SOA da olduğu gibi eviniz ve market farklı yerlerde ise? O zaman aynı marketten bir kaç tane yapar ve birisi yıkılmışsa ya da dolu ise diğerine gitme şansınızı kullanabilirsiniz. Ama durun bir dakika, marketin dolu olmasının sebebi sadece içinde enfes yemekler yapan restoran ise, insanların çok fazla kullanmayacağını bildiğiniz halde aynı marketten bir tane daha yapmanıza gerek var mı? Aynı marketten kastım, içinde restoran, posta ofisi, banka olan kocaman marketin bir tane daha aynısı. Bu sahip olduğunuz kaynakların kullanımı açısından ne kadar saçma geliyor değil mi? Ama kolaylık açısından süper, çünkü herşey aynı yerde, olur da ihtiyacınız olursa. Herşeyin aynı yerde olması trafiğe daha az çıkacaksınız demektir. Tabi trafiğe çıkmak demek, trafik dolu ise ya da market uzaktaysa ihtiyacınızı karşılamak da o kadar uzun sürecek demektir. Biz buna yazılımda network latency diyoruz. Latency, latent var olmamış demek. Trafikte geçen zaman yapmanız gereken işe göre boş geçmiş bir zamandır. Dolayısıyla trafiğe ne kadar az çıkarsanız, o kadar daha hızlı bir şekilde işiniz göreceksiniz. Trafikte az zaman geçirmek zorunda kalmak microservice olmayan SOA ve monolithic gibi çözümlerin en önemli avantajları. Ama hayat bu kadar basit değil. Bazen trafikte geçen zaman büyük resimde çok önemli olmayabiliyor. Eğer bugünki logistic ve üretim zinciri trafiği dert edipte gönderimleri durdursaydı, insanlığın düşeceği sıkıntıları tahmin edebilirsiniz herhalde.

SOA’dan devam edelim. Peki marketimizin içindeki restoranın çok sevilmesinden dolayı daha çok para kazanmasını istedik ve onu büyütmeyi arzuluyoruz. Aklımıza ilk gelen çözüm, market içindeki çok müşterisi olmayan diğer departmanların sahip oldukları alanları ve insan sayısını azaltmak. Fena bir çözüm değil, ama yeterli olmadı. Daha çok insan geliyor. Diğer departmanları da tamamen kapatmak istemiyorsunuz. O zaman binayı büyütmekten başka bir şansınız kalmadı. İnşaat ile yeni kısımlar eklediniz. Biz buna yazılımda scale up diyoruz, yani bilgisayarınıza CPU, RAM, vs. eklemek. Ama bu çok masraflı bir durum. Çünkü müşteriler azaldığı zaman binayı gerisin geri yıkacak mısınız? Onu da geçelim, bir deprem olduğunda tüm market yerle bir olacak. Ve başka markette yok? Biz buna single point of failure diyoruz. Eğer benzerinden başka bir market olsaydı, ona failover server (market) diyecektik. Bir market yıkıldığında o devreye girecekti çünkü. Böyle büyük marketleri replicate yani tekrarlı yapmanın ne kadar büyük bir masraf olduğunu daha önce anlattım.

Çözüm: Microservice’ler! En azından çözümlerden bir tanesi. Birincisi, büyük marketi unutun. Market, posta ofisi, ve restoran artık ayrı binalarda, ve daha ufaklar. Sadece bir iş yapıyorlar ve en iyisini yapıyorlar. Çalışanlar marketten posta ofisine oradan da restorana gün içinde hareket etmiyorlar. Yaz geldi, restoranınıza ilgi çok fazla. Binayı genişletmek yerine başka bir yer daha kıralayıp oradan da hizmet vermeye başladınız. Kış geldi, insanlar mektup göndermeye başladılar, posta ofisi daha çok iş yapmaya başladı. Restoran binanınızı kapatıp, orasını hızlıca posta ofisi yaptınız,ya da başka bir yer kiraladınız. Biz buna yazılımda scale out diyoruz. Dışarıya doğru genişleme, yukarıya doğru değil. Kullandığınız kadar ödediniz, kullanmadığınızı kapatıp arkanıza bile bakmadınız. Restoranlardan bir tanesi mi çöktü, sorun değil, diğeri iş yapmaya devam ediyor. Market çöktü ama aynı binada olmadıkları için restoran ve posta ofisi iş yapmaya devam ediyor. Market ufaktı zaten, hemen başka bir yer kiralayıp orasını market yaptınız. Artık her yer sizin. İstediğiniz yeri kiralayın, kullanın, sonra bırakın gitsin. Cloud şehrine hoş geldiniz. Tamam insanlar daha çok trafikte zaman harcıyorlar, ama hayat her zaman hangi tradeoff’ları seçeceğiniz gerçeğine uyanmaktır. Daha büyük düşünün. Amerikanın batı yakasında deprem oldu, işler durdu, ama sizin doğu yakasındaki posta ofisi çalışmaya devam ediyor. İnsanları oraya yönlendiriyorsunuz. Devasa marketi değil, ufak ufak ofislerinizi taşıyorsunuz. Daha kolay yer buluyor, daha kolay taşınıyorsunuz. Ama binalar kullanıcılardan ne kadar uzaksa, insanların trafikte geçireceği zaman da o kadar artacak demektir. Network dünyasında da durum aynen bu şekildir.

Bir şeyin farkına varmanız lazım, microservice’ler her zaman çözüm değil. Mesela İnternet sorunları yaşadığınız bir ülkede mantıklı değil microservice kullanmak. Önceden bir binayı yönetmeniz gerekirken, şimdi ufak ufak bir sürü binaya bakmanız lazım. Monolithic bir mimaride herkes aynı binaya gelirken, şimdi insanları restoranın kapasitesine göre doğru yerlere yönlendirmeniz lazım (load balancing). Trafikte daha çok zaman harcamanız lazım. Trafiğin çok yavaş olacağı ya da yollarda kaza olabileceği gerçeğini devamlı göz önünde bulundurmanız lazım. Mesela, microservice’ler geliştirirken resillient HTTP client mantığı kullanılır. Bu şu demek: olur da yaptığınız HTTP GET çağrısına cevap kabul edilebilir bir zaman sonra gelmezse o zaman hemen havlu atmak yerine bir kaç defa daha aynı isteği tekrarlamanız gerekiyor, çünkü trafik bu, yolda başına herşey gelebilir bu isteklerin. Tabi bunun daha teknik kısımları anlattığım diğer yazımda daha farklı avantaj ve dezavantajlarını da inceleceğim. Kullandığım metafor bu kısımlarda biraz zayıf kalıyor.

Ufak Bir Örnek

Eğer bir satış siteniz varsa, aşağıdaki gibi farklı microservice’ler bölünebilirler:

1. Catalog Service
2. Shipping Service
3. Account Service
4. Finance Service
5. Ve bunların bir UI ile birleştiği bir UI servisi.

Şimdi diyeceksiniz ki mantığı anladık ama nasıl kodlama yapacağımızı bilmiyoruz. Onu da başka bir yazıda incelemek için söz verip burada duralım. Kendinize iyi bakın.