American Express’in genel müdür yardımcısı ve küresel altyapı başkanı Matthew Liste, başarılı bir teknik platformun bileşenlerinin sayısıyla değil, karmaşıklığı gizleme ve geliştiricilere istikrarlı, anlaşılır bir deneyim sunma becerisiyle ölçüldüğünü düşünüyor. Liste, QCon San Francisco’daki sunumunu Goldman Sachs, JPMorgan Chase ve American Express’te kritik sistemler için platformlar ve altyapılar oluştururken geçirdiği 20 yılı aşkın deneyime dayandırdı.
Liste’nin sözünü ettiği platformlar çok sayıda iç geliştiriciye hizmet veriyor; American Express’te yaklaşık 20 bin, JPMorgan Chase’te ise yaklaşık 60 bin kullanıcı bulunuyor. Bulut hizmeti sağlayıcılarına kıyasla ölçek farklı olsa da Liste, başkalarının dayandığı bir katman oluşturan her ekip için temel ilkelerin aynı olduğunu düşünüyor.
İyi platform, neler olduğunu gizlemeden karmaşıklığı gizler
Liste, platformu, uygulamaların üzerinde oluşturulması için temel teşkil eden bütünleşik teknolojiler kümesi olarak tanımlıyor. Platformu su ve kanalizasyon hizmetlerine benzetiyor: Kullanıcı, çalıştığı sürece arkasındaki altyapıyı düşünmüyor; ancak sistem bozulduğunda bunu hemen fark ediyor.
Bu nedenle platform deneyimi sezgisel olmalı ve izleme, kimlik ile ad alanları için ortak temeller gibi ortak ve birbiriyle değiştirilebilir bileşenler kullanmalı. Bu birleştirilebilirlik, platformu ek çaba olmadan birlikte çalışmayan ayrı hizmetler kümesi yerine Lego parçalarına daha çok yaklaştırıyor.
İstikrar, güvenlik ve ölçeklenebilirlik isteğe bağlı özellikler değildir
Liste, «üç sütun» olarak adlandırdığı istikrar, güvenlik ve ölçeklenebilirliği belirliyor. Gerekli kullanılabilirlik düzeyi sistemin değerine göre değişiyor; sunumuna göre American Express’te kredi kartı provizyon sistemleri, altı ve dokuz seviyelerine varan kullanılabilirlik düzeylerinde çalışırken diğer sistemler daha fazla kesintiyi tolere edebiliyor.
Başlangıçtaki başarının ölçeklenme sorunlarını gizleyebileceğini de vurguluyor. İlk aşamada iyi çalışan bir platform, kullanımı arttığında darboğazlarla karşılaşabilir ve bu da doğrudan istikrarı etkiler. Bu nedenle hizmet seviyesi hedefleri (SLO’lar) tüketicilerle birlikte belirlenmeli ve yalnızca lansman gününde değil, zaman içinde de bunlara uyulmalı.
Sürekli güncelleme ve farklılaştırmayan işlerin azaltılması
Liste, platformu güncel tutmayı en zor ve ertelenmeye en açık görevlerden biri olarak görüyor. Ertelenen yükseltmelerin birikmesi, daha yeni bir sürüme geçişi maliyetli hâle getirebilir ve müşterileri etkileyebilir. Otomasyon sayesinde rutin bakım için sıfır kişi, filonun tüm bileşenlerini yükseltebilme, yükseltmeyi bir günden kısa sürede tamamlama ve 14 günde bir ya da daha kısa aralıklarla güncelleme döngüsü yürütme ölçütlerini içeren, 0114 adını verdiği bir iç standart öneriyor.
Ayrıca yeterli kalitede mevcut olan bir şeyi yeniden oluşturmamaya çağırıyor. Yeni bir PostgreSQL motoru yazmak yerine, düzenleyici gereklilikleri karşılamak için günlük yedeklemeleri nesne depolama alanına gerçekleştiren bir kontrol katmanı oluşturmayı örnek veriyor. Buradaki fikir, mühendislik açısından en ilgi çekici göreve değil, kurumun ihtiyaç duyduğu değere odaklanmak.
Net kararlar ve tüketicilerle sözleşmeye dayalı ilişki
Platform sahipleri müşterileri dinlemeli, ancak her talebi uygulamamalı. Kaynaklar sınırlı ve eski özellikleri kullanımdan kaldırmadan tutmak teknik borcu biriktirerek daha önemli olanın geliştirilmesini engelliyor. Bu nedenle platformun net bir «tavrı» olmalı: Neyi destekleyeceğini, neleri desteklemeyi bırakacağını ve kullanıcıların çoğuna neyin hizmet ettiğini belirlemeli.
Buna, API’ler, hizmet seviyesi anlaşmaları ve süreçler aracılığıyla sorumluluklara resmî sınırlar koymak da dâhil. Ekibin ne sunduğunu bilmesi yeterli değil; tüketicinin de hangi sorumluluğun kendisine ait olduğunu ve platformun aşmayacağı sınırları bilmesi gerekiyor. Liste, platformları sabit şekillere sahip bileşenlere benzetiyor: Sınırlı bir ekip her müşteri için özel bir ürün oluşturamaz.
Pratik deneyim: Erken deneyin ve ayrıntıları gizlemeden soyutlama kullanın
Liste, oluşturma kararı alındıktan sonra müşterileri geçiş sırasında koruyarak hızlı ve tekrarlı başarısızlıklar yaşanmasını öneriyor. Linux konteynerleri ve farklı orkestrasyon araçlarıyla yapılan, sonunda Kubernetes’e geçişle sonuçlanan erken deneyimleri örnek gösteriyor; erken deneyim, ekibin tek bir çözümün olgunlaşmasını beklemeden öğrenmesini sağladı.
Buna karşılık soyutlama katmanları altında neler olduğunu gizlememeli. Terraform gibi bir kullanıcı arayüzü, API’ler ve Infrastructure as Code sağlanabilir; ancak arızaları anlamak ve gerektiğinde davranışı değiştirmek için yeterli görünürlük ve ayrıntı sunulmalı. Liste, platform ekibinin her katmanı sıfırdan yeniden oluşturmak yerine entegrasyona ve katma değere odaklanabilmesi için açık kaynaklar ve açık standartlar üzerine inşa edilmesi gerektiğini vurgulayarak sözlerini tamamlıyor.
Bu ilkeler neden önemli?
Liste’nin yaklaşımındaki temel değer, platform oluşturmayı bir araç seti başlatma projesi olmaktan çıkarıp uzun vadeli bir operasyonel taahhüt hâline getirmesi. Platform, benimsendikten sonra birçok ekibi etkiliyor; bu nedenle güncellenebilirlik, sorumlulukların netliği ve kullanımdan kaldırma yönetimi, hızlıca yeni bir özellik eklemekten daha önemli hâle geliyor. Bu ilkeler başarıyı garanti eden ortak bir standart değil, pratik deneyime dayalı rehberler olarak kalıyor; kullanılabilirlik düzeyi, otomasyonun kapsamı ve soyutlama tercihleri sistemin niteliğiyle kullanıcılarının ihtiyaçlarına bağlı olmaya devam ediyor.