Arayüzler, imp­le­men­tas­yon­lar­dan uzun yaşar

Bir sistemin dışarıya gösterdiği yüz, içeride çalışan şeyden daha uzun kalır. Bu hikâye, bu farkın birden önem kazandığı bir anı anlatıyor. Bilinçli olarak genel tutuldu — sağlayıcı, müşteri ve zaman bilgisi olmadan.

Durum

Bir sistemin üzerine kurulduğu harici bir API sağlayıcısı değiştirildi. Zamanla, eski sağlayıcının yapısını izleyen milyonlarca kayıt birikmişti. Yeni sağlayıcı aynı yeteneği sunuyordu, ancak eskisiyle uyumlu olmayan farklı bir yapıda. Amaç, mevcut veriyi kaybetmeden birini diğeriyle değiştirmekti.

Başlangıç varsayımları

İlk akla gelen bakış, sağlayıcı değişiminin esasen bir bağlantı meselesi olduğuydu: Kaynağı değiştirir, eskisi yerine yenisini çağırırsınız. Emeğin geçişin kendisinde olduğu düşünülüyordu. Asıl ağırlığı hâlihazırda kaydedilmiş milyonlarca kaydın taşıdığı ancak yapıların uyumsuzluğu görünür hâle geldiğinde ön plana çıktı.

Sorun

Yeni yapı eskisine oturmuyordu. Mevcut her alanın, her anlamın yeni modeldeki karşılığına eşlenmesi gerekiyordu — temiz bir karşılığın olmadığı yerlerde ise bir karar verilmesi. Milyonlarca kayıtta böyle bir eşleme tek seferlik bir el hareketi değil, eksiksizliğini ve doğruluğunu kanıtlamanız gereken bir süreçtir. Sorun geçişin kendisi değil, büyük bir veri birikimini bir dilden diğerine kayıpsız çevirmekti.

Neden

Daha derindeki neden, kolayca yapılan bir karıştırmadaydı: arayüzü, arkasındaki sağlayıcıyla bir tutmak. Sağlayıcı implementasyondur — değiştirilebilir, geçicidir. Arayüz ve onun içinden akıp kalıcı hâle gelen veriler ise kalıcı olandır. Veriye kendi bakışını bir sağlayıcının tesadüfi biçiminden ayırmamış bir sistem, bu değişimi mevcut verisinin derinliklerine kadar hissetti.

Karar

Karar, verileri sağlayıcıdan bağımsız, sisteme ait bir biçime getirmek ve yeni sağlayıcıyı bunun arkasına bağlamaktı — arayüzü kalıcı olan, implementasyonu değiştirilebilir olan olarak ele almak. Mevcut verinin biçimini sağlayıcı değil, sistem belirler.

Uygulama

Eski veriler yeni modele eşlendi — alışkanlıkla alan alan değil, anlam anlam. Taşıma doğrulanabilir adımlarla ilerledi ve her adım doğrulandı: Çevrilen veri kaynağıyla örtüşüyor mu? Bir bölüm ancak doğrulama sağlam çıktığında devralınmış sayıldı. Eşleme, taşıma ve doğrulama birbirinden ayrı, bilinçli üç işti — aceleyle yapılmış bir geçiş değil.

Trade-off'lar

Verileri sağlayıcıdan ayırmak ve büyük bir veri birikimini doğrulayarak çevirmek, doğrudan bir geçişten çok daha pahalıdır. Kaynağı basitçe değiştirmek yerine bir çeviri katmanı kurar ve milyonlarca kaydı doğrularsınız. Bu bedel, bir sonraki sağlayıcı değişiminden bağımsızlığı ve hiçbir şeyin kaybolmadığından emin olmayı satın alır. Farklı davranacağımız tek durum, kaybı katlanılabilir ve yeniden temin edilmesi ucuz olan küçük, kritik olmayan bir veri birikimi olurdu.

Ne öğrendik

Arayüzler, implementasyonlardan uzun yaşar. Bir arayüzün arkasındaki sağlayıcı değiştirilebilir; onun içinden akıp kalıcı hâle gelen veriler değiştirilemez. Veriye bakışını belirli bir sağlayıcının biçimine bağlayan, geçici olanı kalıcı olanın temeli yapar — ve bunun bedelini ilk değişimde öder. Verinin kendine ait, bağımsız biçimi bir lüks değil, başkasının verdiği bir kararın kendi verinizi sarsmasına karşı alınmış bir önlemdir.

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

O zamandan beri kalan arayüz ile giden implementasyon arasında bilinçli olarak ayrım yapıyoruz. Verileri sağlayıcıya değil sisteme ait bir biçime getiriyoruz — ve her harici servisi bir gün değiştirilecek bir şey olarak ele alıyoruz. Böylece bir sağlayıcı değişimi artık bir deprem değil, sağlam duran bir sınırın arkasında planlanmış bir süreç.

Devamı

• Rehber: Uzun ömürlü sistemler için API tasarımı — sözleşme yüzeyinin neden en uzun ömürlü parça olduğu ve içerinin neden serbestçe değiştirilebilmesi gerektiği.
• Rehber: Müşterileri bozmadan API versiyonlama — mevcut kullanımı zedelemeden arayüzleri geliştirmek.
• Rehber: Kesintisiz veritabanı migrasyonları — büyük veri birikimlerini doğrulanmış ve geri alınabilir biçimde taşımak.
• Rehber: On yıl sonra hâlâ çalışan yazılım — kalıcı olanla geçici olanın neden ayrılması gerektiği.

Temel, Batunet Engineering Method'dur: kalıcı olanı değiştirilebilir olandan ayırmak, doğrulanabilir adımlarla taşımak, eksiksizliği kanıtlamak.

Bir sağlayıcı ödünç alınmıştır; onun içinden akan veriler kalır. İkisini karıştıran, kalıcı olanını geçici bir şeyin üzerine kurar.