Monolith’ten mikroservise yolculuk

Dolap tech ekibi olarak bizim de içinde bulunduğumuz bu yolculukta başımıza gelenleri ‘Sam Newman’ kitabı Monolith to Microservices mantalitesine göre değerlendirip aktarmaya çalışacağız.

Böylesine büyük bir yolcuğa çıkmadan önce kendi durumumuzu, eksiklerimizi ve artılarımızı görebileceğimiz bir yazı ile giriş yapalım.

Monolith uygulama ne demektir?

Monolith olarak söylediğimizde aklımıza tek, büyük bir uygulama geliyor ama monolitlerinde kendi içinde bölünme durumları var. Burada dikkat etmemiz gereken en temel şey bir uygulamanın nasıl deploy olduğudur. Bütün uygulamayı tek seferde deploy edebiliyorsak aslında bu bir monolith’tir diyebiliriz.

Peki nedir bu monolith çeşitleri?

• The Single Process Monolith: Tüm kodu tek bir işlem ile paketlenebilir olmasıdır.
• The Distributed Monolith: Birden fazla hizmetten oluşur ama birlikte paketlenmesi gereken sistemlerdir.
• Third-Party Black-Box Systems: Temel kodu değiştiremediğimiz (crm, hr sistemleri gibi) sistemler için geçerlidir.

Monolith uygulamanın avantajları ve dezavantajları nelerdir?

• Tek bir uygulamanızın olduğunu düşündüğünüzde sadece tek deployment yapmak.
• Yazılan kodun kendi içerisinde tekrar kullanımı basitleştirilebilir.
• Testlerin tek bir ortamda koşulması kolay takip edilebilir bir yapı oluşturuyor. Dolayısı ile uçtan uca yapılan testleri çalıştırmak daha kolay hale geliyor.
• Uygulamanın davranışlarını izlemek (monitör etmek) çok daha kolay.

• Büyük ve ürün özelliklerinin iç içe girdiği bir uygulamada temel sıkıntılardan birisi oluşturulan takımların (Delivery Teams) kendi içerisinde belirlenmesidir. Monolith uygulamalarda product ownerların takımları müşteri özelinde yönetmesi ve lead mantalitesinde ki desteğin verilmesi biraz iç içe geçmiş haldedir. Her takımın kendi alanında özelleştiği ve leadlerin desteklediği bir yapı ürünün verimliliğini ve yönetimini kolaylaştıracak, verimliliği arttırıcaktır.
• Codebase’in tek olması üzerinde çalışan kişi sayısı arttıkça aynı alanda çalışmak isteyecek insan sayısınında artmasına neden olacaktır. Bu durum zaman içerisinde conflictlerle zorlu mücadelelere girmemize sebebiyet verecektir.

Mikroservis mimarisi nedir?
Herkes tarafında övülen mikroservis nedir ne değildir bir bakalım;
mikroservisin en temel tanımı olarak şöyle diyebiliriz. Belirli bir iş(domain) etrafında bağımsız olarak yönetilebilen hizmettir.

Bir mikroservisin oluşması için gerekli 3 esas vardır bunları şöyle sıralayabiliriz;

• Bir birlerinden bağımsız olarak paketlenebilir olması (Independent Deployability)
• Belirli bir model etrafında sınırlandırılmış olaması gereklidir.
• Kendi verisine sahip olması. Bu özellik uygulamamızın neyi paylaşıp neyi gizleyeceğine karar vermesini sağlayacaktır. Buradaki en önemli noktalardan birisi veri tabanımızın paylaşılabilir olmamasıdır. Bağımsız bir uygulama olmasını istiyorsak bu adımdan vazgeçmememiz önemlidir.

Mikroservisin ne olduğunu kavradığımıza göre avantajlarına ve dezavantajlarına göz gezdirebiliriz.

Mikroservis mimarisinin avantajları ve dezavantajları nelerdir?

• En başından beri dediğimiz gibi bağımsız bir yapı olması dolayısı ile sistemin geliştirilmesi, iyileştirilmesi (hem teknoloji anlamında hemde ürün anlamanda) çok daha kolay ve performanslı olacaktır.
• Paralel çalışan sistemler olduklarından üzerinde çalışan kişi sayısını dağıtmak kolay olacak ve bir sistem üzerine odaklı geliştirmeler yapılabilecek.
• Çok daha kolay ölçeklenebilir yapıların oluşmasına olanak sağlaması

