Hangi Mimariyi Seçmeliyim: Monolithic, Terraservice / Macroservice, Miniservice, Microservice, Nanoservice / Serverless

Published in

Inside Architecht

6 min readJan 21, 2021

Mikroservis son zamanlarda pek meşhur bir konu olarak karşımıza çıkıyor. Firmalar uygulayabilirlerse küçük küçük başlıyor, cesareti olanlar legacy sistemi dönüştürmeye başlıyor. Bazı firma çalışanları hiçbir şey yapamasa da makale okuyor, ne olduğunu anlamak için çaba sarf ediyor. Araştırma yaparken de Monolithic ve Microservice gibi tonla yazı — makale — sunum kurcalıyor. Bu kurcalama seanslarında karşısına Serverless kavramı da çıkıyor, biraz da ona bakıyor. Eğer konuyu derinlemesine araştırıyorsa karşısına Terraservice, Macroservice, Miniservice, Nanoservice gibi kavramlar da çıkıyor ve işte o zaman kavramlar birbirine girmeye başlıyor.

Mikroservis yapmak istiyorsanız diğer tanımların neler olduklarını da bilmelisiniz. Ortaya çıkarttığınız şey farklı bir şey ise, bir uzman gelip baktığında “Siz başka bir şey yapmışsınız” deme ihtimali var. Tanımların ilki ve sonuncusunda kesinlik var ama aradaki tanımlarda tam da bir kesinlik yok, birbirine geçişli olabilirler. Bu kavramların hepsine kısa kısa değinip, sonra hangisi hangi durumda tercih edilmelidir konusuna bakalım.

Monolitik (Monolithic)

Uzun uzun bahsetmeye gerek yok, bunu zaten herkes biliyor, bu konuda sayamayacağımız kadar makale var. Daha “Siz gençler bunu bilmezsiniz” denilecek bir konuma geçmedi, uzun süre de geçmeyecek gibi gözüküyor. Tek devasa bir uygulamanın olduğu, genellikle sınırlı sayıda ve çok modern olmayan teknolojiler ile geliştirilmiş, hantal, yaygınlaştırmanın ya hep ya hiç yapıldığı, ekiplerin çevik olamadığı, geliştirmelerin uzun ve etkisinin büyük olduğu koca koca yazılımlardır. Avantajları da yok değil ama modern mimari yaklaşımları içerisinde artık gösterilmeyen bir yöntem. “Neden hala yaşıyorlar?” sorusunun cevabı; mikroservise dönüştürülme maliyetlerinin çok olması, yeni bir ürüne / projeye başlarken monolitik başlamanın avantajlı olması ve bazı işlerin kritikliği nedeniyle monolitiğe daha uygun olmasıdır (bu son maddede bazı itirazlar geldi gibi, bu fikir ayrılığını başka bir yazıda ele alalım inşallah).

Mikroservis (Microservice)

Özet bir tanımla; bağımsız bir şekilde geliştirme yapabildiğiniz, bağımsız bir şekilde yaygınlaştırma (deployment) yapabildiğiniz ve yine bağımsız bir şekilde sistemi ölçekleyebildiğiniz mimarilerdir. Burada takımları da mikro takım (micro team) şeklinde kurmalısınız ki mimariniz tamamlansın. Takım kurma ile alakalı şu yazımı okumanızı öneririm. Mikro takımlar ve mikroservis mimarisi sayesinde Sürekli Teslimat (Continuous Delivery) ve Sürekli Yaygınlaştırma (Continous Deployment) da mümkün hale gelmektedir. Bu iki kavram karşılanamamışsa mikroservis olduk diyemezsiniz.

Peki başka neler olmalı ki mikroservisiz diyebilesiniz.

Servisler birbirleri ile esnek bağlı ise (loosely coupled).
Servislerde tek sorumluluk prensibi (single responsibility) varsa.
Servisler bağımsız bir şekilde geliştirilebiliyor, yaygınlaştırılabiliyor, yönetilebiliyor ve ölçeklenebiliyorsa.
Servisler publish-subscribe modeli ile asenkron konuşuyorlarsa. Tüm iletişimlerini http çağrılar ile ve senkron bir şekilde yapmıyorlarsa.
Veritabanı ve infrastructure servisler arası paylaşılmıyor ise.

