Підтримка багатожиття

Які типові проблеми, які виникають при перетворенні додатка для одного орендаря в багатостороннє додаток? Безпека та ізоляція даних вважають мене найбільш важливим. Які ще інші?

Я один з архітекторів, який доклав значних зусиль щодо автоматизації, і історично це було лише за допомогою нашої компанії. Ми хочемо дати можливість і іншим цим користуватися. Щоразу, коли ми говоримо про те, щоб зробити його багатостороннім, розмова обертається тим, щоб утримувати користувачів одного орендаря від даних, якими володіє інший орендар, і переконатися, що користувачі, які мають одного орендаря, не можуть (навмисно чи ненавмисно) створювати впливи на іншого середовища орендаря. Мені цікаво, чи справді є безпека / ізоляція даних єдиною головною проблемою, чи є якісь інші основні проблеми, про які ми просто не думаємо.

Крім передачі даних, у вас можуть виникнути проблеми

1. Доступність - з одним орендарем вони можуть здійснювати лише DoS, але навіть коли дані належним чином оснащені, орендар все ще може вичерпати ресурси.
2. Ведення журналу - усі повідомлення журналу передбачають одного орендаря. Якщо ви не проводите журнали силосів на одного орендаря, ваші повідомлення журналу можуть стати менш корисними.
3. Паралельність - окремі програми орендарів можуть працювати при помірному навантаженні, або велика суперечка для кількох замків може ефективно серіалізувати певні операції. Якщо замки множиться на одного орендаря, ви можете почати бачити переплетення операцій, які раніше не відбувалися. Умови перегонів, які навряд чи колись проявляться, зараз, швидше за все, проявляться.
4. Нові джерела суперечки щодо ресурсів - де раніше ви могли мати n сокетів і m файлових файлів, тепер помножте це на кожного орендатора.
5. Конфігураційність / зворотність компромісу сумісності - коли раніше ви зможете застаріти компонент під час розгортання заміни, тепер у вас може бути один орендар, який вимагає компонента, і один орендар, який вимагає, щоб старий компонент, який він замінив, залишався без обмежень.
6. Ціль виклику в суд - на даний момент ви цільова повістка в суд для проблем, пов'язаних з вашою компанією. З кількома орендарями вам, можливо, доведеться відповідати на прохання в суд, навіть якщо ви не є учасником судових позовів.

Деякі з них припускають, що ви працюєте з усіма орендарями в одному адресному просторі (на машині або в кластері). Якщо кожен орендар працює на вашому програмному забезпеченні на своєму апаратному забезпеченні, ви можете передати певне вищезазначене та додати:

1. Труднощі з доступом до машин для налагодження.
2. Запити на підтримку старих версій.
3. Просить дозволити стороннім підрядникам налаштувати.
4. Менший контроль над апаратним забезпеченням, на якому він працює.
5. Менший контроль над циклом виправлення / оновлення ОС, на якій він працює.

На мою думку, найбільша проблема мультиплікації - це персоналізація. Це відбувається звичайно, якщо ви продаєте бізнес-додаток підприємствам. Це може відрізнятися від чогось простого, як кожен клієнт, який бажає власної шкіри, до можливості налаштування додаткових полів, правил, форм та звітів. Рівень налаштування, який потрібно підтримувати, відіграє важливу роль в архітектурі.

Відповідь Майка дуже хороша, і багато пунктів там майже недооцінюють їх складність через те, наскільки вони короткі, тому прийміть їх до серця.

Хочеться додати, що у вас повинні бути хороші інструменти управління для створення (а згодом і управління) нових орендарів. Залежно від фізичної архітектури, з якою ви їдете, це може бути далеко не банальним, і це те, що часто не помічається. Переваги програмного забезпечення як сервісного продукту дійсно вступають у життя лише тоді, коли є велика кількість орендарів, тому для цього слід докласти чимало зусиль.

Продовжити відповідь Шрірама; налаштування на одного орендаря майже заборонено, все, що орендар може змінити, має бути налаштоване . Наприклад, якщо ваше рішення не забезпечує динамічне додавання полів даних принаймні в декілька ключових областей, ви, ймовірно, буде завалене запитами на налаштування. Це один з небагатьох випадків, коли трохи додаткової складності наперед реально окупиться (скажімо, це суперечить YAGNI, або, принаймні, такий рівень конфігурації є майже ключовою вимогою, тому вам це знадобиться).