Çok kiracılığı destekleme


10

Tek kiracılı bir uygulamayı çok kiracılı bir uygulamaya dönüştürürken ortaya çıkan tipik zorluklar nelerdir? Güvenlik ve veri yalıtımı bana en önemlisi gibi geliyor. Diğerleri neler?

Oldukça önemli bir otomasyon çabası için mimarlardan biriyim ve tarihsel olarak bunu kullanan şirketimizdi. Başkalarının da kullanmasını mümkün kılmak istiyoruz. "Çok kiracılı hale getirme" hakkında her konuştuğumuzda, konuşma bir kiracılı kullanıcıları başka bir kiracıya ait verilerden uzak tutmak ve bir kiracılı kullanıcıların (kasıtlı olarak veya yanlışlıkla) başka bir hesapta etki yaratamayacağından emin olmak etrafında döner. kiracı ortamları. Merak ettiğim şey, güvenlik / veri izolasyonunun gerçekten tek büyük endişe kaynağı olup olmadığı ya da sadece düşünmediğimiz başka önemli endişeler olup olmadığıdır.


En kolay çözüm? Boş, sıfırdan donanım dahil tüm sistemin yeni bir örneği, kiracı başına bir yeni sistem. Sistem ve veriler oldukça değerliyse, bu oldukça iyi bir seçenek olabilir. Her örnek için yeni donanımı sevmiyorsanız sanallaştırmayı kullanın. En verimli olmayabilir, ancak kesinlikle bir ton baş ağrısını kurtaracaktır.
SF.

