Bir isteğin geçtiği yol
Bir destek eylemciı düşünün: bir belgeyi buluyor, yanıtı hazırlıyor, ardından kullandığı araçları ve sonucu geriye yazıyor. DigitalOcean’ın özel önizlemeye açtığı Agent Data Services, bu yolun iki ucunu aynı katalogda topluyor. Belgeler, ses ve video gibi girdiler Data Flows ile işlenip vektör dizinine giriyor; eylemci oturumları da sorgulanabilir veriye dönüşüyor. Geliştiriciye sunulan değişiklik, ayrı kaynakların arasında kendi bağlantı kodunu taşımak yerine bu yolu yönetilen veri katmanında kurma seçeneği.[1]
Bu tasarımda ham verinin gelişi, işlenmesi ve sorgulanması aynı hizmetin işi. Yapılandırılmış veri ile vektörler birlikte tutuluyor; kaynak kökeni bilgisi korunuyor. SQL ve API üzerinden erişim, mevcut uygulamanın bağlam isteme noktasını tanımlıyor. Benim için mimarinin ilginç yanı burada: model seçimi sabit kalsa bile, geliştiricinin bakım yaptığı sınır veri alma ve güncelleme akışına kayıyor. Bu kayma bütün bağlantı işinin bittiği anlamına gelmiyor; hangi akışın nasıl kurulacağı hâlâ uygulama kararı.[1]
Aynı katalogdan geri dönüş
İkinci yol, eylemciın kendi işinden geliyor. Araç çağrıları, ara sonuçlar ve oturum geçmişi aynı katmana geri yazılıyor. DigitalOcean bu veriyi Insights ve Learning Services araçlarına bağlıyor. Böylece yanıt için okunan bağlam ile davranışı değerlendirmek için gereken izler aynı veri düzeninde buluşuyor. Ürünün asıl bütünleştirme önerisi bu: arama deposuyla değerlendirme deposu arasındaki eşleme işini küçültmek. Bunun geliştirici saatini azaltması, mevcut akışın ne kadar parçalı olduğuna bağlı; zaten ortak şeması olan ekip için kazanç daha sınırlı olabilir.[1]
Bu rahatlığın karşılığında veri akışının kuralları önemli bir bağımlılığa dönüşüyor. Servis üçüncü taraf depolarını bağlayabiliyor ve bağımsız çalışma alanı olarak kullanılabiliyor; buna rağmen girdiyi hangi adımlarla zenginleştirdiğinizi, oturum izini hangi yapıda sakladığınızı uygulamada bilmek gerekiyor. Çalışma alanı yetkileri, takım rolleri ve erişim günlükleri de bu sınırın parçası. Ben olsam prototipin yanına veri akışı tanımını ve çıktı şemasını koyarım: başka bir sisteme geçişin hesabı, yalnızca SQL sorgusunu yeniden yazmakla bitmiyor.[1]
Küçük bir akışla karar vermek
Başlangıç için tek belge kaynağı, tek sorgu yolu ve tek oturum sonucu yeterli bir deneme alanı. Aynı örneği mevcut veri hattında ve yönetilen katalogda çalıştırıp bir belge değiştiğinde gereken bakım adımlarını karşılaştırmak anlamlı. İzlerin sonuca bağlanması, izinlerin uygulanması ve hangi işin hâlâ uygulamada kaldığı birlikte görülebilir. Bu küçük geliştirme denemesi, satın alma kararını bakım adımları üzerinden somutlaştırır.[1]
Özel önizlemenin koşulları da denemenin boyutunu belirliyor: hizmet düzeyi anlaşması ve destek taahhüdü yok, standart uyumluluk sertifikaları bu hizmeti kapsamıyor. Bu yüzden ilk küçük akışta bağlamın nereden geldiğini ve sonucun nereye yazıldığını görünür tutmak değerli. Yönetilen katman ancak bu iki uç arasındaki bakım işini gerçekten azaltıyorsa geliştiriciye alan açıyor. eylemciın bir yanıt üretmesi kolay görünen kısım; o yanıtı besleyen hattın değişiklik karşısında ne kadar iş çıkardığı, burada satın alma ile kendi kurma arasındaki gerçek soru.[1]