En iyi mimari bile­şen­leri kaldırır

İyi mimari denince akla genellikle inşa edilmiş bir şey gelir: daha fazla yapı taşı, daha fazla yapı, daha fazla önlem. Bu hikâye bunun tersini anlatıyor: değeri “daha az”da yatan bir mimariyi. Bilinçli olarak genel tutuldu: sistem yok, paydaş yok, tarih yok.

Durum

Bir sistem ile konuştuğu servisler arasında, araya yerleştirilmiş yüzlerce API sunucusu duruyordu; her bağlantı, her amaç için ayrı bir sunucu. Her biri tek başına pek dikkat çekici bir şey yapmıyordu; ama birlikte, işletilmesi, izlenmesi ve ayakta tutulması gereken geniş ve zor kavranan bir yapı oluşturuyorlardı.

Başlangıç varsayımları

Bu yapı tek bir kararla değil, her biri kendi içinde makul görünen pek çok küçük kararla oluşmuştu: Her yeni ihtiyaç için araya bir sunucu daha, çünkü o an en kolay yol buydu. Sessiz varsayım, her amacın kendi altyapı parçasını hak ettiği, yani daha fazla bağlantının daha fazla sunucu anlamına geldiğiydi.

Sorun

Bileşen sayısıyla birlikte artan şey yetenek değil, onları işletmenin yüküydü. Yüzlerce benzer sunucu, bir şeyin arızalanabileceği, eskiyebileceği, izlenmesi ve güncellenmesi gereken yüzlerce yer demektir. Altyapı, yalın bir altyapıdan pek fazla yetenek taşımıyordu; ama kat kat fazla emek ve saldırı yüzeyi taşıyordu. Karmaşıklık sistemin yapabildiklerinde değil, neyden oluştuğundaydı.

Neden

Neden, birbirine benzeyen çok sayıda ara parçanın, bir kez ele alınabilecek ama hiç ele alınmamış bir örüntü hâlinde tekrarlanmasıydı. Yüzlerce sunucunun tek tek yaptığı iş, özünde aynı görevdi: istekleri almak, iletmek, dönüştürmek. Bu benzerlik asıl yapıydı; ortadaydı, ama kimse onu tek bir şey olarak değil, yüzlerce ayrı şey olarak ele almıştı.

Karar

Karar, birbirine benzeyen çok sayıda bileşeni, ortak görevlerini tek bir yerde yerine getiren tek bir bileşenle değiştirmekti: bir proxy mimarisi. Bir şey eklemek değil, tekrar edeni birleştirmek ve geri kalanı kaldırmak. İlerleme, sonunda ortada daha az şey kalmasıydı.

Uygulama

Çok sayıdaki ara parçanın ortak görevi ayıklandı ve tek bir yerde ifade edildi: daha önce yüzlerce sunucuya dağılmış olan işi üstlenen bir proxy. Tek tek sunucular adım adım devreden çıkarılıp kaldırıldı; her biri ancak proxy'nin onun görevini kanıtlanmış şekilde üstlenmesinden sonra. Sonunda belirgin biçimde daha basit bir altyapı ortaya çıktı: daha az bileşen, daha az arıza noktası, akılda tutulması gereken daha az şey.

Avantajlar ve sınırlamalar

Birleştirmenin bir bedeli var: Tek proxy önemli hâle gelir. Daha önce dağıtık olanı artık o taşır ve buna uygun şekilde sağlam ve gözlemlenebilir olmalıdır. Çok sayıda küçük arıza noktası, tek bir önemli arıza noktasıyla takas edilir. Bu tek nokta özenle inşa edildiği sürece bu iyi bir takastır; öyle olmasaydı kötü bir takas olurdu. Ara parçalar gerçekten birbirinden farklı olsaydı farklı karar verirdik; o durumda birbirine benzemeyen şeyleri birleştirip var olmayan bir birliği dayatmış olursunuz.

Ne öğrendik

En iyi mimari çoğu zaman yeni bileşen eklemek yerine bileşenleri kaldırır. Yetenek ile sayı aynı şey değildir: Birbirine benzeyen çok sayıda parçadan oluşan bir sistem, aynı görevi tek bir yerde çözen bir sistemden daha güçlü değildir; yalnızca işletmesi daha pahalıdır. Bir şeyin çok kez tekrarlandığı yerde neredeyse her zaman bir kez ele alınabilecek bir yapı yatar. Cazip soru, hangi bileşenin ekleneceğidir; daha değerli soru ise hangi tekrarın ortadan kaldırılacağıdır.

Bu deneyim Batunet'i nasıl değiştirdi

O zamandan beri artan sayıda benzer bileşeni olağan bir durum olarak değil, bir sinyal olarak görüyoruz: henüz ele alınmamış bir yapının işareti olarak. Altyapıda bir şey eklemeden önce, ilk olarak neyin birleştirilip kaldırılabileceğini soruyoruz. Bizde hedef, en zengin mimari değil, görevi taşıyan en basit mimaridir.

İleri okuma

• Hikâye: Karmaşıklığı eklemek yerine kaldırmak: Aynı ders, altyapı yerine bir uygulamanın mimarisine uygulanmış hâliyle.
• Rehber: Modüler monolit mi, mikroservisler mi: Daha fazla bileşenin neden daha fazla yetenek anlamına gelmediği.
• Rehber: Uzun ömürlü sistemler için API tasarımı: Ortak bir görevi tek bir yerde temiz biçimde ifade etmek.
• Rehber: On yıl sonra hâlâ çalışan yazılım: Daha az parçanın bir sistemi neden daha uzun ömürlü kıldığı.

Temelinde Batunet Engineering Method yatar: tekrarı bir yapı olarak tanımak, çoğaltmak yerine birleştirmek, taşıyabilen en basit mimariyi seçmek.

Daha fazla bileşen, daha fazla mimari demek değildir. Çoğu zaman en iyi tasarım, sonunda ortada daha az şey bırakan ve bu azın bütünü taşıdığı tasarımdır.