Muhtemelen tasarım açısından bu en kolayıdır, ancak idari açıdan bakıldığında görünmüyor. En azından sistem yöneticilerimiz bu teklif konusunda çok heyecanlı değiller. (Ve evet, VM'leri kullanıyoruz.) Yönetmek için daha fazla örnek (izleme, dağıtım vb.) Aslında burada, ancak bunun karşısında fiziksel bir izolasyon elde etmek için bunu daha yönetilebilir hale getirmenin yollarını arıyoruz. yaklaşım yönetici sadeliği için dev sadelik ticaret gibi görünüyor ...?

Yanıtlar:


11

Verilerin silolandırılmasının yanı sıra,

  1. Kullanılabilirlik - tek bir kiracıyla, yalnızca DoS'ın kendileri yapabilirler, ancak veriler düzgün bir şekilde silindiğinde bile, bir kiracı hala kaynakları tüketebilir.
  2. Günlük tutma - tüm günlük iletileri tek bir kiracı olarak kabul edildi. Günlükleri kiracı başına silolamadığınız sürece, günlük iletileriniz daha az kullanışlı olabilir.
  3. Eşzamanlılık - tek kiracı uygulamaları orta yük altında çalışabilir veya birkaç kilit için yüksek çekişme belirli işlemleri etkili bir şekilde serileştirebilir. Kilitler kiracı başına çarpılırsa, daha önce gerçekleşmemiş işlemlerin harmanlanmasını görmeye başlayabilirsiniz. Hiç tezahür etmesi pek mümkün olmayan yarış koşullarının şimdi tezahür etmesi muhtemel olabilir.
  4. Yeni kaynak çekişme kaynakları - n soket ve m dosya tanıtıcısı olmadan önce kiracı başına çarpar.
  5. Yapılandırılabilirlik / geriye dönük uyumluluk ödünleşimleri - bir yenisi hazırlanırken bir bileşeni geçersiz kılabilmeniz için artık bir bileşen talep eden bir kiracıya ve yerini aldığı eski bileşenin süresiz olarak kalmasını isteyen bir kiracıya sahip olabilirsiniz.
  6. Mahkeme celbi hedefi - şu anda şirketinizle ilgili sorunlar için mahkeme celbi hedefisiniz. Birden çok kiracıyla, yasal işlemlere taraf olmasanız bile mahkeme celbi taleplerine yanıt vermeniz gerekebilir.

Bunlardan bazıları tüm kiracıları aynı adres alanında (makine veya küme) çalıştırdığınızı varsayar. Her kiracı yazılımınızı donanımlarında çalıştırıyorsa, yukarıdakilerden bazılarını tartışabilir ve şunları ekleyebilirsiniz:

  1. Hata ayıklamak için makinelere erişimde zorluklar.
  2. Eski sürümler için destek talepleri.
  3. Üçüncü taraf yüklenicilerin yapılandırmasına izin verme istekleri.
  4. Üzerinde çalıştığı donanım üzerinde daha az kontrol.
  5. Çalıştığı işletim sisteminin yama / güncelleme döngüsü üzerinde daha az kontrol.

1

Bence çoklu kiracılığın en büyük sorunu kişiselleştirme. İşletmelere bir iş uygulaması satıyorsanız bu rutin olarak gerçekleşir. Kendi derilerini isteyen her müşteri kadar basit bir şeyden ek alanları, kuralları, formları ve raporları yapılandırma yeteneğine kadar değişebilir. Desteklemeniz gereken özelleştirme düzeyi mimaride kritik bir rol oynar.


1

Mike'ın cevabı çok iyi ve orada bulunan noktaların çoğu, ne kadar kısa oldukları için karmaşıklıklarını neredeyse hafife alıyorlar, bu yüzden bunları kalbe alın.

Ekleyeceğim bir nokta, yeni kiracılar oluşturmak (ve daha sonra yönetmek) için iyi yönetim araçlarına sahip olmanızdır. Gittiğiniz fiziksel mimariye bağlı olarak, bu önemsiz olmaktan uzak olabilir ve genellikle gözden kaçan bir şeydir. Bir hizmet ürünü olarak bir yazılımın faydaları sadece çok sayıda kiracı olduğunda gerçekten işe yarar, bu nedenle bunun için yeterli miktarda çaba harcanmalıdır.

Sriram'ın cevabını genişletmek için; kiracının kişiselleştirilmesi neredeyse yasaktır, kiracının değiştirmek isteyebileceği her şey yapılandırılabilir olmalıdır . Örneğin, çözümünüz en az birkaç önemli alana dinamik olarak veri alanlarının eklenmesini sağlamazsa, büyük olasılıkla özelleştirme istekleriyle karşılaşırsınız. Biraz ek karmaşıklık peşin aslında ödemek yok birkaç olgunun bir (hadi o YAGNI aykırı diyorum yoksa bu kadar en azından, konfigürasyonun bu seviye, hemen hemen kilit şartlardan biri olduğunu vardır ihtiyacım olacak o).


Özelleştirme neden "yasaktır"? Kesinlikle teknik olarak erişilebilir. Çekirdek sistemin birden çok kiracı için yeniden kullanılmasına izin verirken, bireysel kiracılar için özelleştirilmiş parçalar sağlarken birçok farklı desen vardır. Bir müşteri özelleştirme için size ödeme yapmak istiyorsa, bunu dikkate almak makul görünecektir. Bu nedenle, müşteri başına özelleştirmelere sahip birçok çok ürünlü ürün vardır. Genişletilebilirliğe izin vermek ve her şeyi yapılandırılabilir yapmak için varsayılan değil, YAGNI IMO'nun ruhunda daha fazladır.
RationalGeek

1
Eh, yazılıma genel olarak bir hizmet uygulaması olarak atıfta bulunuyorum ("çoklu kiracılıktan"). Elbette, teknik olarak ulaşılabilir, ancak SaaS'ın temellerine aykırıdır. Finansal anlamda, birçok kiracı için uygulamayı ve muhtemelen altyapıyı paylaşarak daha düşük maliyetler elde edersiniz. Bu, ürününüzü daha düşük bir fiyatla sunmanıza izin verir, böylece pazarın "uzun kuyruğunu" yakalar (çok az sayıda insan sadece küçük bir miktar ödemek isteyen). Bir sistemin belki 5 dalını koruyabilirsiniz, ancak 15000'i koruyamazsınız ve SaaS'ın amacı budur.
Daniel B

İşletme düzeyinde, bir müşteriyi indirmek için kodlarında önemli özelleştirmeler yapmak isteyen SaaS satıcılarını sık sık görüyorum. Bir müşteri hizmet için 6 veya 7 rakam ödüyorsa, bu muhtemelen makul bir iş modelidir.
RationalGeek

Evet, bu gibi durumlarda, sanırım. Gördüğüm değişikliklerin çoğu, varsayılan olarak mevcut istemciler için kapalı olan yeni yapılandırılabilir özellikler olarak uygulandı. Sorun, bence, ilk 3 veya 4 istemcinin her birinin özel bir tedavi görmesi, çünkü çözüm henüz başlamamasıdır. Çözüm çok spesifik bir şekilde sonuçlanıyor ve "Tamam, sadece hackleyeceğiz" kültürünü yaratıyor. Ama evet, büyük müşteriler hakkındaki yorumunuza katılıyorum.
Daniel B

Bu, özelleştirilebilirlik konusunda yaptığınız faydalı bir ayrımdır. Aynı kavramın yönetilebilirlik için de geçerli olabileceğini düşünüyorum. Çoktanlılığımız muhtemelen uzun kuyruklu müşterilerden ziyade nispeten daha az büyük müşterileri hedeflemektedir. Çok kiracılığın temel amacı uzun kuyruğu yakalamaksa, o zaman bizim için doğru yaklaşım bile olmayabilir. Bu düşünceler için teşekkürler.
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.