Birden fazla uygulamamız olduğunu düşündüğümüz durumda;

• Normalden daha fazla sistem yükü getirmesi
• Birden fazla uygulamayı takip etmenin daha zor olması, birbirleri ile ilişkilerinin de zaman içerisinde karışma ihtimalinin olması.
• Daha fazla makine kendi arasında konuşması fiyatlanmanın da artmasına sebebiyet verebilir.

Mikroservis mimarilerinde esas zamanın network üzerindeki geçişlerde olduğunu farklı ağlardaki (networklerdeki) etkileşimin anlık olarak hatalar alabileceğini acı bir şekilde öğrenmemek adına dikkat edilmesi gereken hususları şöyle sıralayabiliriz.

• Kullanıcı arayüzleri, birbiri içine geçmiş ekranlar bizi en çok zorlayan yerlerden olacaktır. Birden fazla hizmete giden alanlar daha çok network sıkıntısı yaratacaktır. Bu yüzden arayüzlerimizi servis yapılarımıza uygun hale getirmeliyiz.
• Yeni teknoloji kullanma isteğinin ağır basmaması gerek. Uygun ve adaptasyonu zor olmayacak şekilde tercihler yapılmalıdır.
• Büyüklük, bir servisin büyüklüğüne karar vermek elimizde minik karışık monolith’lerin oluşmasını engelleyecektir. Kaç tane servisi yönetebileceğimiz ve bütün servisler kompleks hale gelmeden nasıl yöneteceğimizi bilmemiz gerekli.
• Ufak uygulamalarımızı yöneten takımlarımızı oluşturmak, product owner’ın yazılım ekibiyle birlikte çalıştığı ve müşteri gereksinimlerini bildiği bir yapıda olmalıdır. Bu durum uygulamaya hakimiyeti artıracaktır.

Monolitik ve mikroservis mantıklarından bahsederken avantaj ve dezavantajlarını göz önüne almak elbetteki bize yararı olacaktır ama bu demek değildir ki her monolitik kötüdür. Bu durumda bize ışık tutacak 3 düşünceden bahsetmek gerekli

1.Single purpose

• Oluşturulan her yapının sadece tek bir iş yapması ve o işte ustalaşmış olması gibi düşünebiliriz.

2.Loose coupling

• Oluşturduğumuz yapıların birbirleri hakkında çok az bilgiye sahip olması dolayısı ile kendisindeki değişikliklerin diğer ortamları etkilememesini düşünebiliriz.

3.High cohesion

• Birbiri ile alakalı yapıların bir arada bulunduğu yani fonksiyonel veya işlevsellik olarak birbirine bağımlı olan yapıların bir arada bulunması düşüncesi. Kendi içerisinde az bir değişiklik yaparak alakasız yerlerin etkilenmemesini öngörüyor diyebiliriz.

Temel olarak Monolith ve Mikroservis mantıklarının nasıl çalıştıklarını anladık. Hangisini seçerken neye dikkat etme konusu biraz karışık olabiliyor. Genelde dikkat etmeye çalıştığımız hususları kısaca kendi özelimde özetlemek gerekirse ;

Her ne kadar yukarıdaki avantaj ve dezavantajlar bize direk mikroservislerin avantajını göz önüne çıkarıyor olasa bile, Her Monolith kötü her Mikroservis iyidir kanısından çıkmak gerek. Monolith olarak yazılmış, kendi içerisinde tasarımı güzel olan bir uygulama, karışık mikroservis mimarisinden çok daha öndedir. Burda ki en önemli konu coupling ve cohesion mantıklarının dengesinin güzel kurulmuş ve akıcı bir şekilde uygulanması olabilir. Burada bahsetmediğim ama Domain Driven Design mantığı ile kurulmuş yapılarda, micro servisimizi hem ürün hemde sistem açısından daha dayanıklı hale getirmek için her büyümede tekrar gözden geçirmeyi de unutmamalıyız.

Bir sonraki yazımızda mikroservise geçmede aklımıza gelen en temel sorulara cevap arayacağız. Gerçekten ihtiyacımız var mı? Yapılacak olan değişiklik hali hazırda var olan uygulamayı nasıl etkileyecek, takım olarak bu ayrıma hazır mıyız? gibi soruların yanıtlarını arıyor olacağız.

Bu tarz tecrübeleri rahatlıkla edinebileceğin bir yer arıyorsan bekleriz =)

Trendyol jobs