Monolit mi mikroservis mi? Mimariyi işletme ihtiyacına bağlamak

Yeni müşteri portalı için yapılan toplantıda konu kısa sürede mikroservislere geliyor. Henüz hangi işlerin birlikte değiştiği, sistemi kimin işleteceği ve gerçek yükün nerede oluşacağı bilinmiyor. Buna rağmen mimari etiket, projenin kalitesini anlatan bir vaat gibi kullanılabiliyor. Oysa monolit veya mikroservis kararı, işletmenin gelişme ve çalıştırma koşullarını taşıyabildiği ölçüde anlamlıdır.

Bu karar tek başına modernlik tercihi değildir. Yayınlama düzenini, veri akışını, hata incelemeyi ve ekiplerin birbirine bağımlılığını etkiler. Bir mimarinin uygunluğunu anlatmak için yalnızca sağlayabileceği yararları değil, günlük işleyişte hangi yeni sorumlulukları getirdiğini de konuşmak gerekir. İşletme açısından soru, uygulamanın kaç parçaya bölüneceğinden önce hangi ihtiyacın karşılanacağıdır.

İsimlerin arkasındaki farkı sadeleştirin

Monolit bir uygulama temel işlevlerini genellikle tek dağıtım birimi içinde çalıştırır. Bu, kodun düzensiz olması gerektiği anlamına gelmez. Müşteri, sipariş ve raporlama gibi alanlar kendi kuralları olan modüller şeklinde düzenlenebilir. İç sınırlar açık tutulduğunda tek yayın birimiyle çalışmak, bütün kodun birbirine kontrolsüz biçimde bağlı olduğu bir yapı olmak zorunda değildir.

Mikroservis yaklaşımında iş yetenekleri ayrı çalıştırılabilen ve yayınlanabilen hizmetlere ayrılır. Bu ayrım, yalnızca kod klasörlerini çoğaltmak değildir; hizmetlerin haberleşmesi ve verinin sahipliği de tasarlanır. Bir parçayı bağımsız değiştirebilme imkânı yeni koordinasyon görevleriyle birlikte gelir. Birbirini sürekli bekleyen hizmetler, adları ayrı olsa bile işletme açısından gerçek bağımsızlık sağlamayabilir.

Bu yüzden başlangıç görüşmesinde çizilecek kutulardan önce değişim ihtiyacı konuşulur. Hangi bölüm daha sık değişiyor? Kim hangi bölümden sorumlu? Bir işlevin kapasite ihtiyacı diğerlerinden gerçekten farklı mı? Soruların yanıtı yokken ayrıntılı dağıtım şeması çizmek, henüz bilinmeyen iş sınırlarını teknik altyapıda sabitleyebilir.

Kullanıcı sayısı tek başına mimari seçmez

“Çok kullanıcımız olacak” beklentisi değerlendirme için yeterli değildir. Aynı anda yapılan işlemler, kayıtların boyutu, sorguların niteliği ve dış sistemlerin yanıt süresi önemlidir. Çok sayıda hesabın bulunduğu fakat seyrek kullanılan bir portal ile az kişinin ağır rapor ürettiği uygulama farklı darboğazlar yaşayabilir. Tahminin hangi kullanım senaryosuna dayandığını açıklayın.

Performans sorununun kaynağı bilinmeden uygulamayı bölmek çözüm üretmeyebilir. Gereksiz veri okuyan bir sorgu veya uzun süren dış servis çağrısı yeni yapıda da yavaş kalabilir. Ölçüm, temsil edici yük ve gerçekçi veri örnekleriyle yapılmalıdır. Kritik işlem için kabul edilebilir davranış tanımlandığında teknik seçenekler aynı ihtiyaca göre karşılaştırılabilir.

Kapasite planı tek bir büyüme hayaline dayanmasın. Yakın dönem ihtiyacı, izlenecek göstergeler ve yeniden değerlendirme koşulları belirlenebilir. Böylece işletme olası geleceğe tamamen kayıtsız kalmadan, gerçekleşmemiş yük için bugünden gereksiz işletim yükü üstlenmez. Mimari karar bir kez verilen ve asla incelenmeyen hüküm değildir.

