Veriler genellikle çözümün en değerli parçası olarak kabul edilir çünkü sizin ve müşterilerinizin değerli iş bilgilerini temsil eder. Bu nedenle verilerinizi dikkatli bir şekilde yönetmek önemlidir. Çok kiracılı bir sistem için depolama veya veri bileşenlerini planlarken kiracılarınızın verilerini paylaşma veya yalıtma yaklaşımına karar vermeniz gerekir.
Bu makalede, verileri çok kiracılı bir sistemde depolamaya yönelik bir yaklaşıma karar verirken çözüm mimarları için önemli olan önemli noktalar ve gereksinimler hakkında rehberlik sağlıyoruz. Ardından, depolama ve veri hizmetlerine çok kiracılı uygulama için bazı yaygın desenler ve kaçınılması gereken bazı kötü amaçlı modeller öneririz. Son olarak, bazı belirli durumlar için hedefli rehberlik sağlıyoruz.
Önemli noktalar ve gereksinimler
Depolama ve veri hizmetleri için kullandığınız yaklaşımları, Azure İyi Tasarlanmış Çerçeve'nin yapı taşlarıyla yaklaşık olarak uyumlu olan bir dizi perspektiften ele almak önemlidir.
Ölçek
Verilerinizi depolayan hizmetlerle çalışırken sahip olduğunuz kiracı sayısını ve depoladığınız veri hacmini dikkate almanız gerekir. Az sayıda kiracınız varsa (örneğin, beş veya daha az) ve her kiracı için az miktarda veri depoluyorsanız, yüksek oranda ölçeklenebilir bir veri depolama yaklaşımı planlamak veya veri kaynaklarınızı yönetmek için tam otomatik bir yaklaşım oluşturmak büyük olasılıkla boşa harcanan bir çaba olacaktır. Ancak büyüdükçe, verilerinizi ve depolama kaynaklarınızı ölçeklendirmek ve bunların yönetimine otomasyon uygulamak için net bir stratejiye sahip olmanın avantajı giderek artar. 50 veya daha fazla kiracınız varsa veya bu ölçek düzeyine ulaşmayı planlıyorsanız, önemli bir nokta olarak ölçekle birlikte verilerinizi ve depolama yaklaşımınızı tasarlamanız özellikle önemlidir.
Ölçeklendirmeyi ne ölçüde planladığınızı göz önünde bulundurun ve bu ölçek düzeyini karşılamak için veri depolama mimari yaklaşımınızı açıkça planlayın.
Performans öngörülebilirliği
Çok kiracılı veriler ve depolama hizmetleri özellikle Gürültülü Komşu sorununa açıktır. Kiracılarınızın birbirlerinin performansını etkileyip etkilemeyebileceğini göz önünde bulundurmanız önemlidir. Örneğin, kiracılarınızın kullanım düzenlerinde zaman içinde çakışan zirveler var mı? Tüm müşterileriniz çözümünüzü her gün aynı anda mı kullanıyor yoksa istekler eşit olarak mı dağıtılıyor? Bu faktörler, tasarlamanız gereken yalıtım düzeyini, sağlamanız gereken kaynak miktarını ve kaynakların kiracılar arasında paylaşılma derecesini etkiler.
Bu kararın bir parçası olarak Azure'ın kaynak ve istek kotalarını göz önünde bulundurmak önemlidir. Örneğin, kiracılarınızın tüm verilerini içerecek tek bir depolama hesabı dağıttığınızı varsayalım. Saniye başına belirli bir depolama işlemi sayısını aşarsanız Azure Depolama uygulamanızın isteklerini reddeder ve tüm kiracılarınız etkilenir. Buna azaltma davranışı denir. Kısıtlanmış istekleri izlemeniz önemlidir. Daha fazla bilgi için bkz . Azure hizmetleri için yeniden deneme kılavuzu.
Veri yalıtımı
Çok kiracılı veri hizmetleri içeren bir çözüm tasarlarken genellikle farklı seçenekler ve veri yalıtımı düzeyleri vardır ve bunların her biri kendi avantajları ve dezavantajları vardır. Örnek:
- Azure Cosmos DB'yi kullanırken her kiracı için ayrı kapsayıcılar dağıtabilir ve veritabanlarını ve hesapları birden çok kiracı arasında paylaşabilirsiniz. Alternatif olarak, gerekli yalıtım düzeyine bağlı olarak her kiracı için farklı veritabanları ve hatta hesaplar dağıtmayı düşünebilirsiniz.
- Blob verileri için Azure Depolama kullanırken, her kiracı için ayrı blob kapsayıcıları dağıtabilir veya ayrı depolama hesapları dağıtabilirsiniz.
- Azure SQL kullanırken, paylaşılan veritabanlarında ayrı tablolar kullanabilir veya her kiracı için ayrı veritabanları veya sunucular dağıtabilirsiniz.
- Tüm Azure hizmetlerinde, kaynakları tek bir paylaşılan Azure aboneliği içinde dağıtmayı göz önünde bulundurabilir veya birden çok Azure aboneliği (belki de kiracı başına bir tane) kullanabilirsiniz.
Her duruma uygun tek bir çözüm yoktur. Seçtiğiniz seçenek, bir dizi faktöre ve kiracılarınızın gereksinimlerine bağlıdır. Örneğin, kiracılarınızın belirli uyumluluk veya mevzuat standartlarını karşılaması gerekiyorsa, daha yüksek bir yalıtım düzeyi uygulamanız gerekebilir. Benzer şekilde, müşterilerinizin verilerini fiziksel olarak yalıtmak için ticari gereksinimleriniz olabilir veya Gürültülü Komşu sorununu önlemek için yalıtımı zorunlu kılmanız gerekebilir. Ayrıca, kiracıların kendi şifreleme anahtarlarını kullanması gerekiyorsa, tek tek yedekleme ve geri yükleme ilkelerine sahip olmaları veya verilerinin farklı coğrafi konumlarda depolanması gerekiyorsa, bunları diğer kiracılardan yalıtmanız veya benzer ilkelere sahip kiracılarla gruplandırmanız gerekebilir.
Uygulamanın karmaşıklığı
Uygulamanızın karmaşıklığını göz önünde bulundurmanız önemlidir. Gereksinimlerinizi karşılamaya devam ederken mimarinizi olabildiğince basit tutmak iyi bir uygulamadır. Ölçeklendirdikçe giderek daha karmaşık hale gelecek bir mimariye veya geliştirme ve bakım için kaynaklara veya uzmanlığa sahip olmadığınız bir mimariye bağlanmaktan kaçının.
Benzer şekilde, çözümünüzün çok fazla sayıda kiracıya ölçeklendirilmesi gerekmiyorsa veya performans veya veri yalıtımıyla ilgili endişeleriniz yoksa, çözümünüzü basit tutmak ve gereksiz karmaşıklık eklemekten kaçınmak daha iyidir.
Çok kiracılı veri çözümleri için özel bir endişe, desteklediğiniz özelleştirme düzeyidir. Örneğin, bir kiracı veri modelinizi genişletebilir veya özel veri kuralları uygulayabilir mi? Bu gereksinim için önceden tasarladığınızdan emin olun. Tek tek kiracılar için çatal oluşturma veya özel altyapı sağlamaktan kaçının. Özelleştirilmiş altyapı ölçeklendirme, çözümünüzü test etme ve güncelleştirmeleri dağıtma yeteneğinizi engeller. Bunun yerine özellik bayraklarını ve diğer kiracı yapılandırması biçimlerini kullanmayı göz önünde bulundurun.
Yönetim ve işlemlerin karmaşıklığı
Çözümünüzü nasıl çalıştırmayı planladığınızı ve çok kiracılı yaklaşımınızın operasyonlarınızı ve süreçlerinizi nasıl etkilediğini düşünün. Örnek:
- Yönetim: Düzenli bakım etkinlikleri gibi kiracılar arası yönetim işlemlerini göz önünde bulundurun. Birden çok hesap, sunucu veya veritabanı kullanıyorsanız, her kiracı için işlemleri nasıl başlatacak ve izleyeceksiniz?
- İzleme ve ölçüm: Kiracılarınızı izler veya ölçerseniz çözümünüzün ölçümleri nasıl rapor ettiğini ve bunların isteği tetikleyen kiracıya kolayca bağlanıp bağlanamayacağını göz önünde bulundurun.
- Raporlama: Yalıtılmış kiracılardan gelen verileri raporlamak, her bir veritabanında ayrı ayrı sorgu çalıştırmak ve ardından sonuçları toplamak yerine her kiracının merkezi bir veri ambarına veri yayımlamasını gerektirebilir.
- Şema güncelleştirmeleri: Şemayı zorlayan bir veritabanı kullanıyorsanız, şema güncelleştirmelerini varlığınız arasında nasıl dağıtacağınız planlayın. Uygulamanızın belirli bir kiracının veritabanı sorguları için hangi şema sürümünü kullanacağınızı nasıl bildiğini düşünün.
- Gereksinimler: Kiracılarınızın yüksek kullanılabilirlik gereksinimlerini (örneğin, çalışma süresi hizmet düzeyi sözleşmeleri veya SLA'lar) ve olağanüstü durum kurtarma gereksinimlerini (örneğin, kurtarma süresi hedeflerini veya GPO'ları ve kurtarma noktası hedeflerini veya RPC'leri) göz önünde bulundurun. Kiracıların farklı beklentileri varsa, her kiracının gereksinimlerini karşılayabilecek misiniz?
- Geçiş: Farklı bir hizmet türüne, farklı bir dağıtıma veya başka bir bölgeye geçmeleri gerekiyorsa kiracıları nasıl geçirirsiniz?
Maliyet
Genellikle, kiracıların dağıtım altyapınızdaki yoğunluğu ne kadar yüksek olursa, bu altyapıyı sağlama maliyeti de o kadar düşük olur. Ancak, paylaşılan altyapı Gürültülü Komşu sorunu gibi sorunların olasılığını artırır, bu nedenle dengeleri dikkatli bir şekilde göz önünde bulundurun.
Dikkate alınacak yaklaşımlar ve desenler
Azure Mimari Merkezi'nden alınan çeşitli tasarım desenleri, çok kiracılı depolama ve veri hizmetlerine yöneliktir. Tek bir deseni tutarlı bir şekilde izlemeyi seçebilirsiniz. Alternatif olarak, desenleri karıştırmayı ve eşleştirmeyi de düşünebilirsiniz. Örneğin, kiracılarınızın çoğu için çok kiracılı bir veritabanı kullanabilirsiniz, ancak daha fazla ödeme yapan veya olağan dışı gereksinimleri olan kiracılar için tek kiracılı damgalar dağıtabilirsiniz. Benzer şekilde, bir damga pulu içinde çok kiracılı bir veritabanı veya parçalı veritabanları kullandığınızda bile dağıtım damgalarını kullanarak ölçeklendirmek genellikle iyi bir uygulamadır.
Dağıtım DamgaLarı düzeni
Dağıtım DamgaLarı düzeninin çok kiracılı bir çözümü desteklemek için nasıl kullanılabileceğini öğrenmek için bkz. Genel Bakış.
Paylaşılan çok kiracılı veritabanları ve dosya depoları
Paylaşılan çok kiracılı bir veritabanı, depolama hesabı veya dosya paylaşımı dağıtmayı ve tüm kiracılarınızda paylaşmayı düşünebilirsiniz.
Bu yaklaşım, altyapıya en yüksek kiracı yoğunluğu sağlar, bu nedenle herhangi bir yaklaşımın en düşük maliyetiyle gelme eğilimindedir. Ayrıca yönetilmesi, yedeklenmesi ve güvenliğinin sağlanıp sağlanmadığı için genellikle yönetim ek yükünü azaltır.
Ancak, paylaşılan altyapıyla çalışırken göz önünde bulundurmanız gereken birkaç uyarı vardır:
- Ölçek sınırları: Tek bir kaynağa bağlı olduğunuzda, bu kaynağın desteklenen ölçeğini ve sınırlarını göz önünde bulundurun. Örneğin, mimariniz tek bir veritabanı kullanıyorsa, bir veritabanı veya dosya deposunun en büyük boyutu veya en yüksek aktarım hızı sınırları sonunda sabit bir engelleyici haline gelir. Bu düzeni seçmeden önce, elde etmeniz gereken maksimum ölçeği dikkatle göz önünde bulundurun ve geçerli ve gelecekteki sınırlarınızla karşılaştırın.
- Gürültülü komşular:Özellikle meşgul olan veya diğerlerinden daha yüksek iş yükleri oluşturan kiracılarınız varsa, Gürültülü Komşu sorunu bir faktör haline gelebilir. Bu etkileri azaltmak için Azaltma desenini veya Hız Sınırlama desenini uygulamayı göz önünde bulundurun.
- Her kiracıyı izleme: Etkinliği izlemek ve tek bir kiracının tüketimini ölçmekte zorluk yaşayabilirsiniz. Azure Cosmos DB gibi bazı hizmetler, her istek için kaynak kullanımıyla ilgili raporlama sağlar, böylece bu bilgiler her kiracının tüketimini ölçmek için izlenebilir. Diğer hizmetler aynı ayrıntı düzeyini sağlamaz. Örneğin, dosya kapasitesine yönelik Azure Dosyalar ölçümleri yalnızca premium paylaşımları kullandığınızda dosya paylaşımı boyutu başına kullanılabilir. Ancak standart katman ölçümleri yalnızca depolama hesabı düzeyinde sağlar.
- Kiracı gereksinimleri: Kiracıların güvenlik, yedekleme, kullanılabilirlik veya depolama konumu için farklı gereksinimleri olabilir. Bunlar tek kaynağınızın yapılandırmasıyla eşleşmiyorsa, bunları barındıramayabilirsiniz.
- Şema özelleştirmesi: İlişkisel bir veritabanıyla veya verilerin şemasının önemli olduğu başka bir durumla çalıştığınızda, kiracı düzeyinde şema özelleştirmesi zordur.
Parçalama düzeni
Parçalama düzeni, her biri bir veya daha fazla kiracının verilerini içeren parçalar olarak adlandırılan birden çok ayrı veritabanı dağıtmayı içerir. Dağıtım damgalarından farklı olarak parçalar, altyapının tamamının çoğaltıldığı anlamına gelmez. Ayrıca çözümünüzdeki diğer altyapıyı çoğaltmadan veya parçalamadan veritabanlarını parçalayabilirsiniz.
Parçalama bölümlemeyle yakından ilgilidir ve terimler genellikle birbirinin yerine kullanılır. Yatay, dikey ve işlevsel veri bölümleme kılavuzunu göz önünde bulundurun.
Parçalama düzeni çok fazla sayıda kiracıya ölçeklendirilebilir. Ayrıca, iş yükünüz bağlı olarak, maliyetlerin cazip olabilmesi için parçalar için yüksek kiracı yoğunluğu elde edebilirsiniz. Parçalama düzeni, Azure aboneliğini ve hizmet kotalarını, sınırlarını ve kısıtlamalarını ele almak için de kullanılabilir.
Azure Cosmos DB gibi bazı veri depoları parçalama veya bölümleme için yerel destek sağlar. Azure SQL gibi diğer çözümlerle çalışırken, bir parçalama altyapısı oluşturmak ve istekleri belirli bir kiracı için doğru parçaya yönlendirmek daha karmaşık olabilir.
Parçalama, kiracı düzeyinde yapılandırma farklılıklarını desteklemeyi ve müşterilerin kendi şifreleme anahtarlarını sağlamasını da zorlaştırır.
Her kiracı için ayrılmış veritabanlarına sahip çok kiracılı uygulama
Bir diğer yaygın yaklaşım da her kiracı için ayrılmış veritabanlarıyla tek bir çok kiracılı uygulama dağıtmaktır.
Bu modelde, her kiracının verileri diğerlerinden yalıtılır ve her kiracı için bir miktar özelleştirmeyi destekleyebilirsiniz.
Her kiracı için ayrılmış veri kaynakları sağladığınız için, bu yaklaşımın maliyeti paylaşılan barındırma modellerinden daha yüksek olabilir. Ancak Azure, tek tek veri kaynaklarını birden çok kiracıda barındırma maliyetini paylaşmak için göz önünde bulundurabileceğiniz çeşitli seçenekler sunar. Örneğin, Azure SQL ile çalışırken elastik havuzları göz önünde bulundurabilirsiniz. Azure Cosmos DB için bir veritabanı için aktarım hızı sağlayabilirsiniz ve aktarım hızı bu veritabanındaki kapsayıcılar arasında paylaşılır, ancak her kapsayıcı için garantili performansa ihtiyacınız olduğunda bu yaklaşım uygun değildir.
Bu yaklaşımda, her kiracı için tek tek yalnızca veri bileşenleri dağıtıldığından, çözümünüzdeki diğer bileşenler için yüksek yoğunluk elde edebilir ve bu bileşenlerin maliyetini düşürebilirsiniz.
Her kiracı için veritabanları sağlarken otomatik dağıtım yaklaşımlarını kullanmak önemlidir.
Coğrafi bölge deseni
Geode deseni, çok kiracılı çözümler de dahil olmak üzere coğrafi olarak dağıtılmış çözümler için özel olarak tasarlanmıştır. Yüksek yük ve yüksek dayanıklılık düzeylerini destekler. Coğrafi bölge desenini uygularsanız, veri katmanınızın verileri coğrafi bölgeler arasında çoğaltabilmesi ve çok coğrafyalı yazmaları desteklemesi gerekir.
Azure Cosmos DB bu düzeni desteklemek için çok ana şablonlu yazmalar sağlar ve Cassandra çok bölgeli kümeleri destekler. Diğer veri hizmetleri genellikle önemli özelleştirmeler olmadan bu düzeni destekleyemez.
Kaçınılması gereken kötü amaçlı değişkenler
Çok kiracılı veri hizmetleri oluşturduğunuzda, ölçeklendirme yeteneğinizi engelleyen durumlardan kaçınmak önemlidir.
İlişkisel veritabanları için bunlar şunlardır:
- Tablo tabanlı yalıtım. Tek bir veritabanında çalışırken, her kiracı için ayrı tablolar oluşturmaktan kaçının. Bu yaklaşımı kullandığınızda tek bir veritabanı çok fazla sayıda kiracıyı desteklemez ve verileri sorgulamak, yönetmek ve güncelleştirmek giderek zorlaşır. Bunun yerine, kiracı tanımlayıcı sütununa sahip tek bir çok kiracılı tablo kümesi kullanmayı göz önünde bulundurun. Alternatif olarak, her kiracı için ayrı veritabanları dağıtmak için yukarıda açıklanan desenlerden birini kullanabilirsiniz.
- Sütun düzeyinde kiracı özelleştirmesi. Yalnızca tek bir kiracıya uygulanan şema güncelleştirmelerini uygulamaktan kaçının. Örneğin, tek bir çok kiracılı veritabanınız olduğunu varsayalım. Belirli bir kiracının gereksinimlerini karşılamak için yeni sütun eklemekten kaçının. Az sayıda özelleştirme için kabul edilebilir olabilir, ancak dikkate almanız gereken çok sayıda özelleştirme olduğunda bu hızla yönetilemez hale gelir. Bunun yerine, ayrılmış bir tablodaki her kiracı için özel verileri izlemek üzere veri modelinizi gözden geçirmeyi göz önünde bulundurun.
- El ile şema değişiklikleri. Tek bir paylaşılan veritabanınız olsa bile veritabanı şemanızı el ile güncelleştirmekten kaçının. Uyguladığınız güncelleştirmeleri izlemek kolaydır ve daha fazla veritabanı için ölçeği genişletmeniz gerekiyorsa, uygulanacak doğru şemayı belirlemek zordur. Bunun yerine, şema değişikliklerinizi dağıtmak için otomatik bir işlem hattı oluşturun ve bunu tutarlı bir şekilde kullanın. Ayrılmış bir veritabanında veya arama tablosundaki her kiracı için kullanılan şema sürümünü izleyin.
- Sürüm bağımlılıkları. Uygulamanızın veritabanı şemanızın tek bir sürümüne bağımlılık almasını önlemek. Ölçeklendikçe, farklı kiracılar için şema güncelleştirmelerini farklı zamanlarda uygulamanız gerekebilir. Bunun yerine, uygulama sürümünüzün en az bir şema sürümüyle geriye dönük uyumlu olduğundan emin olun ve yıkıcı şema güncelleştirmelerinden kaçının.
Veritabanları
Çok kiracılı kullanım için yararlı olabilecek bazı özellikler vardır. Ancak, bunlar tüm veritabanı hizmetlerinde kullanılamaz. Senaryonuz için kullanılacak hizmete karar verince bunlara ihtiyacınız olup olmadığını göz önünde bulundurun:
- Satır düzeyi güvenlik , paylaşılan çok kiracılı veritabanında belirli kiracıların verileri için güvenlik yalıtımı sağlayabilir. Bu özellik Azure SQL ve Postgres Flex'te kullanılabilir, ancak MySQL veya Azure Cosmos DB gibi diğer veritabanlarında kullanılamaz.
- Verileri için kendi şifreleme anahtarlarını sağlayan kiracıları desteklemek için kiracı düzeyinde şifreleme gerekebilir. Bu özellik, Always Encrypted'ın bir parçası olarak Azure SQL'de kullanılabilir. Azure Cosmos DB, hesap düzeyinde müşteri tarafından yönetilen anahtarlar sağlar ve Always Encrypted'ı da destekler.
- Kaynak havuzu, kaynakları ve maliyeti birden çok veritabanı veya kapsayıcı arasında paylaşma olanağı sağlar. Bu özellik, Azure SQL'in elastik havuzlarında ve yönetilen örneklerinde ve Azure Cosmos DB veritabanı aktarım hızında kullanılabilir, ancak her seçeneğin bilmeniz gereken sınırlamaları vardır.
- Parçalama ve bölümleme , bazı hizmetlerde diğerlerinden daha güçlü yerel desteğe sahiptir. Bu özellik Azure Cosmos DB'de, mantıksal ve fiziksel bölümleme kullanılarak ve PostgreSQL Hiper Ölçek'te kullanılabilir. Azure SQL parçalama işlemini yerel olarak desteklemese de, bu tür mimariyi desteklemek için parçalama araçları sağlar.
Ayrıca, ilişkisel veritabanları veya diğer şema tabanlı veritabanlarıyla çalışırken, bir veritabanı filosu tutarken şema yükseltme işleminin tetiklenmesi gereken yeri göz önünde bulundurun. Küçük bir veritabanı varlığında, şema değişikliklerini dağıtmak için bir dağıtım işlem hattı kullanmayı düşünebilirsiniz. Büyüdükçe, uygulama katmanınızın belirli bir veritabanının şema sürümünü algılaması ve yükseltme işlemini başlatması daha iyi olabilir.
Dosya ve blob depolama
Depolama hesabındaki verileri yalıtmak için kullandığınız yaklaşımı göz önünde bulundurun. Örneğin, her kiracı için ayrı depolama hesapları dağıtabilir veya depolama hesaplarını paylaşabilir ve tek tek kapsayıcıları dağıtabilirsiniz. Alternatif olarak, paylaşılan blob kapsayıcıları oluşturabilir ve ardından blob yolunu kullanarak her kiracı için verileri ayırabilirsiniz. Azure abonelik sınırlarını ve kotalarını göz önünde bulundurun ve Azure kaynaklarınızın gelecekteki gereksinimlerinizi destekleyecek şekilde ölçeklendirildiğinden emin olmak için büyümenizi dikkatlice planlayın.
Paylaşılan kapsayıcılar kullanıyorsanız, kiracıların birbirlerinin verilerine erişemediğinden emin olmak için kimlik doğrulama ve yetkilendirme stratejinizi dikkatlice planlayın. İstemcilere Azure Depolama kaynaklarına erişim sağladığınızda Vale Anahtarı düzenini göz önünde bulundurun.
Maliyet tahsisatı
Paylaşılan veri hizmetlerinin kullanımı için tüketimi nasıl ölçebileceğinizi ve kiracılara maliyetleri nasıl ayırabileceğinizi düşünün. Mümkün olduğunda, kendi ölçümünüzü hesaplamak yerine yerleşik ölçümleri kullanmayı hedefleyin. Ancak paylaşılan altyapı ile tek tek kiracılar için telemetriyi bölmek zorlaşır ve uygulama düzeyinde özel ölçüm yapmayı göz önünde bulundurmanız gerekir.
Genel olarak, Azure Cosmos DB ve Azure Blob Depolama gibi bulutta yerel hizmetler, belirli bir kiracının kullanımını izlemek ve modellemek için daha ayrıntılı ölçümler sağlar. Örneğin, Azure Cosmos DB her istek ve yanıt için tüketilen aktarım hızını sağlar.
Katkıda Bulunanlar
Bu makale Microsoft tarafından yönetilir. Başlangıçta aşağıdaki katkıda bulunanlar tarafından yazılmıştır.
Asıl yazar:
- John Downs | Baş Müşteri Mühendisi, Azure için FastTrack
Diğer katkıda bulunanlar:
- Paul Burpo | Baş Müşteri Mühendisi, Azure için FastTrack
- Daniel Scott-Raynsford | İş Ortağı Teknoloji Stratejisti
- Arsen Vladimirskiy | Baş Müşteri Mühendisi, Azure için FastTrack
Genel olmayan LinkedIn profillerini görmek için LinkedIn'de oturum açın.
Sonraki adımlar
Çok kiracılılık ve belirli Azure hizmetleri hakkında daha fazla bilgi için bkz: