10 yıllık eski sistemi yeniliyoruz, geliştirici 'mikroservis' diyor — küçük ürün için doğru karar mı?

Serkan Ç***8 ay önce·47 mesaj·6,7 B görüntülenme#yazılım mimarisi #mikroservis #eski sistem #yazılım yenileme

Serkan Ç***VeteranTopluluk üyesi

Katılım: May 2023
Mesaj: 294

8 ay önce#1

ABD'de lojistik acentelerine yönelik B2B yazılım hizmeti sunuyoruz. 2014 yılında geliştirilmiş zamanla eklemelerle büyümüş tek parça bi çekirdek uygulamamız var. Günlük yaklaşık 1.200 aktif kurumsal kullanıcı sisteme giriyor ve veri girişi yapıyor. valla sistemin bakımı artık çok zorlaştı basit bi fatura güncellemesi bile beklenmedik yerleri bozabiliyor. Bu yüzden sistemi sıfırdan modern bi altyapıyla yenilemek icin 70.000 dolar bütçe ayırdık.

Ekibimize yeni katılan kıdemli yazılımcı, sistemi kesinlikle mikroservis mimarisine bölmemiz gerektiğini, kimlik doğrulama faturalama operasyon ve raporlama için ayrı servisler kurmamızı öneriyor. Ancak ekibimiz sadece 3 yazılımcıdan oluşuyor ve bünyemizde ayrı bir bulut altyapı uzmanı bulunmuyor.

Bu büyüklükteki bi sistem ve 3 kişilik bi ekip icin mikroservis yaklaşımı doğru bi adım mı yoksa altından kalkamayacağımız bi operasyonel yük mü alırız? işte eski yazılım yenileme sürecinde mikroservis ile temiz bi monolit arasında nasıl bi yol izlemeliyiz?

Nuri G***KatılımcıTopluluk üyesi

Katılım: Haz 2025
Mesaj: 158

8 ay önceEn çok yardımcı olan#2

Kısa cevap: Üç kişilik bir geliştirme ekibi ve 1.200 aktif kullanıcı için mikroservis mimarisi seçmek operasyonel bir hatadır. Şu anki ölçeğinizde ihtiyacınız olan şey dağıtık bir sistem değil; iyi yapılandırılmış, modüler ve otomatik testleri yazılmış tek parça modern bir yazılımdır.

Mikroservisler yazılımın performansından ziyade organizasyonel ölçekleme sorununu çözer; yani onlarca farklı mühendislik ekibinin birbirine bağımlı olmadan kod dağıtmasını sağlar. Ancak bunun karşılığında muazzam bir karmaşıklık getirir. Dağıtık veri tabanları, servisler arası ağ gecikmeleri, veri tutarlılığı riskleri ve dağıtık hata ayıklama süreçleri, 3 kişilik bir ekibin zamanının büyük kısmını iş mantığı üretmek yerine altyapı yönetmeye harcamasına yol açar.

Sizin durumunuzda doğru yol haritası şöyle olmalıdır: 1) İş sınırlarını net belirleyip kod tabanını bağımsız modüllere ayırarak monolitik yapıyı temizleyin, 2) Veri tabanını normalize edip otomatik test kapsamını artırın, 3) Sadece gerçekten bağımsız ölçeklenmesi veya arka planda ağır kaynak tüketmesi gereken bir işlem olursa (örneğin toplu PDF fatura dökümü veya raporlama) onu bağımsız bir arka plan kuyruk servisi olarak ayırın. 70.000 dolarlık bütçenizi orkestrasyon ve altyapı karmaşasına değil, ürünün işlevsel kalitesine harcayın.

Koray C***KatılımcıTopluluk üyesi

Katılım: Eki 2022
Mesaj: 180

8 ay önce#3