Ekip düzeni, teknik bağımsızlığın karşılığıdır

Ayrı hizmetlerin sahipleri belirsizse arıza ve değişikliklerde sorumluluk tartışması doğabilir. Bir hizmetin geliştirilmesi, test edilmesi, yayınlanması ve izlenmesi için yeterli çalışma düzeni gerekir. Küçük bir ekibin çok sayıda hizmeti yönetmesi mümkündür; ancak parça sayısının artması bu görevleri kendiliğinden ortadan kaldırmaz.

Bağımsız yayın hedefleniyorsa ortak değişikliklerin sıklığı incelenmelidir. Bir alan eklendiğinde bütün hizmetlerin aynı gün güncellenmesi gerekiyorsa sınırlar beklenen esnekliği vermiyor olabilir. Haberleşme sözleşmelerinin uyumu ve eski sürümlerle geçiş davranışı değerlendirilir. İşletmenin gördüğü sonuç, teknik bölünmenin gerçekten daha güvenilir değişim üretip üretmediğidir.

Tek ekipli bir projede iyi düzenlenmiş modüler yapı daha anlaşılır bir başlangıç olabilir. Birden çok bağımsız ekibin belirgin iş alanlarını yönettiği projede farklı seçenekler değer kazanabilir. Bunlar kesin kurallar değildir. Ekibin deneyimi, mevcut altyapı ve ürünün belirsizlik düzeyi birlikte değerlendirilir; yalnızca çalışan sayısına bakılarak karar verilmez.

Veri sınırı net değilse hizmet sınırı da zorlanır

Kurgusal bir bakım işletmesinde teklif onaylandığında iş emri ve tahmini malzeme ihtiyacı oluşsun. Teklif, operasyon ve stok bölümleri aynı bilgiyi farklı amaçlarla kullanır. Bu alanları ayırırken hangi sistemin hangi kaydın doğru kaynağı olduğu belirlenmelidir. Aynı veriyi birden fazla hizmette düzenlemek tutarsız sonuçlara yol açabilir.

İşlem birkaç parçadan oluşuyorsa başarısızlık davranışı da konuşulur. Teklif onaylanmış fakat iş emri henüz oluşturulamamışsa kullanıcı ne görür? Tekrar deneme aynı emri iki kez üretir mi? Bekleyen durum nasıl takip edilir? Bu sorular bölünmüş yapıda belirginleşebilir, ancak çözümün biçimi işin kabul edilebilir davranışına bağlıdır.

Bütün adımların anında birlikte tamamlanması gerçekten gerekli mi, yoksa belirli bir gecikme kabul edilebilir mi? Cevap mimariyi etkiler. Kullanıcının bekleyen durumdan habersiz bırakılması ayrı, kontrollü bir bekleme akışının tasarlanması ayrıdır. Teknik bir yaklaşımın doğal sonucu gibi görünen davranış, işletmenin açıkça kabul ettiği bir karar olmalıdır.

Bir parçanın hatası bütün sistemi durdurmayabilir; tasarım önemlidir

Hizmetleri ayırmak otomatik dayanıklılık garantisi vermez. Ana işlem her adımda diğer bütün hizmetlerin yanıtını bekliyorsa bir parçanın durması geniş etki yaratabilir. Zaman aşımı, tekrar deneme, geçici durdurma ve kuyrukta bekleme gibi davranışlar ihtiyaca göre tasarlanır. Her hatada sınırsız tekrar yapmak mevcut yükü artırabilir.

İşletme açısından geçici alternatifler tanımlanabilir. Bildirim gönderilemese de kayıt güvenle tutulabilir; kullanıcıya gönderim durumunun beklediği gösterilebilir. Ödeme veya yetki kontrolü gibi bir adımda ise devam etmek uygun olmayabilir. Hangi işlemin hangi koşulda duracağı, teknik ekibin tek başına varsayacağı bir ayrıntı değildir.

