Наверх

Мигрируем в облака. Переносим систему

Время чтения: 3 минуты
6
Мигрируем в облака. Переносим систему

Мигрируем в облака. Переносим систему

Я продолжаю серию статей об «облачном» явлении. В предыдущей статье я постарался ответить на вопрос: «кому нужна облачная ЕСМ-система», рассказал об основных преимуществах и недостатках облачной инфраструктуры. Сейчас я хочу выделить основные факторы, о которых важно помнить при переносе системы в облака. Эти факторы относятся к ЕСМ-системе, которая изначально не предназначена для работы в облачной инфраструктуре, но которую хочется туда перенести.

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

А что же надо учитывать при планировании инфраструктуры?

Разберем этот вопрос более подробно.

Начну с того, что ЕСМ-система работает с неструктурированными данными и она достаточно  требовательна к пропускной способности канала. При переносе системы в «облака», во-первых, оцените пропускную способность каналов связи до вашего провайдера – чем больше пользователей работают с системой, тем шире должен быть канал. При низкой пропускной способности конечный пользователь получит задержку в работе, а этого надо избежать.

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

Данный фактор дает основание полагать, что веб-доступ не так требователен к ресурсам сервера, запускается без дополнительных установок на компьютере пользователя и позволяет работать с любого устройства. Но здесь стоит помнить о возможных ограничениях веб-клиентов ЕСМ-системы и перед принятием решения предварительно их изучить.

Выбор организации доступа также окажет влияние и на другие факторы, например, на способ интеграции офисным ПО. Так при веб-доступе оно должно стоять локально на компьютерах, а при терминальном доступе все ПО устанавливается на сервер. Также при переносе ECM-системы в облака стоит продумать взаимодействие с Active Directory, 1С или почтой, которые находятся не в облаке.

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

Перечисленные мной факторы – это та основа, которую надо учитывать при планировании инфраструктуры для переноса не облачной ECM-системы в облака.

Чтобы прочитать эту статью до конца,
или зарегистрируйтесь

Комментарии 6

Андрей Подкин 27 февраля 2012
Во-вторых, решите, каким образом будет организован доступ к облачной системе. Возможно, это терминальный или веб-доступ.
Возможно. Но не всегда удобно. Например, можно еще написать специализированные нативные клиенты (привет iPad) для работы с облачным сервисом.
Данный фактор дает основание полагать, что веб-доступ не так требователен к ресурсам сервера, запускается без дополнительных установок на компьютере пользователя и позволяет работать с любого устройства.

Не факт. Часто веб-доступ к системам класса ECM использует платформенные привязки для части функциональности. Таковыми могут быть ActiveX, Java, Flash или что-то еще. Даже если это запустится на iPad или Android-планшете, может оказаться, что ключевая для пользователя функциональность не заработает.

PS. А будет пример переноса ECM-системы в промышленное облако, например, MS Azure или Amazon EC?

Михаил Романов 28 февраля 2012
В предыдущей статье я постарался ответить на вопрос: «кому нужна облачная ЕСМ-система», рассказал об основных преимуществах и недостатках облачной инфраструктуры.
Вообще-то, в предыдущей статье не было сказанно ни слова про облака. Там была рассмотрена некая смесь из: 
  • варианта развертывания системы у внешнего хостера,
  • использования SaaS системы - способа продажи готового сервиса
Ни то, ни другое, к облакам не имеет ни малейшего отношения.
Самый главный аспект облачных вычислений, это
доступ по требованию к общему пулу конфигурируемых вычислительных ресурсов ... , которые могут быть оперативно предоставлены и освобождены с минимальными эксплуатационными затратами и/или обращениями к провайдеру
Т.е. надо мне увеличить емкость хранилища или вычислительные ресурсы (добавить инстансов, увеличить им память, ...) - я все это делаю сам, через консоль провайдера. И оплачиваю только используемые мощности - т.е. мне не надо беспокоиться о простаивании мощностей (которые не дешевы) или наоборот, что в в какой-то момент мне их не хватит, и мне придется сросно переносить систему на новую машину/хостинг, ...
Мало того, подобноя техническая система может быть развернута и не у провайдера, а в своем дата-центре. Решений для так называемых частных облаков сейчас море.
В общем, давай для начала определеимся с предметом разговора.
Потому как в общем случае ни первая, ни текущая твои статьи к облакам не имеют никакого отношения.
Михаил Романов 28 февраля 2012