Yazılımcınız muhtemelen kendi özgeçmişine popüler mimarileri eklemek istiyor. 1.200 kullanıcı tek bir optimize edilmiş sunucuda standart bir ilişkisel veri tabanıyla rahatça çalışır. Üç kişinin mikroservis yönetmeye çalışması teslim sürenizi en az iki katına çıkarır.

Tülay A***Katılımcı

Görev: Mağaza görevlisi
Sektör: Ambalaj
Yapı: 8 kişilik ekip
Katılım: Ara 2023
Mesaj: 64

8 ay önce#4

Geçen yıl 4 kişilik ekiple benzer bir hatayı yaptık. Beş mikroservise böldüğümüz sistemde ilk 6 ay servisler arası iletişim hatalarını çözmekle geçti. Bulut altyapı faturalarımız ayda 400 dolardan 2.300 dolara fırladı. Sonunda sistemi tekrar modüler tek parça yapıya döndürdük ve geliştirme hızımız üçe katlandı.

SelinKatılımcı

Görev: Frontend geliştirici
Yapı: 20 kişilik firma
Katılım: Şub 2024
Mesaj: 164

8 ay önce#5

Mikroservise geçtiğinizde sadece kod yazmazsınız. Servis keşfi, mesaj kuyrukları, dağıtık loglama ve dağıtık işlem yönetimi inşa etmeniz gerekir. Veri tabanını da böleceğiniz için basit bir SQL birleştirme işlemi bile servisler arası API çağrılarına dönüşür. Ekipte tam zamanlı altyapı uzmanı yoksa sistem hızlanmaz, aksine yavaşlar.

Ferhat K***Katılımcı

Görev: Yazılım takım lideri
Sektör: Makine imalatı
Yapı: holding bünyesinde bir şirket
Katılım: Oca 2023
Mesaj: 377

8 ay önce#6

Yenileme yaparken şu üç adımı uygulayın: 1) Mevcut veri tabanı şemasını temizleyip doğrudan iş mantığına bağlayın, 2) Kod tabanını mikroservis disipliniyle klasörleyin ama tek bir projede tutun (modüler monolit), 3) Kapsamlı birim ve entegrasyon testleri yazarak canlıya geçiş riskini sıfırlayın.

Ufuk S***Veteran

Görev: Ağ yöneticisi
Sektör: Mobilya üretimi
Yapı: imalathane
Katılım: Eki 2024
Mesaj: 187

8 ay önce#7

biz de ayni hevesle girdik iki yil once ama bir servisin cokmesi zincirleme digerlerini goturuyordu loglari takip etmek tam bir eziyete donustu. acikcasi kucuk ekiple monolit candir maaceraya hic gerek yok.

Vildan U***KatılımcıTopluluk üyesi

Katılım: Ara 2025
Mesaj: 32

8 ay önce#8

peki monolit sistem kurarsak ileride kullanıcı sayısı 10 bine veya 50 bine çıktığında sistemi tamamen çöpe mi atmak zorunda kalırız? büyümenin önünü tıkamış olmuyor muyuz?

Pınar K***Yeni üyeTopluluk üyesi

Katılım: Ağu 2026
Mesaj: 410

8 ay önce#9

50 bin kullanıcı bile iyi optimize edilmiş tek bir sunucuda rahatça çalışabilir. Milyonlarca işlem yürüten devasa küresel SaaS platformları hâlâ modüler monolit mimarilerle hizmet veriyor. İleride gerekirse sadece tıkanan modülü servise çevirirsiniz şimdiden dağıtık sistem kurmanın hiç bir faydası yok.

Ömer E***KatılımcıTopluluk üyesi

Katılım: Ağu 2023
Mesaj: 71

8 ay önce#10

Mevcut bütçeniz ve insan kaynağınız göz önüne alındığında, risk yönetimi açısından en makul yaklaşım modüler monolit mimarisidir. Altyapı karmaşıklığı yerine ürün fonksiyonlarına odaklanmanız yatırım getirinizi doğrudan artıracaktır.