У колах SaaS припущення про те, що архітектура постачальника є чимось меншим, ніж повністю багатокористувацький, рівносильне сумніву в мужності людини чи запереченню патріотизму американця.
Для пуристів SaaS мультитенантність — архітектурна модель, яка дозволяє їм обслуговувати кількох клієнтів з одного спільного екземпляр програми — це символ віри, єдине, що позначає їх як плем’я, крім традиційного програмного забезпечення постачальники. Таким чином, припущення, що вони є чимось іншим, ніж повністю багатоквартирним, рівносильне сумніву в мужності чоловіка або оскарженню патріотизму американця. Це ще не зроблено.
У розпал дискусії про безпеку Танавала зробив побіжний коментар, що мультитенантність не є необхідною умовою для SaaS. Голова групи Білл Макні, генеральний директор аналітичної групи Технологія Saugatuck, негайно оскаржив це твердження власним спостереженням про те, що мультиоренда є фундаментальною для SaaS. Тепер під тиском, щоб захистити свою позицію, речник Oracle відповів, що ISV SaaS у партнерській мережі Oracle використовувати різні архітектури. Далі він цитував Цілий на підтвердження своєї позиції, сказавши, що постачальник фінансів на вимогу запускає своїх клієнтів на окремих модулях, кожен з яких має окрему базу даних Oracle.
Це був доленосний приклад для вибору. Утілюючи найгірший кошмар кожного спікера конференції, організатор конференції Девід Томас, виконавчий директор SIIA відділу програмного забезпечення, взявши мікрофон, щоб категорично заперечити Танавалі: «Я колишній генеральний директор Intacct і можу сказати вам напевно, що це не справа. Архітектура Intacct повністю багатокористувацька», — сказав він.
Взявши участь у вебінарі лише минулого місяця з технічним директором Intacct Аароном Харрісом, Танавала був збентежений втручанням Томаса, але залишився на своєму — як і Томас. Після цього під час перерви на каву можна було побачити, як вони обговорюють свої розбіжності.
Просте пояснення дискомфорту Танавали полягає в тому, що існує багато ступенів багатоквартирності, тоді як він використовував цей термін виключно в його найчистішому сенсі, як реалізовано Salesforce.com. Модель Intacct — яку схвалюють багато провідних постачальників SaaS, включаючи NetSuite — є однаково справедливою (хоча не в очах Salesforce.com). Існують менші варіації нижче цих пуристських реалізацій. Ось виклад основних відмінностей між моделлю Salesforce.com, моделлю Intacct і власним підходом Oracle до «pod»:
Salesforce.com: мультиоренда першого ступеня. У цій моделі всі клієнти обслуговуються з єдиної інфраструктури, у якій усі компоненти є спільними, аж до таблиць у базі даних. Це часто називають багатокористуванням «спільної схеми», оскільки структура бази даних визначається схемою і якщо дані кожного зберігаються в цій структурі, то за визначенням усі мають спільний доступ до того самого схема. В ідеальному світі мультитенантна архітектура першого ступеня працює на одній логічній системі або екземплярі. Але в реальному світі, коли ви досягаєте розміру Salesforce.com, навіть Oracle не може запропонувати вам базу даних, здатну масштабувати настільки велике. Отже, Salesforce.com копіює свою архітектуру в (наразі) п’ять примірників у Північній Америці, а також окремі примірники в Європі та Азії.
Intactct: багатоквартирна оренда другого ступеня. Як і багато SaaS pureplays, Intacct використовує реплікацію набагато ширше, ніж Salesforce.com, для розподілу своїх екземплярів спільної схеми між великою кількістю серверних кластерів. Це означає, що він може використовувати звичайне обладнання, а не великі залізні системи, і менш схильний до збою однієї системи, залишаючись при цьому вірним моделі спільної схеми. У кожному кластері Intacct один екземпляр бази даних Oracle обслуговує спільну схему щонайменше 10 клієнтам. Основна відмінність від моделі Salesforce.com полягає в масштабі: Salesforce.com працює лише з вісьмома примірниками (для понад 43 000 клієнтів, співвідношення 1:5000), тоді як Intacct працює сто чи близько того десять (приблизно для 2500 клієнтів, співвідношення 1:250). Але є ще одна критична відмінність, яку пуристи бачать як значне розмивання принципу кількох орендарів: Intacct дозволяє клієнтам вибирати, коли вони оновлюються між випусками (протягом тримісячного вікна), тоді як Salesforce.com оновлює всіх одночасно в власний час вибираючи. [ОНОВЛЕННЯ додано 18 червня: я дізнався, що це неправильно. Intacct оновлює всіх своїх клієнтів одночасно, тому він ближчий до моделі Salesforce.com, ніж я уявляв — див. Чому мультиоренда має значення.]
Oracle та інші: низький ступінь багатокористування. Існує багато термінів для цих нижчих рівнів багатоквартирної оренди, включаючи ізольовану оренду, мега-оренду або гібридну оренду. Багато пуристів будуть обурені тим, що я навіть продовжую використовувати термін мультиоренда для цього типу впровадження. Існує багато варіацій, але основною характеристикою є відмова від принципу спільної схеми. Існує ще певний елемент інфраструктури спільного сервера, але кожен кластер серверів (Oracle називає їх «стручками») налаштований дещо інакше, ніж наступний. Хоча це полегшує тонке налаштування кожної стручки відповідно до різних потреб клієнтів за допомогою звичайного процесів налаштування, це додає надзвичайної складності під час координації розгортання нових випусків програмного забезпечення — як SAP нещодавно відкритий за допомогою проекту Business ByDesign.
Це не лише процес оновлення, який отримує переваги від консолідації, яку можна досягти у величезних масштабах, що забезпечується моделлю Salesforce.com із користуванням кількома орендарями найвищого рівня. Це значно полегшує моніторинг продуктивності додатків і, таким чином, покращує такі аспекти, як безпека, доступність, час відгуку та інші характеристики якості послуг. Також набагато легше збирати сукупні дані про поведінку клієнтів і встановлювати контрольні показники для найкращої практики. Нарешті, інтеграція є простішою для спільної внутрішньої інфраструктури, такої як системи керування ідентифікацією, API та інтерфейси до сторонніх служб. Чим більше кластерів має постачальник і чим більше варіацій між кластерами, тим більше проміжного програмного забезпечення та програмного забезпечення для керування йому доведеться придбати.
Можливо, тому Oracle любить просувати модель із кількома капсулами — особливо на менших рівнях спільної оренди, де проблеми управління та нагляду зростають експоненціально — Oracle не тільки отримує можливість продавати багато ліцензій на базу даних, але також багато ліцензій на різні продукти технологічної інфраструктури.
Пуристи стверджують, що, навіть якщо в принципі ви готові заплатити витрати на керування кількома впровадженнями, настає момент, коли так багато змінних, що технічно неможливо забезпечити той самий рівень контролю, якого вони досягають за допомогою великомасштабної спільної схеми екземпляри. У довгостроковій перспективі це означає, що їхня продуктивність, безпека та надійність настільки випереджатимуть своїх конкурентів, що їхня модель переможе.
Набагато більша кількість постачальників SaaS віддає перевагу дещо більш гібридній моделі, яку дотримується Intacct, або для того, щоб скористатися перевагами стандартного апаратного забезпечення, або для того, щоб надати певну кількість клієнтів гнучкість під час впровадження оновлень (що є більшою проблемою для транзакційних програм, таких як фінанси, ніж для програм керування даними, таких як відділ продажів автоматизація). [ОНОВЛЕННЯ: щоб дізнатися більше про це, перегляньте наступну публікацію, Чому мультиоренда має значення.]
Проте обидва табори погоджуються щодо принципу спільної схеми. Їхні погляди розходяться навколо реалізації мультитенантності спільної схеми. Будь-яка менша форма мультиорендування — наприклад, спільні сервери додатків, але житло дані кожного клієнта в окремо настроюваних екземплярах бази даних — це зовсім інша архітектура. Попереджаємо: у світі SaaS удавати або припускати протилежне може спричинити образу.