Mikroservislere Netflix yaptığı için geçtik. Lansmanda günlük yaklaşık 50 aktif kullanıcısı olan bir CRUD ürünü geliştiren dört geliştiriciydik. Netflix değildik.

Onları gerçekte neden seçtik

Listemizdeki her neden mimari değil sosyal bir nedendi: “modern yol bu”, konferans konuşmaları bunu kaçınılmaz gösteriyordu ve CV'lerimizde iyi duruyordu. Kararı belirlemesi gereken sorular — sistemin parçalarının bağımsız ölçekleme ihtiyacı var mı, bağımsız yayın yapması gereken birden fazla ekibimiz var mı, domain katı sınırları haklı çıkaracak kadar karmaşık mı — hiç sorulmadı. Dürüst cevaplar hayır, hayır ve hayır olurdu: günde 200 sipariş, tek ekip, basit CRUD.

Ne kurduk

  • Sekiz servis: API gateway, auth, user, product, order, notification, analytics, admin
  • Bunları birbirine bağlamak için Kafka, Redis ve Elasticsearch, artı PostgreSQL
  • Her deployable için bir tane olmak üzere on iki CI/CD pipeline'ı
  • Altyapı faturası: aylık yaklaşık $3.000

PostgreSQL üzerinde sıkıcı bir Django ya da Rails monoliti — aylık $20'lık bir droplet'te — bu iş yükünü fark etmeden kaldırır ve altı ay yerine iki haftada yayına çıkardı. Bunun yerine fonksiyon çağrısının yeteceği yerde ağ çağrılarımız ve hakkında tam olarak akıl yürütemediğimiz dağıtık transaction'larımız vardı.

Ekip matematiği

Dört geliştirici ve on iki deployable, her kişinin üç servise “sahip” olması ve her servisin bus factor'ünün bir olması demek. Auth'un sahibi olan geliştirici tatile gittiğinde bir auth hatası iki gün bekledi, çünkü kodu başka kimse bilmiyordu. Her şey için nöbet tutmak, kalıcı olarak nöbette olmak demekti. Tek bir özellik rutin olarak üç servise dokunuyor ve koordineli deploy'lar gerektiriyordu; böylece “servisime bakabilir misin?” günlük bir ritüel oldu ve bağlam değiştirme hiç durmadı.

Yerleşik bir servis-başına-kişi kuralı yok ve biz de uydurmayacağız. Sektörün gerçek rehberliği bilişsel yük üzerinedir: tek bir ekip, gerçekten anlayabileceği, işletebileceği ve nöbetini tutabileceği kadar küçük bir servis kümesine sahip olmalıdır. Bu ölçüte göre dört kişilik bir ekip bir sisteme sahip olur — belki iki — on iki değil.

Ne yapmalıydık

Zorunlu modül sınırları olan iyi yapılandırılmış bir monolitle başlamak ve bir servisi ancak belirli, ölçülmüş bir baskı gerektirdiğinde ayırmak — farklı ölçeklenen bir bileşen ya da bağımsız deploy etmesi gereken bir ekip. Mikroservis mimarisinin gerçekten ne zaman karşılığını verdiğine dair rehberimiz bu tetikleyicileri ele alıyor; böyle bir yapıyı yeniden küçültmek ise kendi başına hassas bir proje — hafta sonu refactor'u değil, birinci sınıf bir DevOps projesi olarak ele aldığımız bir iş.

Ders: Mikroservisler teknik bir yükseltme değil, organizasyonel bir ölçekleme stratejisidir. Çok sayıda ekip arasındaki koordinasyon sorunlarını çözerler; o sorunlarınız yoksa yenilerini üretirler. Tüm ekibiniz tek bir toplantı odasına sığıyorsa neredeyse kesinlikle onlara ihtiyacınız yok.

← Çı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 #Mimari #EkipBüyüklüğü #Antipattern