☑️
DevOps - Notlarım
  • 🎒MikroServis Mimarisi
    • 🏴‍☠️Yol Haritamız
    • ☕Monolith'den Mikroservis'e
    • 🧙Transaction Yönetimi
    • 🎋Veri Tabanı Tasarımı
    • 📵Servisler Arası İletişim
    • 📜DDD ve Mikroservis Mimari
    • 📡Entegrasyon Testi
    • 😎Loglama ve Monitoring
    • 🏁Sonuç
  • 🍄GIT-GITHUB
    • Git - Github - Giriş
    • Branch
    • Merge
  • ✅Cheat Sheet
    • Encoding vs Encryption vs Tokenization
    • Cloud Services
    • Devops-CI-CD
    • CI-CD
    • Cloud Database Landscape
    • Cloud Disaster Recovery Strategies
    • Cloud IAM Best Practice
    • Cloud Native
    • Components of A URL
    • Components of Kubernetes
    • Data Stracture CheatSheet
    • Database Connections Pool
    • Devops and Cloud Key Metric
    • Devops Life Cycle
    • DevOps SRE Raod Map
    • Doceker vs Kubernetes
    • Forward Proxy vs Reverse Proxy
    • Git Cheat Sheet
    • Helm Cheat Sheet
    • How DNS Work
    • HTTP Status Code
    • Kubernetes Commands Cheat Sheet
    • Kubernetes Cost Reduction Tecniques
    • Kubernetes Ecosystem
    • Kubernetes Porduction Reality
    • Kubernetes Troubleshooting Cheat Sheet
    • Linux Command Cheat Sheat
    • Microservice Best Practice
    • Monolithic vs Microservice Architechture
    • Multi Cloud Databese Picker
    • Never ingnore these 7 commands
    • OpenShift Archtitect
    • Microservice RoadMap
    • Scrum vs Kanban
    • Software Architecture Styles
    • Software Architectures
    • Software Enginering Nuttshell
    • System Desing Interview
    • Type Of Database
    • The Elements of Cloud Pyramid
    • Top Tools Used in Devops
    • 8 Archtitectural Styles
    • 7 Step For Api Perfomance
    • 5 Deployment Patern
    • 10 Key Jenkins Pipelines HouseKeeping Routines
    • 12 Cloud Burn Outs
    • Architecture Netflix
    • ASCII-Table-wide
    • Aws-Azure-Google-Oracle-Cloud
    • Azure Devops
    • Basic Server Types
    • Cloud Cost Reduction Techniques
    • Cloud Database Landscape
    • What is OSI model
    • Chat GPT Prompt
    • How does SSO work
    • How do Message Queues Evolve
    • API Architectural Styles Comparison
    • Cache Systems Every Developer Should Know
    • Essential DevOps Concepts
    • How do C++ Java Python work
    • Top 5 Kafka Use Cases
    • Why is Kafka Fast
    • 10 QUESTIONS quality of decision making
    • End to End Software Development Life Cycle
    • Networking Crash Course
    • What is Observability
    • Rest vs GraphQL
    • Statefull Set
    • System Design Cheat Sheet
  • 🤣MeMes
    • Github
    • Continers
    • What Gives People Feelinfs
    • Kubernetes Solve Problem
    • Kubernetes Update
    • Docker Inc. 2014
    • DevOps Before After
    • Kubernetes Real Life
    • Kubernetes Solve Problem
  • ☁️Cloud Provider
    • Cloud Servis Sağlaycılar
    • Kim ne hizmet sunuyor.
  • 🪨CNCF
    • CNCF
  • 🛠️Tools
    • Encode and Decode
  • 🧮Kubernetes Backup
    • Yedekleme yazılımları
  • 🖖ANSIBLE
    • 😎Giriş
    • 🐛Yaml
    • ⌨️Componentler
    • 🫚Inventory
    • ✈️ad-hoc
    • 🔘Playbook
  • Ne nedir - Kısaca tanımlar
    • Git
    • CI/CD
    • Azure DevOps
  • 🥟Docker
    • Docker Cheat Sheet
Powered by GitBook
On this page
  1. MikroServis Mimarisi

Monolith'den Mikroservis'e

Mevcut Monolith Uygulamanın Mikroservis Mimari'ye Dönüşüm Serüveni

Bir önceki bölümde yeni bir projeye başlarken Monolith Mimari ile başlamanın daha doğru bir karar olacağını belirtmiş olsak da, Mikroservis Mimari ile başlangıç yapmak her koşulda yanlış olur gibi kesin bir ifade kullanmaktan da kaçınmalıyız. Dolayısıyla Mikroservis Mimari'ye geçiş için iki ana senaryomuz var diyebiliriz;

İlki, mevcut Monolith Mimarinin dönüşümü ve diğeri doğrudan Mikroservis Mimari ile başlama.

İlerleyen bölümlerde detaylıca inceleyeceğimiz; Transaction Yönetimi, Servisler Arası İletişim, Veri Tabanı Tasarımı gibi konular her iki senaryo için de geçerli olmakla beraber, mevcut monolith mimarinin dönüştürülmesi senaryosu ekstra bazı zorluklar ihtiva etmekte. Bu bölümde biraz bunlardan bahsedeceğiz. DDD ve Mikroservis Mimari konu başlığında da bu dönüşüm konusuna atıfta bulunduğumuzu ayrıca belirtmek isterim.

Dönüştürme İşlemine Nereden Başlamalıyız?