Ну и по самой статье:

Начну с того, что ЕСМ-система работает с неструктурированными данными и она достаточно требовательна к пропускной способности канала

И что? Любая система может быть требовательна к каналу... а может и не быть...

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

А типичный кейс работы в ECM-системе: раз в несколько часов открыть документ (который, если это обычный офисный документ - будет в районе от 100 до 1000 кб), отредактировать и залить обратно. Где здесь большие объемы?

Соответсвенно, как именно

оцените пропускную способность каналов связи до вашего провайдера
- что конкретно нужно сделать?
Данный фактор дает основание полагать, что веб-доступ не так требователен к ресурсам сервера, запускается без дополнительных установок на компьютере пользователя и позволяет работать с любого устройства
Хотелось бы увидеть какое-то численное подтверждение...
Но здесь стоит помнить о возможных ограничениях веб-клиентов ЕСМ-системы и перед принятием решения предварительно их изучить
В свете того,что большинство мировых лидеров (Microsoft SharePoint, EMC Documentum, OpenText, Alfresco), а также многие российские системы (EOS for SharePoint, DocsVision, Летограф, Elma) изначально спроектированы как Web-системы, данное утверждение имеет смысл только для некоторых российских систем, ориентированных на Desktop - коих с каждым годом становится все меньше.
Также при переносе ECM-системы в облака стоит продумать взаимодействие с Active Directory, 1С или почтой, которые находятся не в облаке.
Во-первых, в какое именно облако?
Для частного облака это вообще бессмывсленное утверждение, для публичного или гибридного - зависит от реализации.
Но вопрос - если вы отдаете внешнему провайдеру свою ECM-систему, то почему бы не держать там же почту, учет и прочие системы? Какой смысл выносить во вне ECM, но держать свои почтовые сервера?
Облака ­– это не только техническое решение, это еще и сервис.
Не правда. Как говориться, "учите матчасть". Облака - это чисто технический термин, значение которого я привел выше. Сервис, сюда не относится никаким боком.
Итог:
  • опять никакой конкретики (ни цифр, ни методики)
  • содержание статьи никак не связано с заголовком
  • автор упорно называет облаками обычный хостинг ресурсов
Спасибо за оставленные комментарии.
Статьи написаны мной, исходя из реального опыта. В прошлом году я участвовал в разработке проекта по переносу ЕСМ-системы в облака. Из этого проекта я вынес ряд выводов, с которыми делюсь в рамках своих статей. Конечно, систем много, технология переноса достаточно сложная, много спорных моментов. Но общая направленность моих статей состоит в том, чтобы разобрать процесс переноса классической ЕСМ-системы за рамки вычислительных мощностей офиса.
Но общая направленность моих статей состоит в том, чтобы разобрать процесс переноса классической ЕСМ-системы за рамки вычислительных мощностей офиса.
Вот.
Именно поэтому я предлагаю не злоупотреблять термином "облако" - это не более чем один из типов организации хостинга (наряду с выделенным сервером, разделяемым сервером, ...).
Из этого проекта я вынес ряд выводов, с которыми делюсь в рамках своих статей.
Вот и здорово - почему бы не поделиться конкретным опытом и конкретными решенными или не решенными проблемами?
Например, по такой схеме:
Во-первых, сразу оговорить что за система, какова ее архитектура, какие варианты для нее применимы, какие противопоказаны, ...
Во-вторых, как выбирался тип хостинга, какие были нужны опции? ...
В-третьих, каковы полученные результаты? Если это работа реальной системы, то сравнить с тем, что было у заказчика до и после (или что было на анлогичной системе у разных заказчиков) - что получили, где проиграли, ...
В-четвертых, (хотя, наверное, это "в-нулевых") - а заради чего это вообще затевалось?
И больше "цифр и графиков", общие выводы типа "могут быть проблемы с каналом" уже давно обсосаны со всех сторон, но еще никто на моей памяти не сказал, а какой нужен канал или как его посчитать.

В следующих статьях добавлю конкретики и цифр :)

Чтобы прокомментировать, или зарегистрируйтесь