К сожалению, у этого термина нет хорошего русскоязычного аналога. «Википедия» дает перевод «мультиарендность, множественная аренда». Иногда это называют «множественным владением». Эти термины могут несколько путать, так как предмет не связан по сути ни с арендой, ни с владением. Это вопрос именно архитектуры программного обеспечения и организации его эксплуатации. Причем последнее не менее важно.
Мы начали формировать наше понимание 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, и в обычном режиме. Это весьма непростая задача и предмет отдельного обсуждения.
Поделиться с друзьями
Комментарии (22)
PeterG
18.04.2017 12:15Например здесь (используется продукт 1cFresh).
А вот про пример использования 1cFresh внутри большой организации (ДИТ Москвы) — новость «Переход на облачную ERP сэкономил Москве миллионы рублей», официальное письмо от ДИТ Москвы.
Catolampius
18.04.2017 13:33какие условия получения продукта 1cFresh для коммерческих организаций не занимающихся франчайзингом 1с? для собственных нужд, но интересует больше не сам продукт(его бери да купи), а поддержка и инструментарий как у Кнопки.
PeterG
18.04.2017 13:39«А мы покупаем или продаём?» :)
Поддержку и инструментарий как у Кнопки — вы хотите получать или сами оказывать своим клиентам?
Azuregosa
18.04.2017 12:44По поводу термина: Microsoft предлагает перевод «мультитенантность» или описательное «архитектура обслуживания одним экземпляром приложения нескольких развертываний».
Мне сначала термин «мультитенантность» показался неудачным, но на самом деле он оказывается лучшим вариантом: ведь, как сказано в начале статьи, «мультиарендность» и «множественное владение» неточны.
yukon39
18.04.2017 14:01Для «песочниц» используете штатные возможности ОС изоляции (процессы/потоки) и/или собственные механизмы?
PeterG
18.04.2017 16:14Используем собственные механизмы. В основном потому, что настройки, используемые в наших профилях безопасности — application-specific, и ОС про них ничего не знает.
gearbox
18.04.2017 16:38половина из того что описано в примерах в русском языке называется греческим заимствованием синергия. (не грамар наци, да и вообще не русский, просто мешает пониманию, когда ты читаешь примеры, четко попадающие под уже известную абстракцию а тебе их называют новым неизвестным словом которое ты пытаешься понять а в итоге оказывается что тебе просто неправильно объясняли/неудачно подобрали примеры)
teleghost
18.04.2017 19:22для слова multitenancy действительно нет хорошего перевода, приходится либо использовать англицизм «в лоб», либо использовать «мультиарендный» (потому что многоквартирный, многозадачный, многопользовательский, мультисервисный уже заняты); впрочем, я не знаю всех вариантов, с удовольствием бы услышал предложения
teleghost
18.04.2017 20:09+2простите, о наболевшем
Мы начали формировать наше понимание multitenancy одновременно с тем, как начали проектировать подход к облачной (сервисной) модели работы «1С: Предприятия». Это было несколько лет назад.
А в вашем организационном понимании есть пункт о желательности Linux/Postgres для облачных (сервисных) моделей вместо Microsoft Windows/SQL? Потому что те ребята, которые меня консультировали, вообще не рекомендовали использовать Linux и Postgres, ссылаясь на проблемы с производительностью. Что это — реальная проблема или плохое информирование торговой сети?Боюсь даже заикаться про FreeBSD и официальную совместимость файлового backend'а с samba.
Т.н. «отраслевые» решения требуют аж двух аппаратных USB-ключей. Многие способны паковать гирлянды USB-ключей в корпуса с помощью специальных адаптеров, но это всё равно дико неудобно. Аппаратные USB-ключи с облачными продуктами сочетаются плохо, промышленная виртуализация вообще не любит USB, это блокирует автоматическое перемещение машин (контейнеров) между физическими хостами в случае отказа последних. Варианты типа AnywhereUSB — тоже точка отказа и та ещё заноза, ни о каком multitenancy речь не идёт.
Таких процессов десятки: создание новых областей данных («квартир»), обновление приложений, обновление нормативной информации, резервное копирование и т. д.
Ага, попробовал тут давеча через командную строку вызвать конфигуратор на выгрузку, не засвечивая пароль сервисной (привилегированной) учётной записи. Перепробовал с десяток способов использовать аргумент/@ <имя файла>, но всё без толку, не берёт пароль и всё. Плюнул, забил пароль открытым текстом. Либо я полный утюг, либо интерфейс командной строки Предприятия застрял в конце 90-х годов…
Облачно-сервисная модель предполагает мощный интерфейс командной строки и сетевой API (например, REST API). Чтобы не светить пароль в командной строке, современные утилиты дают возможность считать его через конвейер (pipe, file handle), либо хотя бы просто из файла.PeterG
19.04.2017 16:42А в вашем организационном понимании есть пункт о желательности Linux/Postgres для облачных (сервисных) моделей вместо Microsoft Windows/SQL?
Да, конечно. И не только пункт есть, но и на практике применяем и сами («Для собственных нужд «1С» также использует открытую СУБД, PostgreSQL, которая (наряду с MS SQL) используется в облачном сервисе 1С:Fresh, функционирующем с 2012 года.»), и наши партнеры.
Потому что те ребята, которые меня консультировали, вообще не рекомендовали использовать Linux и Postgres, ссылаясь на проблемы с производительностью. Что это — реальная проблема или плохое информирование торговой сети?
Может быть — нежелание «ребят» учиться новому?
Аппаратные USB-ключи с облачными продуктами сочетаются плохо
Согласен. В этом случае лучше использовать программные лицензии.
Перепробовал с десяток способов использовать аргумент /@ <имя файла>, но всё без толку, не берёт пароль и всё.
Пробовали каждый параметр в файле размещать на новой строке?teleghost
19.04.2017 21:46во-первых, благодарю за ответ о наболевшем, я тогда ещё поделюсь мыслями с Вашего позволения…
Может быть — нежелание «ребят» учиться новому?
Может, и так. Но если ваш департамент по работе с торговой сетью проводит регулярное анкетирование или учебную аттестацию, добавьте вопросы по теме выбора платформ. Сможете увидеть реальную картину, и, если она отличается от желаемой, проведёте кампанию по информированию торговых партнёров. Даю готовые примеры.
примеры вопросов1. На какой платформе достигается лучшая производительность при работе Предприятия?
A. Microsoft Windows Server и СУБД SQL Server
B. Поддерживаемый сервер Linux и СУБД MySQL
C. Поддерживаемый сервер Linux и СУБД PostgreSQL
D. Поддерживаемый сервер Linux и СУБД Oracle
E. Любой из вариантов A или B.
F. Любой из вариантов A или C.
G. Любой из вариантов A или D.
2. Какую платформу Вы порекомендуете заказчику, если не стоит вопрос с лицензиями?
A. Microsoft Windows Server
B. Microsoft Windows Professional
D. Сервер Linux с платной поддержкой
D. Cервер Linux с бесплатной (community) поддержкой
E. Ничего из вышеперечисленного
Примечание: варианты содержат distractor'ы, т.е. неверные ответы.PeterG
20.04.2017 15:01Большое спасибо за подробную информацию, познавательно.
По поводу отраслевых решений и программных лицензий — насколько знаю, сейчас новые версии отраслевых почти все умеют работать с программными лицензиями, мы специально работаем над этим. У вас были проблемы с конкретным отраслевым решением?
1C:Fresh — это отлично, но если распространять франшизу дальше, то методы работы с операторами и брокерами облачного доступа существенно отличаются от привычных моделей торговой сети.
Можете развить? В какую сторону отличаются, в какую сторону рекомендуете двигаться.teleghost
20.04.2017 19:15У вас были проблемы с конкретным отраслевым решением?
Да, но об этом лучше в личной переписке.
Можете развить? В какую сторону отличаются, в какую сторону рекомендуете двигаться.
DISCLAIMER: я не BDM:)
диванная аналитикаОператоры облачных услуг — прежде всего владельцы инфраструктуры и автоматизированных технологических процессов. Сфера деятельности весьма близка к телекому (и традиционному веб-хостингу). У операторов весьма прокачанные службы эксплуатации. Операторы фокусируются на стандартизации и автоматизации, выручка генерируется массовой продажей типовых решений по модели подписки (аренды), но без глубокого погружения в нужды и проблемы каждого заказчика. Оператор услуг отвечает, прежде всего, по всевозможным SLA, за несоблюдение которых идут штрафы. Важен анализ утилизации (использования) инфраструктуры, планирование и развитие. Если продукт ориентирован на бизнес, есть отдел продаж и сейлы, работающие с корпоративными заказчиками. Если продукт потребительский, продажи генерирует маркетинг в разных формах. Но, повторяю, выручка генерируется по рентной модели: лучше каждый год получать по 50р, чем один раз продать лицензию за 100р и потом продлевать поддержку за 30р.
Ваших франчайзи Вы знаете лучше меня. Полагаю, у них нет ни инфраструктуры, ни серьёзных групп эксплуатации, ни SLA, только размытые обязательства по ответу на запросы в рамках программ техподдержки. Выручка идёт от продажи продуктов и профессиональных услуг по их внедрению, но по принципу один раз 100р и потом каждый год 30р. Соответственно, в штате есть специалисты по внедрению и платформам, но от Windows/Linux/SQL они абстрагируются. Отделы продаж у франчайзи, на мой взгляд, единственное похожее звено на операторские отделы по работе с бизнесом. Про маркетинг ничего определённого сказать не могу.
Мне кажется, что у крупных операторов есть мощные инфраструктурные и маркетинговые ресурсы, но им неинтересно заниматься внедрением 1С, это семечки. Обычным же франчайзи очень тяжело стать операторами, им проще взять инфраструктуру в аренду, занимаясь тем же самым, что и раньше. Но если 1С нужно нарастить долю рынка, возможно, имеет смысл пойти к крупным игрокам и продавать эту идею им, готовясь значительную часть работы взять на себя. Придётся либо закрыться на коробочных продуктах, либо как-то восполнять подгонку под требования заказчиков. В любом случае нужно будет контролировать удовлетворённость конечных закзачиков всей цепочкой в целом. Продукт наверняка придётся допиливать (я уже обозначал, где именно, и про функции CASB не шутил, хотя это относительно новая ниша даже в мировом масштабе).
Вот вам и синергия: сочетание возможностей операторов инфраструктуры и желания франчайзи работать с заказчиками индивидуально.
Думаю, что кассовая реформа м.б. хорошим драйвером развития такого бизнеса: дескать, фискальные данные продаж и так уже отправляются в сеть, так чего теперь бояться? Правда, шансы не успеть весьма велики:)PeterG
20.04.2017 19:19Да, но об этом лучше в личной переписке.
ОК! Пишите в личку.
И спасибо за развернутый ответ.
teleghost
19.04.2017 22:04Перепробовал с десяток способов использовать аргумент /@ <имя файла>
Пробовали каждый параметр в файле размещать на новой строке?
да, в том числе так:
подробности"C:\Program Files\1Cv8\common\1cestart.exe" CONFIG /@ E:\1C\cred.txt /F E:\1C\ENTERPRISE /DumpIB \\server\backup\share
файлE:\1C\cred.txtиз двух строк:
/N sysuser
/P very-secret-password
появляется окошко со вводом логина и пароля до тех пор, пока я не затащу явно /N и /P в командную строку,
пользователь и пароль те же, само собой.softilium
19.04.2017 17:09Для лицензирования можно использовать программные лицензии, расположенные на отдельном хосте. Например, на физическом копьютере, который доступен рабочим серверам по сети.
Linux и Postgres поддерживаются для работы. Попробуйте обратиться за разъяснением к консультантам, которые дали Вам такую рекомендацию.
Вопросы по командной строке, в которой критично «не светить пароль», не совсем ясны. Вроде бы любая работа с серверами из командной строки должна происходить только из trusted окружения. Я ошибаюсь?teleghost
19.04.2017 22:16Для лицензирования можно использовать программные лицензии, расположенные на отдельном хосте. Например, на физическом копьютере, который доступен рабочим серверам по сети.
Для оператора облачного сервиса, связанного SLA, риск отказа такого выделенного хоста с ключами может означать конец бизнеса и практически неприемлем. Как я уже ответил в комментарии выше, т.н. отраслевые конфигурации (форки «управления небольшой фирмой», неплохие коробочные решения) по любому требуют «катрановский» аппаратный ключ, без вариантов. Поправьте, если не так.
Вопросы по командной строке, в которой критично «не светить пароль», не совсем ясны. Вроде бы любая работа с серверами из командной строки должна происходить только из trusted окружения. Я ошибаюсь?
Речь идёт о запланированном по расписанию задании. Промышленный сервер, хостящий облачные сервисы, обслуживается не одним человеком, а группой с чётко поставленными ролями, и далеко не всем полагается видеть пароли. Имя процесса и аргументы командной строки слишком легко подсмотреть стандартными системными утилитами, обладая минимальными правами юзера, поэтому современный софт принципиально избегает задания пароля в командной строке. Да и компрометация (взлом) сервера — явление сейчас настолько обыденное, что понятие trusted окружения очень условно и размыто.
спасибо
teleghost
20.04.2017 01:38да, и ни одна серьезная аудиторская проверка не допустит пароли в открытом виде в принципе, т.е. такой сервис априори нелегальный
andrewev
Идея «многоквартирного дома» для пользователей очень хорошая — в плане устойчивости и стоимости ведения «хозяйства жкх». Хотелось бы в дальнейшем получить примеры экономии «жильцов» этого «дома» на сопровождении своих баз и на отсутствии проблем. Желательно в цифрах. Заранее спасибо.