Выбор архитектуры электронной почты: внутренняя или хостинговая

Если поговорить со специалистами по электронной почте, то, по моему небольшому анекдотическому опросу рынка, половина из них скажет вам просто установить почту локально, как правило Microsoft Exchange, а вторая половина – просто перейти на хостинговый (он же Software-as-a-Service / SaaS или “в облаке”) сервис, чаще всего Google Apps. Однако электронная почта – не такой простой архитектурный компонент, чтобы сводить его к банальным ответам. Электронная почта является одним из важнейших компонентов коммуникационной инфраструктуры вашего бизнеса, нередко превосходя по значимости телефонию, и выбор правильной методологии доставки для вашей компании имеет критическое значение для долгосрочного успеха.

Начнём с рассмотрения некоторых базовых факторов при размещении электронной почты. Почтовые системы требуют значительной пропускной способности, весьма существенного объёма хранилища, высокой надёжности, тщательного управления и серьёзных соображений безопасности.

Пропускная способность – первая область для рассмотрения. Каждое отправленное и полученное письмо должно пройти путь между конечным пользователем и почтовым сервером, а также между самим почтовым сервером и внешним миром в случае писем, предназначенных для внешних адресатов. В малом бизнесе почти все письма предназначены для выхода за пределы корпоративной сети – к клиентам, заказчикам, поставщикам и т. д. В крупных предприятиях использование электронной почты меняется: по мере приближения к компаниям уровня Fortune 100 электронная почта из инструмента общения с людьми за пределами организации превращается в платформу, которая используется прежде всего для внутренних коммуникаций.

Этот сдвиг в том, как именно используется электронная почта, является очень важным фактором при принятии решения о развёртывании почтовых сервисов. Если электронная почта используется почти исключительно внутри компании для общения между сотрудниками, это хорошо подходит для размещения почтовых систем внутри организации с целью повышения безопасности и улучшения использования WAN-пропускной способности. Оговорка здесь, конечно, состоит в том, что высокораспределённая компания любого размера не будет удерживать этот трафик в локальной сети, и потому к ней следует относиться так, как будто использование электронной почты является внешним, независимо от того, является ли оно внутрикорпоративным. Малые компании, коммуникации которых происходят преимущественно с внешними пользователями, найдут лучшее применение в хостинговом сервисе.

Хранилище на самом деле часто является меньшим фактором при принятии решений об архитектуре электронной почты, чем могло бы показаться на первый взгляд. Традиционно требования к хранилищу для электронной почты давали убедительный аргумент в пользу внутреннего размещения из-за экономической выгоды хранения больших объёмов данных, особенно используемых для архивных нужд, локально. В последнее время крупные хостинговые провайдеры электронной почты, такие как Rackspace и Google Apps, снизили цену на онлайн-архивное хранилище электронной почты настолько, что во многих случаях использование хостингового хранилища может быть даже более экономически выгодным, чем локальное, или по крайней мере стоимость сопоставима. Даже долгосрочное архивное хранилище сегодня может быть обеспечено очень экономично в рамках хостингового решения.

Надёжность – довольно сложная тема. Электронная почта критически важна для любой организации. Если почтовая система выходит из строя, многие компании просто останавливаются. В некоторых случаях компания фактически прекращает работу, когда перестаёт поступать почта. Не только сотрудники перестают общаться друг с другом, но клиенты, поставщики, партнёры и другие видят компанию как минимум в автономном режиме, а как максимум – вышедшей из бизнеса. Прерывание коммуникаций с внешним миром может немедленно нанести серьёзный финансовый ущерб практически любому бизнесу.

Хостинговая электронная почта имеет очевидное преимущество: она размещается в крупном коммерческом датацентре с резервированием на каждом уровне (при условии вендора верхнего уровня) – от оборудования до хранилища, сети, электроснабжения и поддержки. Размещение электронной почты внутри организации требует от бизнеса определения уровня резервирования, который является наиболее экономически оправданным с учётом способности бизнеса выдержать простой электронной почты, и в целом представляет собой упражнение в компромиссах – сколько надёжности компания может себе позволить не иметь с учётом необходимых затрат на её обеспечение.

Некоторые компании предпочтут размещать почтовые серверы в коллокационном объекте, который обеспечит им многие резервные компоненты, однако для достижения уровня предложений Rackspace или Google, вероятно, потребуется несколько датацентров. Коллокация – это промежуточный вариант, предоставляющий технические возможности хостинговых решений с управляемостью и гибкостью внутренних почтовых систем.