En temel gereklilikler yukarıda saydıklarım ama bunların yanında başka detay konular da yok değil. Martin Fowler da yukarıdakilerden ilk 3 maddeyi öncelikli gereklilik olarak sunuyor.

Serverless / Nanoservice

Her bir işlemin bir servis ucu ve bir fonksiyon olarak çalıştığı mimaridir. Yani eğer her bir fonksiyonaliteyi ayrı bir servis ucu olarak yaşatırsanız bu yapılar serverless yapılar olur. Tabi tüm mimarinizi serverless kurma şansınız yok. Eğer state önemli ise, veri tabanı işlemi yapıyorsanız gibi durumlarda serverless mimarileri kullanamayabilirsiniz. Tabi ben her CRUD işlemini de serverless açacağım derseniz yapabilirsiniz ama bunu sağlayabilmek için ekstra yapılar kullanmak zorunda kalabilir ve bu nedenle amaçlanan verimi alamayabilirsiniz.

Peki neden bunu kullanmalıyım? Örneğin bir PDF oluşturma servisiniz var. Belli bir veriyi alıyor ve geriye PDF file dönüyor. Bunu serverless yaparsanız servis sadece çalıştığı zaman ayağa kalkacağı için maliyet avantajı olacak. Ayrıca uygulama ile ilgilenmek dışındaki hiçbir yönetim işlerine karışmazsınız. Bu gibi avantajları nedeniyle bazı konular serverless yapılabilir ama tüm sistemi serverless kurmanız hem imkansıza yakın hem de anti-pattern’dir.

Bazı makalelerde nanoservisi ayrı bir tanım olarak da ifade ediyorlar. Mikroservisi biraz daha ince taneli (fine grained) yaparsanız bu durumda nanoservis olur deniyor. Bu tanımla da karşılaşırsanız şaşırmayın. Ancak ben o şekilde bir ayrımın miniservis ve mikroservis olarak ifade edilmesini daha doğru buluyorum. Nanoservis çoğu yerde serverless kavramı ile aynı şey olarak geçiyor.

Miniservis (Miniservice)

Bazı mikroservislerin birbirlerini bilmelerinin avantajı daha fazla ise bu mikroservislerin birleştirilmesi sonucu ortaya çıkan yapılara miniservis diyebiliriz. İlla önce ayırıp sonra birleştirmeye gerek yok, direkt birleşik şekilde de kurgulayabilirsiniz. Miniserviste hem bazı mikroservis gerekliliklerini atlatıyoruz hem de bazı servisleri karmaşıklığı engellemek için birleştiriyoruz. Ancak yine bu servisler hiç alakasız servisler olmuyorlar veya içlerinde generic servisleri içermiyorlar.

Yukarıda mikroservis diyebilmek için neler olması gerektiğini listelemiştik. Şimdi de ne olunca miniservis olur onu listeleyelim:

Eğer veritabanı ve infrastructure servisler arası paylaşılıyor ise.
Servisler publish-subscribe modeli ile konuşmuyorlar, iletişimlerinin çoğunu http çağrılar ile ve senkron bir şekilde yapıyorlarsa.
Karmaşıklığın engellenmesi için biraz daha iri taneli (course grained) servisler varsa.

Fark ederseniz diğer maddeleri yazmadım. Çünkü bu modelde servisler biraz daha büyük olmasına rağmen yine de birbirleri ile sıkı bağlılıkları yok. Ya da servisler yine single responsibility prensibini uygulamaya çalışıyorlar. Ama bu prensip çok küçük bir iş olarak değil de biraz daha büyük bir iş olarak düşünülmelidir.

Terraservice / Macroservice