Dayanıklılık iddiası denemeyle desteklenmelidir. Bir bağlantı erişilemez olduğunda, yanıt geciktiğinde veya aynı mesaj yeniden geldiğinde ne olduğu kontrollü ortamda incelenir. Denemenin amacı gösterişli bir altyapı sunumu yapmak değildir; kullanıcı ve veri açısından kabul edilebilir davranışın gerçekten oluştuğunu görmektir.

İşletim maliyetini geliştirme bedelinden ayrı inceleyin

Ayrı dağıtım birimleri, izleme ve sorun inceleme düzeninin kapsamını değiştirebilir. Bir kullanıcı işleminin nerede takıldığını anlayabilmek için parçalar arasında ilişki kurulması gerekir. Yapılandırma, erişim bilgileri ve sürümlerin takibi de planlanır. Kullanılan yönetilen hizmetler bazı görevleri kolaylaştırabilir; sorumlulukları tamamen ortadan kaldırmaz.

Monolit yapıda da işletim işi vardır. Güncelleme, veri tabanı, yedek, erişim ve kapasite izlenmelidir. Dolayısıyla karşılaştırma “işletim gerektiren” ile “gerektirmeyen” sistem arasında yapılmaz. Her seçeneğin hangi işleri hangi ekibe yüklediği ve bu işlerin nasıl karşılanacağı değerlendirilir. Toplam maliyet, yalnızca ilk geliştirme faturası değildir.

İşletme, bakım ekibinin kullandığı araçlara ve bilginin tek kişide toplanma riskine de bakmalıdır. Altyapı açıklanabilir ve devredilebilir olmalıdır. Geliştirme bitiminde sistemi başka yetkili bir ekibin çalıştırabilmesi, dokümantasyonun kullanılabilirliğini sınamak için yararlı bir adımdır. Mimari seçimin sürdürülebilirliği bu devir koşulunda da görünür olur.

Baştan bütünü değiştirmek tek geçiş yolu değildir

Mevcut uygulamanın sorunları tek bir alanla sınırlıysa o alanın ayrılması değerlendirilebilir. Yoğun rapor üretimi veya belirgin bir dış bağlantı, sınırları yeterince anlaşıldığında ayrı bir çalışma biçimine taşınabilir. Bunun uygunluğu veri akışı ve işletim etkisiyle birlikte incelenir. Her eski uygulamayı bütünüyle yeniden yazmak zorunlu değildir.

Geçiş sırasında eski ve yeni davranışların nasıl birlikte çalışacağı belirlenir. Hangi kayıt hangi sistemden okunacak, tutarlılık nasıl doğrulanacak, sorun olursa hangi adım geri alınabilecek? Kullanıcıların aynı işi iki yerde yürütmesi gerekiyorsa bu geçici yükün süresi ve sorumlusu açıklanmalıdır. Geçişin kendisi ayrı bir proje işi olarak görünmelidir.

Yeni yapının değerini değerlendirmek için başlangıçtaki soruna dönün. Yayın süresi, hata etkisi veya belirli işlem yükü gibi bir sorun hedeflenmiş olabilir. Sonucun hangi kanıtla gözden geçirileceği önceden konuşulur. Teknoloji değişmiş olması tek başına hedefe ulaşıldığını göstermez; beklenen işleyişin değişip değişmediği incelenir.

Karar notunda alternatifleri ve yeniden bakma koşulunu yazın

Seçilen yaklaşım, değerlendirilen diğer seçenekler, önemli varsayımlar ve kabul edilen sınırlamalar kısa bir kayıtta tutulabilir. Gelecekte ekibe katılanlar böylece kararın bağlamını görür. O günün koşulları değişmişse yeniden inceleme yapılabilir; eski seçimi yalnızca etiketine bakarak savunmak veya reddetmek gerekmez.

İş alanları ve değişim ihtiyacı henüz belirsizse özel yazılım projesinin keşif çalışması mimari kararı besleyecek örnekleri ortaya çıkarabilir. Amaç en çok teknik bileşeni kullanan şemayı seçmek değildir. Kullanıcının işini güvenilir biçimde tamamlayan, ekibin işletebildiği ve gerektiğinde değiştirilebilen bir yapı üzerinde anlaşmaktır.

İlk toplantıda istenecek kanıtı belirleyin

