Согласен, Zextras Carbonio действительно неплохой вариант, также как и Zimbra.
Однако надо понимать масштабы и требования. Если ставить Community-версии этих продуктов, то у них достаточно много ограничений. Коммерческую версию Carbonio, насколько я знаю, можно купить, но в реестр отечественного ПО продукт не входит, что может стать дополнительным ограничением для некоторых заказчиков.
Для варианта setup-next-next-next RuPost подходит очень неплохо. Достаточно базовых знаний Linux, чтобы развернуть standalone-вариант. Даже кластер в самом простом варианте разворачивается несложно, но нужно понимать, что инфраструктура существует не в вакууме. Грамотно настроенный Exchange тоже не так-то просто установить.
Согласен с этими замечаниями. Действительно, при планировании архитектуры решения у заказчика их нужно учитывать. Если необходимость отказоустойчивости сервиса Memcached под вопросом и зависит от ряда факторов (например, отказ этой службы практически не несёт рисков в случае использования клиентов RuPost Desktop или Thunderbird), то отказоустойчивость кластера PostgreSQL крайне важна. Как правило, это решается кластером PostgreSQL + Patroni + ETCD.
Как раз вчера вышла новая версия RuPost, где реализован механизм работы с кластером СУБД.
Мы начали активно тестировать новую функциональность.
К сожалению, функциональность календарей пока не такая обширная, как привыкли сотрудники большинства компаний. Однако точно есть запрос бизнеса, и вендоры понимают, что нужно дорабатывать и добавлять функциональность в свои решения. Open source-решения, которые лежат под капотом большинства импортонезависимых систем, таким похвастаться не могут, поэтому есть преимущество в вендорских решениях (хотя и недостатков тоже хватает).
Думаю что нужно принять как данность, что нужны специалисты с компетенциями по *nix-системам. Компетенции по продуктам MS в целом и Exchange в частности тоже не сразу набирались.
Согласен, что не всем необходимо с места в карьер менять Exchange на что-то ещё, но в текущих реалиях бывают ситуации, когда заказчики вынуждены выбирать альтернативные решения.
Согласен, Zextras Carbonio действительно неплохой вариант, также как и Zimbra.
Однако надо понимать масштабы и требования. Если ставить Community-версии этих продуктов, то у них достаточно много ограничений. Коммерческую версию Carbonio, насколько я знаю, можно купить, но в реестр отечественного ПО продукт не входит, что может стать дополнительным ограничением для некоторых заказчиков.
1. Пользователи могут делегировать свои календари.
2. Есть сущность «Переговорная комната», которая может автоматически принимать и показывать занятость.
3. Тут функциональность может быть ограниченf. Точно есть списки рассылки во всех системах.
4. В CommuniGate и VK такая функциональность есть. В RuPost нет из коробки, но возможны варианты на уровне проекта.
5. Зависит от бизнес-сценария. В целом, возможность управлять транспортными правилами есть, но в некоторых системах она сильно «под капотом».
6. Вот этой функциональности пока нет в системах.
Для варианта setup-next-next-next RuPost подходит очень неплохо. Достаточно базовых знаний Linux, чтобы развернуть standalone-вариант. Даже кластер в самом простом варианте разворачивается несложно, но нужно понимать, что инфраструктура существует не в вакууме. Грамотно настроенный Exchange тоже не так-то просто установить.
Согласен с этими замечаниями. Действительно, при планировании архитектуры решения у заказчика их нужно учитывать. Если необходимость отказоустойчивости сервиса Memcached под вопросом и зависит от ряда факторов (например, отказ этой службы практически не несёт рисков в случае использования клиентов RuPost Desktop или Thunderbird), то отказоустойчивость кластера PostgreSQL крайне важна. Как правило, это решается кластером PostgreSQL + Patroni + ETCD.
Как раз вчера вышла новая версия RuPost, где реализован механизм работы с кластером СУБД.
Мы начали активно тестировать новую функциональность.
К сожалению, функциональность календарей пока не такая обширная, как привыкли сотрудники большинства компаний. Однако точно есть запрос бизнеса, и вендоры понимают, что нужно дорабатывать и добавлять функциональность в свои решения. Open source-решения, которые лежат под капотом большинства импортонезависимых систем, таким похвастаться не могут, поэтому есть преимущество в вендорских решениях (хотя и недостатков тоже хватает).
Думаю что нужно принять как данность, что нужны специалисты с компетенциями по *nix-системам. Компетенции по продуктам MS в целом и Exchange в частности тоже не сразу набирались.
Согласен, что не всем необходимо с места в карьер менять Exchange на что-то ещё, но в текущих реалиях бывают ситуации, когда заказчики вынуждены выбирать альтернативные решения.