Dönüşüm işleminin toplam süresi, dolayısıyla harcanacak toplam efor, uygulamanın bağımlılık ve karmaşıklık seviyesiyle doğrudan ilişkilidir. Birbirine sıkı sıkıya bağlı katmanlar ve modüllerden oluşmuş, ağırlıklı olarak iyi pratiklere uyulmadan geliştirilmiş bir uygulamanın dönüşüm sürecinin daha sancılı geçeceğini tahmin etmek zor değil. Bunun yanında modüler tasarlanmış ve gevşek bağlı, değişime kapalı ancak gelişime açık yapıdaki bir uygulamada ise işimiz daha kolay olacaktır. Buradan, modüler ve gevşek bağlı tasarımın ileride Mikroservis Mimari dönüşüm yapılması planlanan projeler için çok daha önemli hale geldiği sonucunu çıkarabiliriz.

Dönüşümü yapılacak olan uygulama hali hazırda kullanılmakta olan bir ürün ve mevcut monolith yapı üzerine aktif olarak geliştirmeler ve hata ayıklama işlemleri devam ediyor. Haliyle tüm bu geliştirme sürecini durdurup, Mikroservis Mimari dönüşümünü yapma gibi bir lüksümüz olmayacaktır. Nefes alan, üzerinde aktif olarak geliştirme yapılan bir uygulamayı dönüşme gibi zorlu bir işimiz var.

Bu dönüşüm işini 'kodları birbirinden ayırma' gibi basit bir seviyeye indirgemek yapacağımız ilk yanlış olacaktır. Öyle ki, kodları servisler halinde ayrışma işi bu dönüşüm sürecinin belki de en kolay işi olacaktır.

Öncelikle kısa ve uzun vadelik eylem planları hazırlamamız gerekmekte. Mevcut monolith uygulamadan kaç adet servis doğacak, ve bu servislerin sınırlanır neler olacak soruları cevap bekleyen en zor sorular olarak karşımıza çıkacaktır. Bu sorularak nasıl cevap vermeliyiz, servislerin sınırlarını nasıl çizmeliyiz gibi konulara DDD ve Mikroservis Mimari konu başlığında örnek bir senaryo üzerinden ele alacağımızdan, burada detayına girmiyoruz.

Uzun ve hararetli toplantılar sonunda servislerimiz ve bu servislerin sınırlarını belirledik. Domain-Driven Design ile ilerleyeceksek, Bounded-Context'lerimiz ve bunların sınırlarını doğru bir şekilde belirlemiş olmalıyız. Ne demiştik, mevcut monolith uygulama hayatına devam ediyor, öyleyse servislerimizi monolith yapıdan birer birer kopararak kontrollü bir şekilde devreye almamız gerekmekte.Dönüşümü tamamlayana dek, monolith bir uygulamamız ve belirli sayıda Mikroservis ile hayatımıza devam edeceğimiz anlamına geliyor bu.

Burada kişisel bir tavsiye olarak şunu söyleyebilirim; İlk servisi mümkün olduğunca basit ve ayırması kolay olan bir servis olarak seçmenizdir. Gerek servisi geliştirme süreci gerekse DevOps anlamında bu sizin acemilik döneminiz olacağından servisin basit olması hızlı çıktı almanızı sağlayacaktır. Genelde benim aklıma ilk gelen notifikasyon servisi oluyor. Hemen her uygulamada, e-posta ve sms gibi bildirimleri göndermekle yükümlü bir modülümüz oluyor ve bu modülün pek bir bağımlılığı da olmuyor diğer modüllerle. Dolayısıyla notifikasyon işini yapmakla sorumlu modülü monolith yapıdan koparıp istediğiniz bir teknolojiyle servis haline getirerek başlangıç yapabilirsiniz. Eğer bu servis bir veri tabanına ihtiyaç duyuyorsa, mevcut veri tabanınızdaki ilgili tabloları ayrı bir ilişkisel veya NoSQL veri tabanına taşıyarak tam izolasyonu sağlayabilirsiniz. Her servisin mutlaka kendine ait bir izole veri tabanı olması gerektiğini unutmamalısınız. Veri tabanını servisler özelinde parçalama konusuna Veri Tabanı Tasarımı konu başlığında yine örnek bir senaryo üzerinden daha detaylı değineceğiz.

Bir diğer önemli nokta ise, dönüşüm sürecindeyken gelecek yeni bir talebin konumlandırılması konusudur. Konumlandırmadan kastımız geliştirmenin nerede yapılacağı. Burada 3 farklı ihtimal söz konusu;

a) Mevcut Monolith b) Mevcut Mikroservis'lerden birisi c) Yeni bir Mikroservis

Eğer gelen bu yeni istek uygulamamız için tamamen yeni bir özellik anlamına geliyorsa yeni bir Mikroservis olarak geliştirmek önceliğiniz olmalı. Eğer mevcut modüllerden birisiyle bağlantılıysa doğru konumlandırmak o kadarda kolay olmayabilir. Eğer servis sınırlarımızı (Bounded Contex'lerimizi de diyebiliriz) doğru bir şekilde çizdiysek, bu 3 seçenek arasında en doğru olanı çok zorlanmadan bulabiliriz. Aksi halde her yeni gelen istek için bu 3 seçenek arasında kalma ve yanlış kararlar verme ihtimalimiz olacaktır. Bu yüzden servis sınırlarının doğru olarak çizilmesi konusu büyük öneme sahip.

PreviousYol HaritamızNextTransaction Yönetimi

Last updated 1 year ago

🎒
☕