Плюсы:
1. не нужна лицензия (экономия бабла);
2. не нужен сервер (экономия бабла);
3. не нужно апгрейдить на нём УКМ при накатывании новой версии/сервис-пака (экономия времени: существенный плюс при обновлении всей системы УКМ на СГО и всех кассах за одну ночь - теоретически достижима неограниченная масштабируемость);
4. не нужно обслуживать сервер и БД (быкап). (Который в случае дизастера надо поднимать из быкапа изолированно от касс, синхронизировать сначала с СГО, затем с кассами, дополнительно "подружив" журналы версий изменений данных).
В общем, как бы снижение стоимости владения - самой важной характеристики эффективности работы IT департмента.
Минусы:
1. количество условных каналов связи между СГО и кассами становится равным количеству касс в магазине, помноженному на три (ukmserver-канал между СГО и СМ и два MySQL-каналы - на IN и на OUT. А ещё бывают отдельные каналы на всякие онлайн-сервисы: подарочные карты, системы лояльности и т.п.). Плюс к этому вылезают "внутренние" каналы (контроль остатков, например). В общем, быть готовым к тому, что на СГО кроме ukmservice и apache2ukm больше ничего не будет работать - никакие серверы прайсчекеров, печати кассовых документов, транспорта данных и т.п. Ибо пул TCP/IP будет в дефиците;
2. товары, цены и весы теперь грузятся с СГО - возрастает нагрузка на интернет-канал;
3. из п.1 и п.2 так же следует, что существенно возрастает нагрузка на БД СГО. Высокопроизводительный storage, поиск оптимальных настроек MySQL. Необходимость поиска оптимальных настроек "Резерв каналов на экспорт/импорт". Цикл прогрузки данными всех касс увеличивается до нескольких минут (то есть, например, одноразовые дисконтные карты и суммовые купоны гасятся на всех кассах не сразу). В функционале "Клиенты" рекомендовано отказаться о репликации балансов карт - только "запросом к серверу".
4. перезаливка кассы в магазине требует ухищрений для скачивания дистрибутива кассы, например, использование http сервера на соседней кассе или поднимать локальный PXE сервер. Саму флешку, в принципе, можно залить на любом компе директора/зама/охранника;
5. перезалитая в магазине касса существенно дольше прогружает товары, цены, клиенты и их карты, дисконтные карты, стоп-листы и т.п. Выручает ухищрение типа заливки БД на виртуальной кассе в офисе, её архивирование 7z и пересылка по http на кассу в магазин. У нас это занимает максимум три часа на всю процедуру против шести часов прогрузки традиционным способом.
6. Ну и обновление касс несколько сложнее происходит: предварительная загрузка обновлений на кассы очередями по несколько касс (не всем скопом), да и после этого не гарантируется, что при запуске обновления скрипты обновления не захотят перезакачать пакеты обновления (напарывался на это неоднократно - тоже свой костыль пришлось сделать против этого).
7. Нагрузка на ЦП СГО по ukmserver и apache2ukm возрастёт: быть готовым к тому, что на СГО кроме ukmservice и apache2ukm больше ничего не будет работать - никакие серверы прайсчекеров, печати кассовых документов, транспорта данных и т.п.
Минусов как бы больше, чем плюсов, но формула расчёта выгоды будет условно такой:
(плюсы * количество СМов) / (минусы * максимальное количество касс в магазине)
С точки зрения управления всем этим кассовым хозяйством схема "СГО-СМ-касса" более правильная. Но становится громоздкой, если касс в магазинах не много. Однозначно схема "СГО-касса" не годится для магазинов, где касс больше четырёх-пяти и если таких магазинов более сотни. Группировка касс в СМы позволяет экономить каналы обмена данными с СГО.
С другой стороны, у "Сервис Плюса" запланированы на этот год работы по исследованию "кластерного решения для СГО", что-нибудь типа объединения нескольких "UKM Object Server" с арбитратором в один "логический" СГО. Ну и со всеми вытекающими новыми плюсами: масштабируемость, отказоустойчивость. А после переноса хранилища БД СГО на какой-нибудь Percona XtraDB Cluster или MariaDB Galera Cluster и работа c "кластером СГО" через HAProxy с распределением нагрузки по нодам кластера БД - и остальные минусы становятся пренебрежимо малыми: повторное скачивание пакетов обновлений поверх предварительно скачанных - пофиксят, а прогрузку касс данными когда-нибудь реализуют с соседней кассы...
О нас:
310 касс в 149 магазинах работают напрямую с СГО. Ещё 37 касс в 16 магазинах пока работают через СМы (переводим кассы на СГО по мере выгорания СМов).
СГО (ukmservice, apache2ukm, транспорт обмена данными между ТС и УКМ): отдельный сервер Win2k8r2, 8 Гб RAM, 24 ядра CPU;
+ отдельно сервер БД (Percona Server 5.6.23-72.1): CentOS 7.0, 32 Гб RAM, 8 ядер CPU, 2 TB storage на SSD-RAID.
Всё это в ЦОДе. Каналы между ЦОД и кассами дублированы (резервированы разными провайдерами), ширина - не менее 1,6 (в подавляющем большинстве - 2) МБит/с. Для различных серверов отчётности, BI, информационных киосков, всяких выгрузок наружу и т.п. используются slave-реплики с БД СГО. Сервер прайс-чекеров, сервер печати кассовых документов - отдельные серверы в офисной серверной, неспешно ждут своего переезда в ЦОД.
В планах: "кластерное решение СГО". В более отдалённой перспективе - "кластерное решение СУБД" (успешно протестировано решение 3-node PXC на стенде с "лабораторной" нагрузкой).