Monolitik ve mikroservis arasında kalan Terraservice, Macroservice ve Miniservice tahmin ettiğiniz gibi karma modeller. Mini’den Terra’ya giderken mikroservisten monolitiğe doğru bir kayma oluşuyor. Terraservice’ler gerçekten büyük hafıza isteyen uygulamaları ifade ederler. Monolitik bir kurguya sahiptirler. Çok özel işler için kullanılabilirler ancak genellikle kaçınılması gereken bir mimaridir.

Peki Ben Hangi Mimariyi Seçeyim

Peki uygulamaya başlarken hangi mimariyi seçeceğim? Monolitik mi, yoksa Mikroservis mi olsun? Herhangi bir uygulamaya başlarken monolitik başlamak en mantıklısı olacaktır. Daha sonra dilerseniz monolitik uygulamayı mikroservislere parçalayabilirsiniz. Ancak dikkat edilmesi gereken konu, monolitik uygulama bir deve dönüşmeden önce bu işleme başlamanız lazım. Yoksa bu devasa uygulamayı bölmek ve tekrar küçük küçük dizayn etmek çok zor olacak. Canlıya çok hızlı çıkış (time to market) amacınız varsa veya bir startup iseniz ve MVP çıkartıyorsanız, bu durumda zaten monolitik sizin için en mantıklısı olacaktır. Mikroservisin teferruatı yerine ürüne odaklanmanız gerekmektedir. Ürünün nereye gideceğini bilmediğiniz için mikroservis tercih etmek sizin için çok maliyetli olabilir. Önemli bir soru da şudur ki, bu uygulama bir gün kesinlikle mikroservis olacak mı? Eğer olacaksa baştan mikroservis başlayabilirsiniz.

Karmaşıklığınız çok ve diğer servisler ile etkileşiminiz az ise bu durumda da daha çok miniservis tercih edebilirsiniz. Mikroservisleri miniservislere tercih etmeniz sonucu maliyetlerinizin artacağı kesindir. Ama burada amaç önemli. Eğer hızlı geliştirme istiyorsanız ve karmaşık mimariyi kurabilecek takımınız varsa Mikroservis seçebilirsiniz. Ancak takım karmaşıklığı çözemeyecekse ve ürünü canlıya çok hızlı almak daha az önemli ise miniservis tercih edebilirsiniz.

Bir de zaten var olan bir monolitik uygulamanızı mikroservise dönüştürmek isteyebilirsiniz. Yapabilirsiniz, ancak bunun için ciddi bir efor ve konsantrasyon gerekiyor. Ayrıca sadece teknolojiyi değil, tüm kültürü de değiştirmeniz gerektiğini unutmayın. DevOps süreçlerini otomatize etmeden, temiz kod anlayışını ve kod gözden geçirme süreçlerini oturtmadan, çevik (agile) takımlar ile ürün odaklı yaklaşıma geçmeden bu dönüşümü yapamayacağınızı bilin. Aşağıdaki Tweet bunu çok iyi anlatıyor.

Mimarinizi geçişli bir şekilde kurup, karma bir yere de oturtabilirsiniz. Hem mikroservis yapıp, bazı kısımları miniservis, bazı kısımları ise serverless yapabilirsiniz. Belki bazı servislerini birleştirip terra servis yapacak ama çok değişiklik yapmayacak, en çok değiştirdiklerinizi mikroservis yapacak, bazı kısımları ise karmaşıklığı çok diye miniservis yapacaksınız. Maliyetler sizin için önemli ise ve fonksiyonunuz uygun ise serverless fonksiyonlarınız da olabilir, neden olmasın.

“Bu modellerden kesin bir tanesini tercih ederim, başka da kullanmam” demeye gerek yok. Sonuçta ortaya çıkacak olan size özel bir xService olabilir. Kabiliyetlerinizi, enerjinizi ve kısıtlarınızı iyi analiz etmeniz gerekiyor. Unutmayın; en iyi model, en az maliyetle ürününüzü en çok sattıran modeldir.

Son olarak Chris Richardson’dan aşağıdaki 2 tweet ile bitirmek istiyorum.