KOBİ yazılımında monolit mi mikroservis mi tercihi, moda mimariden değil ekip ve trafik gerçekliğinden çıkar. Bu rehber, servisleri erken parçalamanın maliyetini ve modüler monolit sınırının neden çoğu üründe yeterli kaldığını anlatır. Kararı sloganla değil iş birleşme noktalarıyla alın.
Bir KOBİ ürününde mimari tartışması çoğu zaman moda kelimelerle açılır. Oysa asıl mesele teknoloji listesinden birini seçmek değildir. Soruyu doğru kurmak gerekir: monolit mi mikroservis mi diye bakmadan önce, henüz trafik ve ekip büyümeden servisleri parçalamanın maliyetini ödemeye değip değmediğini netleştirin.
Dağıtık sistem, ekip sınırlarını ve bağımsız ölçeklemeyi kolaylaştırır. Aynı anda dağıtımı, gözlemi, veri tutarlılığını ve hata ayıklamayı zorlaştırır. Küçük bir üründe bu zorluk, özellik üretmekten daha fazla zaman yer.
Bu rehber, seçimi sloganla değil iş yüküyle kurar. Klasik monolit, modüler monolit ve mikroservis arasındaki farkı KOBİ gerçekliğine indirir. Amaç erken kahramanlık değil; ürünü bozmadan ilerleyecek bir sınır çizmektir.
Monolit mi mikroservis mi sorusunu nereye koymalısınız
Yanlış başlangıç, büyük şirketlerin slaytını kopyalamaktır. Doğru başlangıç üç kısıttır: kim bakacak, ne sıklıkla yayınlanacak, hangi veri birlikte değişmek zorunda.
Tek yazılım ekibi, tek canlı ortam ve sıkı iş kuralları varsa dağıtık servisler size hız kazandırmaz. Kazandırdığı şey, her değişiklikte birden fazla depo, sözleşme ve yayın sırası yönetmektir. Bu, mimari olgunluk değil; erken vergi olabilir.
Monolit, her şeyin iç içe geçtiği bir yığın olmak zorunda değildir. Mikroservis de her sınıfı ayrı süreç yapmak demek değildir. Karar, süreç sınırını nereye çekeceğinizdir: aynı uygulama içinde modül mü, ağ üzerinden servis mi.
Önce iş dilini, sonra süreç sınırını ayırın
Sipariş, stok, fatura ve kullanıcı aynı cümlede geçiyorsa bunlar henüz bağımsız ürünler değildir. Bağımsız ürün, kendi yayın ritmi, kendi hata bütçesi ve kendi veri sahibi olan parçadır. Bu üçü yoksa ağ ile ayırmak yalnızca çağrı gecikmesi ekler.
KepezWeb tarafında özel yazılım işlerinde sık gördüğümüz tablo şudur: ekip henüz aynı kod tabanında bile net modül sınırını konuşmadan servis haritası çizer. Harita güzel durur; günlük iş ise bu alanı kim değiştirir sorusunda takılır.
Trafik gelmeden servis bölmenin faturası
Mikroservisin vaadi nettir: bir parçayı diğerinden bağımsız büyütmek, yayınlamak ve bozmamak. Vaadin bedeli, o bağımsızlığı ayakta tutacak işletim işidir. Trafik düşükken bu bedel grafiklerde görünmez; takvimde görünür.
Dağıtık bir KOBİ kurulumunda görünmeyen işler birikir:
- Her servis için ayrı yayın, yapılandırma ve sürüm uyumu
- Yerel ortamda birçok süreci ayağa kaldırma
- İstek izini servisler arasında takip etme
- Ödeme oldu, stok düşmedi gibi kısmi başarılar
- Rapor ve yönetim ekranlarında veriyi birleştirme zorluğu
KOBİ ekibinde bu maddelerin her biri bir kişi daha demektir. O kişi çoğu zaman aynı geliştiricidir. Özellik yazmak yerine sözleşme kırılması, zaman aşımı ve tekrar deneme ile uğraşır.
Ağ, fonksiyon çağrısı değildir. Gecikme, kısmi başarı ve sıra dışı durum varsayılan hale gelir. Henüz hangi özelliğin tutacağını ararken bu karmaşa, öğrenme hızını düşürür. Erken parçalama ölçek sorununu çözmez; keşif maliyetini yükseltir.
Veri ayrışması en pahalı adımdır
Servisi ayırmak, tabloları kopyalamak değildir. Sipariş stok adedini kendi veritabanında mı tutacak, yoksa her seferinde başka servise mi soracak? İkisi de maliyetlidir. İlki çoğaltma ve uzlaşma ister. İkincisi canlı trafikte bağımlılık üretir.
Tek veritabanını paylaşıp süreçleri ayırmak ise mikroservis değildir; dağıtık monolit olur. Şema değişikliği yine herkesi kilitler. Kazanç sanılan bağımsızlık, ortak tablo yüzünden geri gelir. Bu yüzden süreç ayırmayı veri sahibinden önce düşünmeyin.
Modüler monolit neyi çözer, neyi erteler
Modüler monolit, aynı süreçte çalışan ama birbirine rastgele dokunmayan parçalardır. Sipariş modülü, stok modülünün tablosuna doğrudan yazmaz. Ortak bir uygulama içi arayüz, olay veya açık bir fonksiyon üzerinden konuşur. Sınır kodda vardır; henüz ağda yoktur.
Bu modelin gücü sadedir. Tek yayın, tek izleme, tek yerel çalıştırma. Buna karşılık ekip, hangi klasörün hangi iş diline ait olduğunu bilir. Yanlışlıkla her yere sızan yardımcı sınıflar, ileride servise bölmeyi de zorlaştırır; bugün değiştirmeyi de.
Klasik monolit ile fark buradadır. Klasik monolit, ekrandan veritabanına kadar her katmanın birbirinin alanına girdiği yapıdır. Modüler monolit katmanlı olmayı reddetmez; iş sınırını katmandan üstün tutar.
Ağı, ekip ve yük gerçekten bağımsız olunca çekin. O zamana kadar sınırı kodda tutun.
Modül sözleşmesi ağ sözleşmesinden ucuzdur
Aynı dilde bir arayüz kırmak, dışarıya açılmış bir JSON sözleşmesini kırmaktan daha çabuk fark edilir. Test ve derleme, yanlış kullanımı hemen gösterir. Servisler arasında aynı hata, ancak belirli bir istek yolunda ve belirli bir sürümle ortaya çıkar.
Bu yüzden erken dönemde sınır çizin, ama sınırı süreç olarak çekmeyin. Önce paket, klasör ve veri erişim kuralı. Ağ, gerçekten bağımsız yayın ve bağımsız yük gerektiğinde gelir. Ertelemek ihmal değildir; bedeli görünür kılmaktır.
KOBİ ürününde birleşen veri, birleşen süreç
KOBİ yazılımı genelde birkaç çekirdek akış etrafında döner: kayıt, işlem, listeleme, bildirim, yönetim. Bu akışlar aynı müşteri, aynı sipariş, aynı stok kaydı üzerinde birleşir. Birleşen veri, birleşik bir tutarlılık ister.
Bir e-ticaret sitesi örneğini alın. Katalog, sepet, ödeme ve kargo ekranı kullanıcıya ayrı dünyalar gibi görünür. Veri tarafında ise stok düşümü, sipariş kaydı ve ödeme sonucu aynı anda doğru olmak zorundadır. Trafik tek uygulamayı zorlamıyorken bu akışı üç servise bölmek, tutarlılığı zorlaştırır.
Aynı şey saha servisi, randevu, teklif veya üye paneli için de geçerlidir. Ekranlar çoğalır; iş kuralı tek kalır. İş kuralı tekken süreçleri ayırmak, kuralı çoğaltmak demektir. Çoğalan kural sessizce sapar. Bir sipariş iptalinde stok iadesi bir serviste, iade belgesi başka serviste farklı yorumlanırsa müşteri kaydı değil, işletme kaydı bozulur.
Yeterlilik ölçütü mikroservis kullanıyor muyuz sorusu değildir. Ölçüt şudur: bir geliştirici yeni bir iş kuralını tek yerde, güvenle değiştirebiliyor mu? Değiştirebiliyorsa mimari, ekibin ölçeğine uygundur.
Özel yazılım tarafında PHP ve ilişkisel veri hâlâ birçok KOBİ ürününün omurgasıdır. Özel PHP/MySQL yazılım işinde de aynı ilke geçerlidir: şemayı erken parçalamak yerine, modülün hangi tablolara yazabileceğini netleştirmek daha ucuz bir disiplindir.
Servis adayını nasıl ayırt edersiniz
Mikroservis yasak değildir. Erken varsayılan olmaması gerekir. Aşağıdaki sinyaller bir araya geldiğinde süreç sınırını tartışmak mantıklıdır.
- Belirli bir parça, geri kalanından belirgin biçimde farklı yük altında kalıyor
- O parçanın yayın ritmi ayrı; sık deneme diğer ürünü riske atıyor
- Ayrı bir ekip, o parçanın veri ve hata bütçesinin gerçek sahibi
- Modül sınırı kodda oturmuş; rastgele tablo erişimi kalmamış
- Gözlem ve yedekleme bu parçayı tek başına taşımaya yetiyor
Tek sinyal yetmez. Ödeme hassas diye ödeme servisi açmak, kart verisini daha güvenli kılmaz. Güvenlik, ağ sayısıyla değil erişim, günlük, anahtar ve yetki tasarımıyla gelir. Hassas parça önce modül ve sıkı kapı olarak ayrılır.
Yük de tek başına gerekçe olmayabilir. Kuyruk, önbellek ve arka plan işi, tek süreç içinde de yükü yumuşatır. Servis çıkarmak, ölçeklemenin ilk adımı değil son adımlarından biri olmalıdır.
Parçalamadan önce kapatılacak kaçaklar
Mimariyi büyütmeden önce mevcut monolit içinde yapılabilecek işler vardır. Bunlar ileride mikroservis vaadi değil; bugünün okunabilirlik ve yayın güvenliği işleridir.
- İş diline göre modül klasörleri açın; ortak yardımcılar çöplüğünü kapatın.
- Modül dışı tablo yazımını yasaklayın. Okuma bile gerekçeli olsun.
- Uzun süren işi istek döngüsünden çıkarın: e-posta, belge üretimi, dış API.
- Yayını küçük ve sık tutun. Büyük paket, monolit olsun olmasın risklidir.
- Kritik akış için izlenebilir günlük ve iş olayı kaydı tutun.
- Testi katmana göre ayırın: kural birim testi, sınır entegrasyon testi.
Bu adımlar, ileride bir modülü servise çevirmeyi de kolaylaştırır. Çünkü servis adayı zaten kendi verisine ve kendi arayüzüne sahip olur. Tersini yapmak, dağınık kodu sonradan yalıtmak, çok daha pahalıdır.
KepezWeb olarak yazılım geliştirme işinde mimariyi bu sırayla ele alırız: önce iş sınırı, sonra yayın ve gözlem, en sonda süreç ayrımı. Sıra tersine dönünce ekip mimariyle değil, kendi araç zinciriyle boğuşur.
Kararı bir çalışma ile kilitleyin
Karşılaştırmayı ezberlemeden önce üç modeli KOBİ ölçütüyle yan yana görün. Bu noktada soru, süreç sayısı değil sahiplik ve birleşme sorusuna döner.
| Ölçüt | Klasik monolit | Modüler monolit | Mikroservis |
|---|---|---|---|
| Yerel çalıştırma | Tek uygulama | Tek uygulama, net paketler | Birden fazla süreç ve sözleşme |
| Yayın | Tek paket; iç sınır zayıfsa her değişiklik riskli | Tek paket; sınırlı alan daha güvenli değişir | Bağımsız yayın; sürüm uyumu işi doğar |
| Veri | Ortak şema, serbest erişim | Ortak veritabanı olabilir; yazma hakkı sınırlı | Ayrı veri; birleşik rapor ve tutarlılık maliyeti |
| Hata yalıtımı | Bir sızıntı her yeri etkiler | Bellek aynıdır; iş kuralı yalıtılabilir | Süreç yalıtımı var; kısmi hata tasarımı şart |
| Ekip uyumu | Herkes her yere dokunur | Alan sahipliği kodda görünür | Alan sahipliği ekip ve sözleşmede görünür |
| Ne zaman uygun | Çok küçük, kısa ömürlü iş | Çoğu KOBİ ürünü | Kanıtlanmış yük, ayrı ritim, ayrı sahip |
Tablo bir sıralama değildir. Klasik monolit kötü, mikroservis ileri anlamına gelmez. Uygunluk, ürünün birleşme noktalarına ve ekibin gerçek kapasitesine bağlıdır.
Kararı toplantı sloganıyla değil kısa bir çalışma ile alın.
- Çekirdek akışları yazın: sipariş oluştur, stok düş, ödeme kaydet gibi.
- Her akışta hangi kayıtların aynı anda doğru kalması gerektiğini işaretleyin.
- Kodda bugün bu kayıtlara kimlerin yazdığını listeleyin. Sızıntı varsa önce onu kesin.
- Yük ve yayın acısını ayırın: hangi parça gerçekten ayrı ritim istiyor?
- Ayrı ritim yoksa modüler monolit sınırını yazılı kurala çevirin.
- Ayrı ritim ve ayrı sahip varsa yalnızca o parçayı aday yapın; her şeyi birden bölmeyin.
Bu çalışma, hepsini mikroservis yapalım tartışmasını somut bir haritaya indirir. Haritada boş kalan yer henüz servis değildir; henüz bilinmeyen iştir. Bilinmeyeni dağıtmak, belirsizliği çoğaltır.
Mimari, ekibin günlük hızını korumak için vardır. Hızı düşüren her dağıtık parça, gerekçesini düzenli olarak yeniden kanıtlamalıdır. Kanıt yoksa sınırı geri alın. Süreç birleştirmek de bir mimari karardır.
Sıkça Sorulan Sorular
Küçük ekip mikroservisle başlarsa daha mı rahat büyür?
Hayır. Küçük ekip önce iş kuralını tek yerde tutarak büyür. Erken servis haritası, büyümeyi değil işletim yükünü öne çeker. Büyüme sinyali geldiğinde yalıtılmış bir modülü ayırmak, dağınık kodu ayırmaktan kolaydır.
Modüler monolit ileride mikroservise dönüşür mü?
Dönüşebilir; otomatik dönüşmez. Dönüşümün şartı, modülün kendi verisine ve kendi arayüzüne sahip olmasıdır. Bugün her yerden tablo okuyan bir yapı, yarın zaten modülerdi diye servise çıkmaz.
Veritabanını şimdiden servis bazında ayırmak gerekir mi?
Gerekmez. Önce yazma haklarını ayırın. Ortak okuma bir süre idare eder. Şemayı erken parçalamak, rapor ve yönetim ekranlarını zorlaştırır; getiri ise çoğu KOBİ yükünde belirsizdir.
Performans sorunu mikroservis gerektirir mi?
Çoğu zaman hayır. Önce yavaş sorgular, gereksiz senkron dış çağrılar ve istek içinde yapılan ağır işler gelir. Bunlar tek süreçte de çözülür. Mikroservis, belirli bir parçanın gerçekten bağımsız ölçeklenmesi gerektiğinde konuşulur.
Yönetim paneli ve müşteri uygulaması ayrı servis olmalı mı?
Ayrı arayüz olabilir; ayrı süreç şart değildir. Panel ve müşteri yüzü aynı iş kuralını paylaşıyorsa kuralı iki kez yazmak sapma üretir. Ayrılacak şey sunum katmanıdır, çekirdek kural değil.
Mimari seçimi ürününüzün birleşme noktalarına göre netleştirmek istiyorsanız KepezWeb ile konuşabilirsiniz. Mevcut kod tabanındaki sınırları, yayın riskini ve gerçekten servis adayı olan parçaları birlikte işaretleriz. Kısa bir keşif için teklif alın.