Teknik öneriyi sunan ekipten yalnızca yarar listesi istemeyin. Önerinin hangi iş akışına dayandığını, hangi sorunu çözmeyi hedeflediğini ve hangi ek işi gerektirdiğini anlatmasını isteyin. Teklifte adı geçen bileşenlerin günlük sorumluluğu açıklanabilmelidir. Bazı kararlar henüz verilmemişse bunların nasıl araştırılacağı ve ne zaman netleşeceği belirtilir.

Bir tasarımın karmaşıklığı her zaman gereksiz olduğu anlamına gelmez. Fakat gerekliliği iş örneğiyle açıklanamayan karmaşıklık sorgulanmalıdır. Aynı biçimde basit görünmesi de seçeneği otomatik doğru yapmaz; kritik ihtiyacı karşılayıp karşılamadığı denenmelidir. Değerlendirme, teknik yaklaşımın adını beğenmekten çok sonuçlarını anlamaya dayanır.

Sınırlar değiştiğinde kullanıcı deneyimi parçalanmasın

Arka planda farklı hizmetler çalışması, kullanıcının işini ayrı sistemlere bölmesini zorunlu kılmamalıdır. Ekranların durumları tutarlı olmalı; bekleyen işlem, hata ve tamamlanma bilgisi anlaşılır biçimde sunulmalıdır. Kullanıcı teknik dağıtımı bilmeden de ne olduğunu ve bir sonraki adımını anlayabilmelidir.

Ayrı ekipler aynı kavramı farklı adlandırıyorsa ortak ürün dili oluşturulur. Bir yerde tamamlandı görünen işlemin başka yerde hâlâ bekliyor olması açıklama gerektirebilir. Tarih, durum ve kayıt numarası gibi bilgilerin nasıl gösterildiği üzerinde anlaşmak bu nedenle teknik tasarımın yanında önem taşır. Mimari seçenekler değerlendirilirken uçtan uca deneyimin sorumlusu da belirlenmelidir.

Sık Sorulan Sorular

Monolit uygulama mutlaka eski teknoloji mi kullanır?

Hayır. Dağıtım biçimi ile kullanılan teknolojinin yaşı aynı konu değildir. Güncel araçlarla geliştirilen bir uygulama tek dağıtım birimi olabilir. Önemli olan kodun düzeni, iş sınırları, test edilebilirlik ve sistemin ihtiyaca uygun biçimde işletilmesidir.

Mikroservisler performansı otomatik artırır mı?

Hayır. Belirli parçaların ayrı kapasiteyle çalışması yarar sağlayabilir, ancak hizmetler arası haberleşme ve veri tasarımı yeni maliyetler getirir. Mevcut darboğaz ölçülmeden yalnızca uygulamayı bölmek performans sorununu çözmeyebilir. Karar temsil edici kullanım üzerinden doğrulanmalıdır.

Küçük ekip mikroservis kullanamaz mı?

Kullanabilir; belirleyici nokta yalnızca kişi sayısı değildir. Ekibin deneyimi, hizmet sayısı, işletim araçları ve sahiplik düzeni önemlidir. Geliştirme kadar izleme, yayınlama ve arıza müdahalesinin de karşılanabileceği bir plan bulunmalıdır.

Modüler monolit daha sonra bölünebilir mi?

Sınırlar ve bağımlılıklar dikkatle yönetilirse belirli alanların ayrılması kolaylaşabilir. Bunun kendiliğinden veya maliyetsiz olacağı söylenemez. Veri sahipliği, haberleşme ve geçiş davranışı yine değerlendirilir. Modüler düzen, gelecekteki seçenekleri konuşmak için daha anlaşılır bir temel sağlayabilir.

Mimari kararını işletme yöneticisi mi vermeli?

Teknik değerlendirmeyi yetkin ekip yapmalıdır; işletme ise iş öncelikleri, kesintiye tolerans, bütçe ve değişim beklentisini açıklamalıdır. Karar bu bilgilerin birlikte değerlendirilmesiyle oluşur. Teknik terimlerin bilinmemesi, işletmenin sonuçları anlamadan bütün riskleri kabul etmesini gerektirmez.