Monolitik Mimariden Mikroservis Mimarisine Geçiş

Bu yazımızda Monolitik Mimari ve Mikroservis mimarisi arasında bir kıyaslama ve ihtiyaçlara göre örnek projelere değineceğiz.

Öncelikle iki Mimariyi ayrı ayrı inceleyip tanımlarını yapacak, daha sonra ihtiyaç analiziyle detaylandıracağız.

Monolitik Mimari

İngilizce olarak Monolithic Architecture olarak geçen bu mimari yaklaşım, uygulamanın tüm parçalarının tek bir çatı altında geliştirilmesi ve sunulması olarak tanımlayabiliriz. Birçoğumuz sektöre girdiğimizde adını bilmediğimiz bu mimari yaklaşım ile devam ederiz zaten.

Üzerinde çalıştığımız/çalışacağımız projelerde, yeterli insan kaynağı olmadığından veya zaman yetersizliğinden dolayı doğru analiz ve projelendirme yapamaz ve hızlı olarak productiona geçmek için monolith mimariyle devam ederiz.

Fakat zamanla ekip büyütme ihtiyacı ve optimizasyon içinden çıkılmaz zorlu ve yorucu bir hal alır. Bu durumlarda yeni arayışlara girer, görev paylaşımı yaparız. Açık konuşmak gerekirse, seed yatırımı almamış çoğu girişim bu süreci tam olarak böyle yaşar. Bir taraftan müşteri taleplerini karşılamaya çalışırken diğer taraftan projenin kontrolden çıkmasını yönetmek zorunda kalırsınız. İşte bu noktada yeni arayışlara geçerek eninde sonunda Mikroservis mimarisinde karar kılarsınız.

Ama Mikroservise geçmeden önce gelin Monolith yapının avantajları ve dezavantajlarını inceleyelim:

Avantajlar

1. Küçük ekipler için yönetilmesi ve geliştirmesi kolaydır.
2. CI/CD ve Test süreçleri neredeyse DevOPS gerektirmez.
3. Birden fazla ekip ihtiyacı duymaz aynı anda birden fazla modülle çalışılabilirsiniz (Bunun bir avantajdan ziyade dezavantaj olduğunu göreceğiz)

Dezavantajlar

1. Zamanla yeni feature ekleme ve optimizasyon zorlaşır.
2. Bağımlılık ve Kod tekrarından dolayı versiyonlar arasında sorunlar yaşanır.
3. Proje bir bütün olduğundan, projenin bir bölümü auto scale yapılamaz tüm projeyi scale etmeniz gerekir.
4. Farklı framework/programlama dili kullanarak, daha stabil ve uygun maliyetle sunabileceğiniz modülleri proje içinde yazmanız gerekir (örneğin: AWS Lambda kullanmak)
5. Tüm proje aynı veritabanını kullanacağından performans optimizasyonu gerekir.
6. Sık kullanılan ve yüksek kaynak kullanımına sahip bir modülünüz için tüm sistem kaynaklarını arttırmanız gerekir.
7. Projeye yeni dahil olacak geliştiriciler için anlaması güç ve zaman alacak bir code base sunar.

Monolitik Mimariyi hepimiz aslında biliyor ya da bilmeden bir alışkanlıkla uyguluyoruz. Peki ihtiyaçlarımızı artık mevcut yapı sağlayamıyor ise ne yapıyoruz? Sürekli kaynak arttırımı veya kod değişiklikleri mi? Ya peki asıl sorun Mimarimiz ise?

Eğer sonunda sorunun mimarimiz olduğuna karar kıldıysak, radikal değişiklikler yapmak zorunda kalacağız. Biz Mikroservis Mimarisine geçme kararı aldık ve bu deneyimlerimizi sizinle paylaşmak istedik.

Mikroservis Mimarisi

Mikroservis Mimarisi için aslında en basit ve en sevdiğim tanım “Everything as an API” tanımıdır. Evet aslında her şey bir “API” (kısmen :)).

Son 20 yılda Teknolojinin hızlı büyümesi beraberinde maliyet ve performans sorunlarını ortaya çıkardı. Bunlara çözüm bulmak amacıyla sektörün guruları veya teorisyenleri olarak tanımlayabileceğimiz kişiler birbirinden farklı teoriler ve pratikler geliştirdiler. İşte Mikroservis Mimarisi de tam olarak böyle ortaya çıktı.

Genel amaç basitti: Böl, Parçala ve Yönet!

Mikroservis Mimarisi, bir uygulamanın bütün olarak değil parçalanmış olarak sunulmasıdır. Bu parçalar birbirleriyle herhangi bir TCP/UDP protokolü ile iletişim kurabilir (HTTP, WS vs.)

İlk okuduğunuzda tanım biraz karmaşık gelebilir. Gelin bunu bir örnekle açıklayalım:

Bir Online Araç Kiralama uygulaması geliştireceğiz. Normal şartlar altında Bir SPA Frontend hazırlayıp API ile entegre ederek devam edebiliriz, fakat ilerleyen zamanlarda daha karmaşık modüller, daha fazla yük ve büyüyen bir ekiple kaos içinde kalacağız.

Örneğin araç arama modülümdeki yükü dağıtabilmek için aynı projeyi tekrar tekrar deploy edip kopya sunucular yaratacak, veritabanı sunucumuzun kaynaklarını arttırmak veya caching desteği sağlayacağız. Ve tüm bunları aynı code base içinde yapacağız.

