К сожалению, у этого термина нет хорошего русскоязычного аналога. «Википедия» дает перевод «мультиарендность, множественная аренда». Иногда это называют «множественным владением». Эти термины могут несколько путать, так как предмет не связан по сути ни с арендой, ни с владением. Это вопрос именно архитектуры программного обеспечения и организации его эксплуатации. Причем последнее не менее важно.
Мы начали формировать наше понимание multitenancy одновременно с тем, как начали проектировать подход к облачной (сервисной) модели работы «1С:Предприятия». Это было несколько лет назад. И с тех пор наше понимание постоянно расширяется. Мы постоянно обнаруживаем у этого предмета все новые и новые аспекты (плюсы, минусы, сложности, особенности и т.п.).
Иногда разработчики понимают под multitenancy вполне простой предмет: «чтобы данные нескольких организаций хранились в одной базе, нужно добавить во все таблицы колонку с идентификатором организации и установить по ней фильтр». Мы тоже, конечно, начали свою проработку вопроса с этого момента. Но достаточно быстро поняли, что это только одна полянка (тоже, кстати, непростая). А вообще это «целая страна».
Основную идею multitenancy можно описать примерно так. Обычное приложение – это коттедж, рассчитанный на проживание одной семьи, которая пользуется его инфраструктурой (стены, крыша, водоснабжение, отопление и т.п.). А multitenancy-приложение – это многоквартирный дом. В нем каждая семья пользуется таким же составом инфраструктуры, но сама инфраструктура реализована для всего дома целиком.
А подход multitenancy – это хорошо или плохо? На это можно найти очень разные мнения. Представляется, что нет «хорошо или плохо» вообще. Сравнивать нужно плюсы и минусы в контексте конкретных решаемых задач. Но это отдельная тема…
В простейшем понимании цель multitenancy – снизить расходы на поддержание приложения за счет «обобществления» расходов на инфраструктуру. Это такое же движение, как снижение стоимости приложения за счет применения тиражного решения (возможно, с настройкой и доработкой), а не написание «под заказ». Только в одном случае обобществляется разработка, а в другом – эксплуатация.
Причем, повторимся, тут нет прямой завязки на способ продажи. Архитектура multitenancy может вполне применяться и в корпоративной или ведомственной IT-инфраструктуре для автоматизации большого числа однотипных филиалов, предприятий холдинга.
Можно сказать, что multitenancy – это не просто вопрос организации хранения данных. Это модель работы приложения целиком (включая и существенную часть аспектов его архитектуры, и модель развертывания, и организацию обслуживания).
Самое сложное и интересное в модели multitenancy как нам кажется, что суть приложения «раздваивается». Часть функциональности работает с конкретными областями данных (квартирами) и «не интересуется» тем, что есть жильцы в других квартирах. А часть воспринимает дом целиком и работает сразу для всех жильцов. При этом последняя не может абстрагироваться от того, что все-таки это отдельные квартиры, и нужно обеспечивать необходимый уровень гранулярности и безопасности.
В «1С:Предприятии» модель multitenancy реализуется на уровне нескольких технологий. Это механизмы платформы «1С:Предприятия», механизмы «1С:Технология публикации решений 1cFresh» и «1С:Технология разработки решений 1cFresh», механизмы БСП (библиотеки стандартных подсистем).
Каждый из этих предметов вносит свой вклад в построение общей инфраструктуры многоквартирного дома. Почему это реализуется в нескольких технологиях, а не в одной, например, в платформе? Прежде всего потому, что часть механизмов, по нашему мнению, вполне уместно модифицировать при конкретном варианте развертывания. Но в общем виде это непростой вопрос, и мы постоянно становимся перед выбором – на каком уровне лучше реализовывать тот или иной аспект multitenancy.
Очевидно, что базовую часть механизмов требовалось реализовать в платформе. Ну, например, собственно разделение данных. То, с чего обычно начинают разговор про multitenancy. Но в итоге модель multitenancy «проехалась» по существенной части механизмов платформы и потребовала их доработки, а в некоторых случаях и переосмысления.
На уровне платформы мы реализовали именно базовые механизмы. Они позволяют создавать приложения, работающие в модели multitenancy. Но чтобы приложения «жили и работали» в такой модели, нужно иметь систему управления их «жизнедеятельностью». За это отвечают технологии 1cFresh и унифицированный слой бизнес-логики на уровне БСП. Так же как в многоквартирном доме инфраструктура обеспечивает жильцов всем необходимым, так и технологии 1cFresh обеспечивают всем необходимым приложения, работающие в multitenancy модели. А чтобы приложения могли взаимодействовать с этой инфраструктурой (без существенных доработок), в них помещаются соответствующие «разъемы» в виде подсистем БСП.
С точки зрения механизмов платформы легко заметить, что по мере получения опыта и развития облачного варианта использования «1С:Предприятия» мы расширяем состав механизмов, которые вовлечены в эту архитектуру. Приведем один пример. В модели multitenancy существенно меняется расстановка ролей участников обслуживания приложений. Существенно повышается роль (уровень ответственности) тех, кто отвечает за эксплуатацию приложений. Им стало необходимо иметь более мощные инструменты контроля приложений. Потому что пользователи приложений (жильцы) доверяют прежде всего провайдеру, с которым они работают. Для этого мы реализовали в версии 8.3 новый механизм профилей безопасности. Этот механизм позволяет администраторам провайдера ограничить свободу разработчиков приложений необходимым уровнем безопасности – по сути, изолировать работу приложения для каждого жильца в определенных рамках «песочницы» (sandbox).
Ничуть не меньший интерес представляет собой архитектура для управления приложениями, работающими в режиме multitenancy (то, что реализуется в технологиях 1cFresh и БСП). Здесь, по сравнению с обычной моделью развертывания, существенно повышаются требования к автоматизации процессов управления. Таких процессов десятки: создание новых областей данных («квартир»), обновление приложений, обновление нормативной информации, резервное копирование и т. д. И, конечно, возрастают требования к уровню надежности и доступности. Например, для обеспечения надежного взаимодействия приложений с компонентами системы управления мы реализовали технологию асинхронной системы вызовов с гарантированной доставкой.
Очень тонким моментом является способ обобществления данных и процессов. Простым это кажется (если кому-то кажется) только на первый взгляд. Наибольшую сложность представляет баланс между централизацией данных и процессов и децентрализацией. С одной стороны, централизация позволяет уменьшить расходы (дискового пространства, ресурсов процессора, усилий администраторов…). С другой стороны, ограничивает свободу «жильцов». Это как раз один из моментов «раздваивания» приложения, когда разработчику нужно думать одновременно про приложение в узком смысле (обслуживающее одну «квартиру») и в широком смысле (обслуживающее сразу всех «жильцов»).
Как пример такой «дилеммы» можно привести нормативно-справочную информацию. Разумеется, велик соблазн сделать ее общей для всех «жильцов» дома. Это позволяет и хранить ее в одном экземпляре, и обновлять сразу для всех. Но бывает так, что какому-то жильцу необходимы специфические изменения. Как ни странно, но на практике это встречается, даже для информации, которая специфицирована регуляторами (государственными органами). Получается непростой вопрос: обобществлять или не обобществлять? Заманчиво, конечно, сделать общую информацию для всех и частную для желающих. А это уже ведет к совсем непростой реализации. Но над этим мы работаем…
Еще одним примером является проектирование реализации регулярных процессов (выполняемых по расписанию, инициируемых управляющей системой и т.п.). С одной стороны, их можно реализовать для каждой области данных отдельно. Это проще и удобнее. Но, с другой стороны, такая мелкая гранулярность создает большую нагрузку на систему. Чтобы снизить нагрузку, нужно реализовывать обобществленные процессы. Но они требуют более тщательной проработки.
Разумеется, напрашивается весьма существенный вопрос. А как разработчикам приложений обеспечить работу в режиме multitenancy? Что им нужно для этого делать? Конечно, мы стремимся к тому, чтобы тяжесть технологических и инфраструктурных вопросов максимально ложилась на плечи поставляемой технологии, а разработчик приложения думал бы только в задачах бизнес-логики. Но как и с другими важными архитектурными вопросами, какое-то представление о работе в модели multitenancy разработчикам приложений иметь нужно и какие-то усилия при разработке приложений потребуются. Почему? Потому что есть моменты, которые технология не может обеспечить автоматически без учета семантики данных. Например, то же определение границ обобществления информации. Но мы стараемся, чтобы эти сложности были небольшими. Примеры реализации таких приложений уже есть.
Важным моментом в контексте реализации multitenancy в «1С:Предприятии» является то, что мы создаем гибридную модель, в которой одно приложение может работать и в режиме multitenancy, и в обычном режиме. Это весьма непростая задача и предмет отдельного обсуждения.
Мы начали формировать наше понимание multitenancy одновременно с тем, как начали проектировать подход к облачной (сервисной) модели работы «1С:Предприятия». Это было несколько лет назад. И с тех пор наше понимание постоянно расширяется. Мы постоянно обнаруживаем у этого предмета все новые и новые аспекты (плюсы, минусы, сложности, особенности и т.п.).
Иногда разработчики понимают под multitenancy вполне простой предмет: «чтобы данные нескольких организаций хранились в одной базе, нужно добавить во все таблицы колонку с идентификатором организации и установить по ней фильтр». Мы тоже, конечно, начали свою проработку вопроса с этого момента. Но достаточно быстро поняли, что это только одна полянка (тоже, кстати, непростая). А вообще это «целая страна».
Основную идею multitenancy можно описать примерно так. Обычное приложение – это коттедж, рассчитанный на проживание одной семьи, которая пользуется его инфраструктурой (стены, крыша, водоснабжение, отопление и т.п.). А multitenancy-приложение – это многоквартирный дом. В нем каждая семья пользуется таким же составом инфраструктуры, но сама инфраструктура реализована для всего дома целиком.
А подход multitenancy – это хорошо или плохо? На это можно найти очень разные мнения. Представляется, что нет «хорошо или плохо» вообще. Сравнивать нужно плюсы и минусы в контексте конкретных решаемых задач. Но это отдельная тема…
В простейшем понимании цель multitenancy – снизить расходы на поддержание приложения за счет «обобществления» расходов на инфраструктуру. Это такое же движение, как снижение стоимости приложения за счет применения тиражного решения (возможно, с настройкой и доработкой), а не написание «под заказ». Только в одном случае обобществляется разработка, а в другом – эксплуатация.
Причем, повторимся, тут нет прямой завязки на способ продажи. Архитектура multitenancy может вполне применяться и в корпоративной или ведомственной IT-инфраструктуре для автоматизации большого числа однотипных филиалов, предприятий холдинга.
Можно сказать, что multitenancy – это не просто вопрос организации хранения данных. Это модель работы приложения целиком (включая и существенную часть аспектов его архитектуры, и модель развертывания, и организацию обслуживания).
Самое сложное и интересное в модели multitenancy как нам кажется, что суть приложения «раздваивается». Часть функциональности работает с конкретными областями данных (квартирами) и «не интересуется» тем, что есть жильцы в других квартирах. А часть воспринимает дом целиком и работает сразу для всех жильцов. При этом последняя не может абстрагироваться от того, что все-таки это отдельные квартиры, и нужно обеспечивать необходимый уровень гранулярности и безопасности.
В «1С:Предприятии» модель multitenancy реализуется на уровне нескольких технологий. Это механизмы платформы «1С:Предприятия», механизмы «1С:Технология публикации решений 1cFresh» и «1С:Технология разработки решений 1cFresh», механизмы БСП (библиотеки стандартных подсистем).
Каждый из этих предметов вносит свой вклад в построение общей инфраструктуры многоквартирного дома. Почему это реализуется в нескольких технологиях, а не в одной, например, в платформе? Прежде всего потому, что часть механизмов, по нашему мнению, вполне уместно модифицировать при конкретном варианте развертывания. Но в общем виде это непростой вопрос, и мы постоянно становимся перед выбором – на каком уровне лучше реализовывать тот или иной аспект multitenancy.
Очевидно, что базовую часть механизмов требовалось реализовать в платформе. Ну, например, собственно разделение данных. То, с чего обычно начинают разговор про multitenancy. Но в итоге модель multitenancy «проехалась» по существенной части механизмов платформы и потребовала их доработки, а в некоторых случаях и переосмысления.
На уровне платформы мы реализовали именно базовые механизмы. Они позволяют создавать приложения, работающие в модели multitenancy. Но чтобы приложения «жили и работали» в такой модели, нужно иметь систему управления их «жизнедеятельностью». За это отвечают технологии 1cFresh и унифицированный слой бизнес-логики на уровне БСП. Так же как в многоквартирном доме инфраструктура обеспечивает жильцов всем необходимым, так и технологии 1cFresh обеспечивают всем необходимым приложения, работающие в multitenancy модели. А чтобы приложения могли взаимодействовать с этой инфраструктурой (без существенных доработок), в них помещаются соответствующие «разъемы» в виде подсистем БСП.
С точки зрения механизмов платформы легко заметить, что по мере получения опыта и развития облачного варианта использования «1С:Предприятия» мы расширяем состав механизмов, которые вовлечены в эту архитектуру. Приведем один пример. В модели multitenancy существенно меняется расстановка ролей участников обслуживания приложений. Существенно повышается роль (уровень ответственности) тех, кто отвечает за эксплуатацию приложений. Им стало необходимо иметь более мощные инструменты контроля приложений. Потому что пользователи приложений (жильцы) доверяют прежде всего провайдеру, с которым они работают. Для этого мы реализовали в версии 8.3 новый механизм профилей безопасности. Этот механизм позволяет администраторам провайдера ограничить свободу разработчиков приложений необходимым уровнем безопасности – по сути, изолировать работу приложения для каждого жильца в определенных рамках «песочницы» (sandbox).
Ничуть не меньший интерес представляет собой архитектура для управления приложениями, работающими в режиме multitenancy (то, что реализуется в технологиях 1cFresh и БСП). Здесь, по сравнению с обычной моделью развертывания, существенно повышаются требования к автоматизации процессов управления. Таких процессов десятки: создание новых областей данных («квартир»), обновление приложений, обновление нормативной информации, резервное копирование и т. д. И, конечно, возрастают требования к уровню надежности и доступности. Например, для обеспечения надежного взаимодействия приложений с компонентами системы управления мы реализовали технологию асинхронной системы вызовов с гарантированной доставкой.
Очень тонким моментом является способ обобществления данных и процессов. Простым это кажется (если кому-то кажется) только на первый взгляд. Наибольшую сложность представляет баланс между централизацией данных и процессов и децентрализацией. С одной стороны, централизация позволяет уменьшить расходы (дискового пространства, ресурсов процессора, усилий администраторов…). С другой стороны, ограничивает свободу «жильцов». Это как раз один из моментов «раздваивания» приложения, когда разработчику нужно думать одновременно про приложение в узком смысле (обслуживающее одну «квартиру») и в широком смысле (обслуживающее сразу всех «жильцов»).
Как пример такой «дилеммы» можно привести нормативно-справочную информацию. Разумеется, велик соблазн сделать ее общей для всех «жильцов» дома. Это позволяет и хранить ее в одном экземпляре, и обновлять сразу для всех. Но бывает так, что какому-то жильцу необходимы специфические изменения. Как ни странно, но на практике это встречается, даже для информации, которая специфицирована регуляторами (государственными органами). Получается непростой вопрос: обобществлять или не обобществлять? Заманчиво, конечно, сделать общую информацию для всех и частную для желающих. А это уже ведет к совсем непростой реализации. Но над этим мы работаем…
Еще одним примером является проектирование реализации регулярных процессов (выполняемых по расписанию, инициируемых управляющей системой и т.п.). С одной стороны, их можно реализовать для каждой области данных отдельно. Это проще и удобнее. Но, с другой стороны, такая мелкая гранулярность создает большую нагрузку на систему. Чтобы снизить нагрузку, нужно реализовывать обобществленные процессы. Но они требуют более тщательной проработки.
Разумеется, напрашивается весьма существенный вопрос. А как разработчикам приложений обеспечить работу в режиме multitenancy? Что им нужно для этого делать? Конечно, мы стремимся к тому, чтобы тяжесть технологических и инфраструктурных вопросов максимально ложилась на плечи поставляемой технологии, а разработчик приложения думал бы только в задачах бизнес-логики. Но как и с другими важными архитектурными вопросами, какое-то представление о работе в модели multitenancy разработчикам приложений иметь нужно и какие-то усилия при разработке приложений потребуются. Почему? Потому что есть моменты, которые технология не может обеспечить автоматически без учета семантики данных. Например, то же определение границ обобществления информации. Но мы стараемся, чтобы эти сложности были небольшими. Примеры реализации таких приложений уже есть.
Важным моментом в контексте реализации multitenancy в «1С:Предприятии» является то, что мы создаем гибридную модель, в которой одно приложение может работать и в режиме multitenancy, и в обычном режиме. Это весьма непростая задача и предмет отдельного обсуждения.
