Cloud exit stratejisi: kazara lock-in’i zamanında fark etmek

Kurumların cloud exit stratejisi çoğu zaman ancak sağlayıcıdan ayrılma ihtiyacı doğduğunda gündeme geliyor ve o noktada bağımlılıklar production sistemlerine gömülmüş oluyor. Yazı, cloud exit architecture’ı buluttan vazgeçme planı olarak görmüyor. Onu, fiyat, regülasyon ya da kesinti gibi değişikliklerde sistemleri taşınabilir tutan bir tasarım disiplini olarak tanımlıyor.

Cloud exit stratejisi nedir, ne işe yarar?

Cloud exit stratejisi, bir kurumun iş yüklerini ve verisini bulut sağlayıcısından başka bir sağlayıcıya ya da kendi altyapısına makul maliyetle taşıyabilmesi için yaptığı plandır. Regülasyon, fiyat değişikliği ya da tek sağlayıcıya yoğunlaşma riskine karşı hazırlanır. Genellikle identity, veri taşınabilirliği, network tasarımı ve IaC bağımlılıklarını kapsar. Multi-cloud ve hybrid cloud yaklaşımlarıyla birlikte anılır.

Cloud exit stratejisi bir göç planı değil

Yazının ana tezi şu: sağlayıcıdan çıkmak teknik olarak mümkün, pratikte çoğu zaman değil. Çünkü bağımlılık tek bir serviste durmuyor. Identity, veri, network, IaC (Infrastructure as Code) ve deployment pipeline’ları aynı control plane’e bağlanıyor.

Bu bir olay ya da sürüm haberi değil, bir mimari yaklaşım. Yine de platform ekipleri için somut bir iş listesi çıkıyor. Sağlayıcı fiyat değiştirdiğinde ya da bir region erişilemez olduğunda elinizde seçenek olmalı. O seçenek iki yıllık bir yeniden yazım istiyorsa seçenek sayılmaz.

Yazıdaki en işe yarar kavram “understood portability”. Her şeyi taşınabilir yapmaya çalışmak yerine neyin kolay, neyin zor taşındığını bilmek. Lowest-common-denominator bir platform kurmak yazara göre her yerde kötü sistem üretiyor. İyi bir cloud exit stratejisi tam bağımsızlık hedeflemez, bağımlılığın haritasını çıkarır.

İlk envanter: identity ve veri

Identity genelde en son düşünülen konu. Yazının önerisi dört katmanı birbirinden ayırmak:

• İnsan kullanıcı identity’si
• Workload identity
• Servisler arası identity
• Authorization policy

Kendi ortamınız için tek bir soru yeterli bir başlangıç: Service account, cloud role ve uygulama içindeki yetki kararı aynı yerde mi tanımlı? Policy’yi sağlayıcı konsolunu açmadan okuyamıyorsanız çıkış maliyetinin büyük kısmı burada. Federation tarafında SAML, OAuth ya da OpenID Connect gibi standartlara dayanmak, kurumsal identity’yi tek bir cloud hesabına gömmemenin yolu.

Veride asıl tuzak format. Managed veritabanı kullanmak sorun değil. Sorun, veriyi dışarı alma, doğrulama ve başka yerde ayağa kaldırma adımlarının hiç düşünülmemiş olması. Servis seçmeden önce şu soruları karar kaydına yazın:

• Veri standart bir formatta export edilebiliyor mu?
• Şema platform dışında belgelenmiş mi?
• Şifreleme anahtarları taşımaya izin verecek şekilde kimin kontrolünde?
• Taşıma ne kadar sürer, doğruluk nasıl kanıtlanır?

Network ve egress maliyeti

Yazının en pratik uyarısı şu: teknik olarak taşınabilir ama finansal olarak taşınamayan bir sistem taşınabilir sayılmaz. Egress ücretini mimari çizime eklemediğiniz sürece çıkış planı eksik kalır. Hangi veri akışının pahalı olduğunu, hangi bağımlılığın latency’ye duyarlı olduğunu ve hangi iş yüklerinin birlikte taşınması gerektiğini bir tabloya dökün.

Hard-coded endpoint’ler en sinsi bağımlılık. Config ve IaC repository’lerinde sabit yazılmış IP adreslerini kabaca bulmak için bir grep iş görür:

grep -rnE '([0-9]{1,3}\.){3}[0-9]{1,3}' .

Çıktıda sürüm numarası gibi false positive (yanlış pozitif) eşleşmeler de olacak. Ama kalan her adres, DNS üzerinden çözülmesi gereken bir bağımlılığa işaret ediyor. Adres planını ve private bağlantıları alternatif bir ortamı düşünerek belgelemek bu listeyi küçültür.

IaC’de intent ile implementation ayrımı

Yazarın iddiası sert: IaC birçok kurumda lock-in’i çalıştırılabilir hale getirdi. Kod olması taşınabilir olduğu anlamına gelmiyor. Provider’a özgü modüller, isimlendirme kalıpları ve policy’ler şablonu tek ortama kilitliyor.

Önerilen yol, gereksinimi uygulamadan ayırmak. Önce yeteneği tanımlayın: compute profili, network’e açılma biçimi, storage dayanıklılığı, identity modeli, observability (gözlemlenebilirlik) gereksinimi ve recovery hedefleri. Sağlayıcıya özgü kod bu tanımın altında bir eşleme katmanı olarak dursun. Başka bir sağlayıcıya geçerken yeniden yazacağınız şey mimari olmaz, yalnızca bu katman olur.

Bilinçli lock-in için karar kaydı

Yazının özü tek cümlede: lock-in her zaman kötü değil, kazara lock-in kötü. Bir native servis operasyon maliyetini düşürüyor ya da ürünü pazara hızlı çıkarıyorsa kullanın. Ama her böyle kararın yanına çıkış maliyetini, alternatifini ve kararı onaylayan kişiyi yazın.

Pratik başlangıç basit: production’daki her sistem için bir satır. Sütunlar identity modeli, veri formatı, network bağımlılığı, IaC’nin provider’a bağlılık derecesi ve tahmini çıkış maliyeti olsun. Bu tablo cloud exit stratejisinin yazılı halidir. Çeyrek başlarında güncellerseniz, sağlayıcı fiyat değiştirdiğinde yönetime aylar yerine günler içinde cevap verebilirsiniz.