Mikroservis mimarimiz organizasyon şemamızı birebir yansıtıyordu. Bu, Conway Yasası'nın iş başındaki hali.

Kurulum:

  • A Ekibi (5 kişi) → User Service
  • B Ekibi (5 kişi) → Order Service
  • C Ekibi (5 kişi) → Payment Service
  • Ekipler API sözleşmeleri üzerinden iletişim kuruyor

Reorganizasyonda ne oldu:

  • A ve B ekipleri birleşti
  • Yeni ekip User + Order servislerinin sahibi
  • Ama User ve Order sıkı API sözleşmeleriyle bağlı
  • Artık aynı ekip HTTP üzerinden koordine oluyor
  • Sıfır fayda karşılığında ek yük

Tersi problem:

  • C Ekibi Payment + Fraud ekiplerine bölündü
  • Ama Payment servisi ikisini de yönetiyor
  • İki ekip, tek kod tabanı
  • Sürekli merge conflict
  • Bağımsız deploy yok

Çıkarılan ders:

  • Sistem tasarımı ekip sınırlarını izler
  • Reorganizasyonlar mimari değişiklik gerektirir
  • Ya da mimari, reorganizasyonları kısıtlar
  • İkisi de bedava değil

Ders: Mimarinizi tasarlamadan önce ekiplerinizi tasarlayın. Yoksa ileride sancılı bir yeniden hizalama bekleyin — ikisini hizada tutmak, bir DevOps mühendisliği işi olduğu kadar organizasyonel bir egzersizdir.

← Çıkarılan Dersler'e dön

Bu tür olaylar önlenebilir. AWS Yönetilen Hizmetler ekibimiz müşteri ortamlarını yapay zekâ destekli izleme ve nöbetteki kıdemli mühendislerle 7/24 gözetir — böylece bu tür hikâyeler arşivde kalır.

Etiketler: #Mikroservisler #Organizasyon #Conway #Mimari