Key Takeaways
- Mevcut sistemi tamamen değiştirmeden, kademeli ayrıştırmayla dönüşüm sağlandı.
- CDC tabanlı gerçek zamanlı veri sistemiyle mainframe'e doğrudan erişim ikame edildi.
- REST yerine GraphQL kullanılarak çok sayıdaki BFF katmanı kaldırıldı, esneklik ve bakım kolaylığı sağlandı.
- Alan odaklı ekip yapısıyla (Team Topologies) ekip sorumlulukları ve sahiplik netleştirildi.
- Kademeli dağıtım ve otomasyon sayesinde sistem risksiz biçimde dönüştürülüp istikrarlı şekilde değer sunuldu.
Uygulama örneği: Arıza sırasında bile ayakta kalan sistemin yarısı
Mainframe arızası yaşandı, ancak bulut tabanlı streaming mimarisi sayesinde yeni UI normal çalışmaya devam etti.
Eski sistem devre dışı kalsa bile yeni sistem müşteri deneyimini koruyarak dayanıklılığını kanıtladı.
Temel strateji: Çok katmanlı ayrıştırma (Decoupling)
- Domain-Driven Design (DDD): Mainframe merkezli model, iş odaklı olacak şekilde yeniden kurgulandı
- Team Topologies: Özellik odaklı ekip organizasyonuna geçildi
- Olay tabanlı mimari: Asenkron yaklaşımla sistemler arası bağlılık azaltıldı
- Change Data Capture (CDC): Gerçek zamanlı veri değişimleri algılanarak legacy ile yeni sistem birbirine bağlandı
Önceki yapı: Unified Web Portal 1.0
Çeşitli mainframe verileri ETL ile birleştirilerek SQL DB ve SaaS üzerinden sunuluyordu,
ancak gerçek zamanlılık eksikliği, veri kalitesinde düşüş ve mainframe'e doğrudan çağrı gibi sorunlar ortaya çıktı.
Sorunlar
- ETL kaynaklı veri gecikmesi
- Mainframe ile esnek olmayan senkron bağlantı
- Sayısız BFF API üretilmesi
- Organizasyon yapısından kaynaklanan darboğazlar ve sürüm gecikmeleri
- Trafiğin ani arttığı anlarda mainframe aşırı yüklenmesi nedeniyle tüm hizmetin kesintiye uğraması
Yeni hedeflerin belirlenmesi
Teknik hedefler: mainframe ile web'in ayrıştırılması, BFF'nin kaldırılması, ekip özerkliğinin sağlanması
İş hedefleri: çağrı merkezi taleplerinin azaltılması, lisans maliyetlerinin düşürülmesi, müşteri memnuniyetinin artırılması
Yeni mimarinin özeti
- Mainframe hâlâ system of record
- CDC → Kafka → domain DB (CosmosDB)
- GraphQL + REST API → BFF → UI
- Olay tabanlı yapı ve message broker ile tüm bileşenlerin bağlanması
Adım 1: Change Data Capture
- Gerçek zamanlı veri streaming'i ile system of reference kuruldu
- Mainframe → Kafka → dönüşüm → domain DB → API olarak sunum
- Mainframe şemasına bağımlı olmayan esnek veri yapısı elde edildi
Adım 2: Domain-Driven Design + GraphQL
- DDD ile domain modeli tanımlandı (Entity, Command, Event)
- Her domain bir GraphQL düğümü olarak yapılandırıldı, schema stitching ile supergraph oluşturuldu
- Yalnızca gerekli veriyi sorgulayan optimize sorgu yapısı desteklendi
Organizasyon yapısındaki değişim: Team Topologies
- Özellik odaklı stream-aligned ekipler olarak yeniden organize edildi
- Karmaşık alanlar (ör. mainframe entegrasyonu) özel ekipler tarafından yönetildi
- Teknik destek için Enablement ekibi işletildi
Olay tabanlı genişleme: iç domain event'leri + saga pattern
- Outbox pattern ile domain değişikliklerinde event üretildi
- Parallel Saga ile mainframe işleri ve CDC senkronize edildi
- State machine tabanlı workflow kurularak karmaşık akışlara da yanıt verildi
Zorluklar
- Olay tabanlı yapının benimsenmesi için organizasyon içinde bakış açısı değişimi gerekliydi
- Asenkron yapı nedeniyle gözlemlenebilirliğin sağlanması kritik hâle geldi
- Mainframe batch işleri → CDC pipeline üzerinde aşırı yük oluşturdu
- GraphQL schema yönetiminin karmaşıklığı ve federated approach kullanımına dair değerlendirmeler
- Kimlik doğrulama/loglama gibi ortak ihtiyaçlar ayrı paketler ve otomasyonla yönetildi
Sürüm stratejisi: release train + Feature Flag
- Her ekip bağımsız dağıtım yaptı, dağıtım repository'sinde entegrasyon sağlandı
- Kustomize ile ortama göre dağıtım pipeline'ları kuruldu
- Feature flag ile özellik/güvenlik sürümleri ayrıştırıldı, trunk-based geliştirme sürdürüldü
Hibrit mimari uygulaması
- UWP 1.0 ve UWP 2.0 birlikte çalıştırılarak kademeli geçiş gerçekleştirildi
- Edge routing ile kullanıcı istekleri adım adım yeni sisteme yönlendirildi
Sonuç: Evrilebilir bir platform inşası
- Frontend ile mainframe tamamen ayrıştırıldı
- Ekip merkezli yapı sayesinde hız ve istikrar sağlandı
- Müşteri memnuniyeti ve operasyon maliyetlerinde iyileşme elde edildi
- Gelecekte mainframe'in değiştirilmesini de mümkün kılan esnek bir temel kuruldu
1 yorum
Aşamalı iyileştirme ve aşamalı mikroservis çıkarımı gerçekten çok önemli... böyle yazıları görünce, ilgili projeyi yöneten PM'in ne kadar önemli ve ne kadar büyük iş başardığını gerçekten hissediyorum. Bunca şeyi yönetmek gerçekten vay be.