Her veri isteğini uzak bir merkeze taşımak bazı uygulamalarda gereksiz gecikme yaratır. Uç bilişim yaklaşımı, belirli işlemleri kullanıcıya daha yakın ağ noktalarında yaparak yanıt süresini iyileştirmeyi hedefler. Özellikle gerçek zamanlı içerik ve yoğun trafik alan hizmetlerde bu fikir dikkat çekiyor. Yine de yakın işlem her zaman daha iyi mimari demek değildir; veri tutarlılığı ve güvenlik sınırları dikkatle tasarlanmalıdır.
Hangi iş yakınlaşabilir?
Genel bir görselin biçimlendirilmesi veya erişim isteğinin ön denetimi uygun aday olabilir. Kullanıcıya özgü, hassas ve sürekli değişen hesap bilgisi ise farklı korumalar ister. Aynı verinin çok sayıda noktada tutulması güncel sürümün hangisi olduğunu belirsizleştirebilir. Mühendisler bu yüzden veri türlerini ayırır, hangi işlemin merkezde kalacağını belirler. Mimari, pazarlama terimine göre değil gerçek kullanım senaryosuna göre seçilmelidir.
İlk tıklamanın ardındaki yol
betrupi ve betrupi giriş bağlantıları aynı sayfaya götürse de ağın isteği hangi noktada karşıladığı kullanıcıya görünmez. Bu alan adının uç bilişim kullanıp kullanmadığı bilinmiyor; bağlantılar yalnızca genel bir web yolculuğu örneği. Kullanıcı açısından önemli olan, sayfanın doğru açılması ve oturum işleminin güncel veriyle yapılmasıdır. Hız kazanımı tutarsız hesap durumu yaratıyorsa amaç boşa gider.
Veri yerleşimi ve denetim
İşlemi farklı bölgelerde yürütmek, verinin nerede işlendiği sorusunu da gündeme getirir. Kuruluşlar saklama, silme ve günlükleme politikalarını yeni mimariye göre gözden geçirmeli. Sorun çıktığında hangi ağ noktasının hangi yanıtı verdiğini görebilmek operasyon için gereklidir. Aksi halde hızlı sistem, arızanın nedenini bulmayı zorlaştırır. Performans kararının gizlilik ve bakım maliyetiyle birlikte hesaplanması gerekir.
18 | Yakın işlem her zaman ucuz değil
İşlemleri birden çok noktaya dağıtmak sunucu kaynaklarını ve izleme araçlarını çoğaltabilir. Tek merkezde yapılan yazılım güncellemesi uç düğümlere farklı zamanlarda yayılırsa sürüm tutarsızlığı yaşanabilir. Mühendisler dağıtımı kademeli yapmalı ve hangi kullanıcının hangi sürüme eriştiğini izlemeli. Ayrıca her bölgedeki ağ koşulu aynı değildir; bazı yerlerde merkezi hizmet zaten yeterince hızlı olabilir. Bu nedenle önce gerçek gecikme verisi toplanmalı, sonra mimari değiştirilmelidir. Güvenlik kuralları da tüm noktalar için tutarlı uygulanmalı; bir bölgedeki eksik ayar sistemin genel savunmasını zayıflatabilir. Uç işlem fikri, yalnızca milisaniye kazancı değil yönetim ve uyumluluk maliyeti üzerinden tartılmalı. Teknik başarının ölçüsü sunucu sayısı değil, kullanıcının doğru ve kararlı yanıt almasıdır.
18 | Ölçmeden taşımamak
Yeni altyapıya geçmeden önce hangi işlemlerin gerçekten yavaş olduğu saptanmalı. Kullanıcıya yakın noktada çalışan kod, uzaktaki veritabanına sık sık gitmeye devam ediyorsa beklenen hız kazanımı oluşmayabilir. Taşınan işlemlerin güncellenmesi ve hata kaydının tutulması da yeni operasyon gerektirir. Deneme grubunda gerçek kullanıcı gecikmesi ölçülüp güvenlik ve bakım maliyetiyle karşılaştırılmalıdır. Teknolojik yeniliğin kendisi değil, çözmeye çalıştığı somut problem yatırımın gerekçesi olmalı.
Uç bilişim sihirli hız düğmesi değil, uygulamanın bazı parçalarını farklı yerde çalıştırma tercihidir. İyi sonuç için ölçüm şart: Gerçek kullanıcı ne kadar hız kazandı, hangi işlem karmaşıklaştı, hangi veri yeni risk doğurdu? Teknoloji haberi yeni mimariyi anlatırken bu soruları birlikte sormalı. Kâğıt üzerindeki düşük gecikme, güvenli ve tutarlı deneyimle birleştiğinde değer kazanır.