Однако более распространённым сценарием является размещение компаниями единственного почтового сервера полностью внутри своих стен, опираясь на внутреннее электроснабжение, оборудование и сетевое подключение. В таком сценарии компания должна либо принять экстремальные меры для обеспечения работоспособности – например, разместить полностью резервный объект с огромными затратами – либо поставить перед всей своей почтовой инфраструктурой надёжный онлайн-сервис буферизации, такой как Postini, MessageLabs или MXLogic. Стоимость таких сервисов, критически важных для надёжности, необходимой большинству компаний, нередко равна или даже превышает стоимость полного хостинга электронной почты. Затраты на этот сервис буферизации, вероятно, добавят постоянные, масштабируемые расходы, которые сделают полностью хостинговые почтовые сервисы всегда более дешёвым вариантом, чем внутреннее размещение.

Стоимость управления очень сложно определить, но она требует внимания. Полностью хостинговое решение требует относительно небольших технических знаний. Время на управление невелико, и необходимый уровень квалификации относительно низок. При внутреннем решении вашей компании необходимо обеспечить навыки в области инфраструктуры, сети, безопасности, системного администрирования и работы с электронной почтой. В зависимости от ваших потребностей и имеющегося персонала это может быть частичная занятость одного специалиста или потребовать нескольких штатных единиц или даже внешних консультантов. Общее время, необходимое для управления внутренней почтовой системой, будет существенно варьироваться и нередко очень сложно поддаётся расчёту из-за комплексной природы ситуации, однако как минимум оно на порядки превышает время, необходимое для управления хостинговым решением.

Безопасность – последнее значимое соображение. Помимо традиционной безопасности на уровне системы, электронная почта требует фильтрации спама. Борьба со спамом может осуществляться разными способами: программно на почтовом сервере, на устройстве в локальной сети, через аутсорсинг специализированному сервису фильтрации спама или силами провайдера хостинговой почты. Фильтрация спама, если она выполняется внутри организации, редко является услугой, которую достаточно настроить раз и забыть – это сервис, требующий регулярного внимания и, как правило, дополнительных затрат на лицензирование и управление.

Рассмотрев эти основные соображения, каждая компания должна сесть, просчитать цифры и определить, какое решение наиболее подходит именно для неё. Нередко необходимо использовать электронную таблицу и рассмотреть несколько сценариев, чтобы понять, во что обойдётся каждое решение как единовременно, так и со временем. Это, в сочетании с оценкой функций и их применимости к компании, будет критически важным при определении пригодности каждого варианта.

Секретным оружием внутреннего решения являются функциональность, интеграция и гибкость. Внутренние почтовые решения могут быть расширены или модифицированы для обеспечения именно того набора функций, который требуется организации – иногда за дополнительную плату. Прекрасным примером является интеграция мгновенных сообщений в Zimbra, которая может существенно повысить ценность почтовой платформы. Это необходимо учитывать в дополнение к прямым затратам. Важным фактором может быть также интеграция с существующими внутренними механизмами аутентификации.

По моему собственному опыту и расчётам, хостинговые решения представляют подавляющее большинство подходящих решений в сегменте SMB из-за сугубой экономики, тогда как крупные и корпоративные клиенты найдут непреодолимые преимущества в гибкости и коммуникационных возможностях внутренних решений. Малый бизнес в основном борется со стоимостью, тогда как крупный бизнес борется прежде всего с коммуникационной сложностью своего масштаба. Крупные компании также получают наибольшую отдачу от внутренних решений благодаря “профессиональной плотности” – обратному числу ИТ-специалистов, чьё время теряется из-за неэффективностей корпоративного масштаба.

Сегодня независимо от того, решит ли компания размещать собственную электронную почту или получать её как сервис, доступно множество вариантов даже после выбора базовой архитектуры. Традиционно рассматривались лишь немногие внутренние варианты, такие как MS Exchange и Lotus Notes, однако новые альтернативы, в частности Zimbra (недавно приобретённая VMware), Scalix и Kerio, расширяют ландшафт с более низкими затратами, новыми вариантами развёртывания и агрессивными наборами функций. Rackspace – относительный новичок в хостинге и быстро ставший тяжеловесом отрасли – привлекает много внимания своими новыми почтовыми предложениями, которые всё больше имитируют традиционные внутренние предложения, тогда как Google продолжает привлекать внимание своими уникальными сервисами GMail. Я ожидаю, что хостинговый почтовый рынок продолжит становиться всё более конкурентным, причём ключевым направлением будут новые функции интеграции.

Каждый бизнес уникален, и необходимо учитывать всю совокупность факторов. Для оценки имеющихся вариантов и возможностей необходимо сочетание бизнес- и ИТ-навыков, и ни одна из дисциплин не должна принимать эти решения в изоляции. Это прекрасный пример того, когда ИТ-менеджеры должны понимать экономику бизнеса в дополнение к технологическим аспектам решения.