Peki bunu Microservis olarak nasıl uygulayabilirdik?

Sistemi 5 Ana modüle bölebilirdik:

1. Araç Kataloğu
2. Arama Servisi
3. Rezervasyon Servisi
4. Sepet
5. Ödeme

Bu modüllerin her birinin tek bir amacı var, Her bir modül sadece üstüne düşeni yapmalı. Araç Kataloğu içinde sepet veya rezervasyon işlevlerine ihtiyaç duyduğunda bunu doğrudan Amacı bu olan servislerle iletişime geçerek yapmalı (API vb.).

Mikroservis mimarisinin bir diğer önemli noktası her servis kendi veritabanına sahip olmalıdır (mümkün olduğunca). Genelde fail olan geçişlerin ana sebebi bunun görmezden gelinmesidir.

Araç kataloğu servisi ile Rezervasyon servisi aynı veritabanını kullanmamalı, Bir veritabanı ihtiyacı yoksa, veritabanı ihtiyaçlarını ait olduğu servis üstünden yapmalıdır.

Örneğin Ödeme işlemi başarıyla tamamlanmış bir rezervasyon düşünelim, Monolitik bir yapıda Ödemeden sonra veritabanından rezervasyon durumunu “completed” olarak güncelleyip, rezervasyon yapılmış aracı ilgili rezervasyon tarihleri arasında müsaitlik durumunu blokelememiz gerekecekti, ve bunu yaparken aynı veritabanını aynı code base üzerinden yapacaktık. Mikroservis mimarisiyle bunu yapsaydık, Ödeme servisi bu adımlar için Rezervasyon Servisini kullanacak ve sorumluluğu oraya aktaracaktı.

Böylece her biri kendisine çizilmiş sınırlarda, bağımsız, farklı ekipler tarafından geliştirilen, amaçları belli olan birden fazla servisimiz olacak.

Tabii bunları teorik olarak anlatmak uygulamaya göre daha basit. Çünkü Mikroservis Mimarisi yukarda değindiğimiz gibi tamamen dertsiz/tasasız bir yaklaşım değil. Fakat günümüz ihtiyaçlarına fazlasıyla uygun.

Bir projemizde başarıyla tamamladığımız Mikroservise geçiş sürecini ve süreç içindeki deneyimlerimizi farklı bir yazımda yakında yazacağım.

Ama bu yazıda değinmeden geçmek istemediğim bir konu var:

Mikroservis Mimarisine Geçerken Sizi Neler Bekliyor?

Mevcut bir code basei Mikroservis mimarisine geçirmek sıfırdan bir projeye başlamakla neredeyse eş değer, evet kod bloklarınızı kopyalanıp taşıyabilirsiniz veya sıfırdan yazabilirsiniz. Bu seçim tamamen siz ve ekibinize göre değişecektir. Ama emin olun pek bir şey değişmeyecektir.

En büyük problem birden fazla kişiden oluşan ve her bir servis için ayrılmış ekipleriniz olmalı. Çünkü zamanla sonra aynı developerlar farklı servislerde kod yazmaya başladıkça efor yönetimi tarafında zorluklar yaşacayacaksınız. Kontrolü kaybettiğiniz zaman Geliştiriciler size ufak sürprizler yaparak bağımsızlık ilkesini yok sayacaklar.

Uzun araştırmalar sonucunda bir Mikroservis mimarisine en uygun cloud çözümün Amazon Web Services olduğu kanaatine vardık (bu ayrı bir tartışmanın konusu). Bu ekosisteme hakim bir DevOps geliştiricinizin olması çok önemli. Çünkü Mikroservis Mimarisinin kodlamaktan daha çok bir konfigürasyon sihirbazlığı olduğunu göreceksiniz.

Yine aynı şekilde CI/CD süreçlerine hakim, repo yönetimi ve deployment senaryolarında iyi bir DevOps geliştirici ihtiyacınız olacak.

Dökümantasyon yazma disiplini olan developerlara veya Dökümantasyon yazmak için farklı bir personele ihtiyacınız olacak.

Domain Driven Design (DDD) veya benzeri tasarım modellerine hakim, model ve event çıkarabilir olmanız gerekecek.

Belkide en önemlisi Container mimarisine eninde sonunda ihtiyaç duyacaksınız.

Bu sorunlar bir sonraki yazımda detaylandırılacak ve çözüm önerileri sunulacak.

Peki size ne kazandıracak:

Mikroservis Mimarisi Avantajları

1. Farklı featurelar için tüm code base üzerinde değişiklik yapmak zorunda değilsiniz.
2. Bağımsız servislerle daha sade bir code base kazanacak, yeni personel istihdamında zaman kazanacaksınız.
3. İstediğiniz bir servisi bağımsız olarak scale edebilecek, ekstra kaynak ihtiyacı duymayan servisleriniz için gereksiz maliyetten kurtulacaksınız.
4. Bir Servisde yapılan hata diğer servislerin aksamasına sebep olmayacak.
5. Servisleriniz için dilediğiniz framework/programlama dili kullanabilecek, dilediğiniz zaman geçiş yapabileceksiniz.
6. Her servis için farklı veritabanları kullanabilecek, veri akışını hızlandırıp performansı ölçeklendirebileceksiniz.

Bir sonraki yazıda görüşmek dileğiyle.