Централизованные информационные системы имеют массу преимуществ перед распределенными: нет проблем с организацией репликаций, контролем версионности, существенно проще обеспечивать высокую доступность и отказоустойчивость, организовать резервное копирование и быстрое восстановление, решать задачи планирования мощностей и масштабирования. Сейчас существует масса технологических решений, позволяющих решать подобные задачи: виртуализация, сети хранения данных, интегрированные с системами резервного копирования данных по сети хранения, решения по кластеризации приложений, системы балансировки (распределения) нагрузки и т. д.

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

В подавляющем большинстве случаев классический «толстый клиент» обеспечивает нормальную работу в пределах локальной сети. При работе через WAN появляется множество новых факторов: ограниченная и зачастую негарантированная полоса пропускания, высокая латентность (время прохождения пакета) и джиттер (разброс значений времени прохождения пакетов), потери пакетов, алгоритмы шифрации и VPN (в результате их работы реальный MTU может быть намного меньше указанного в настройках ОС клиентов и сервера, на который настроены приложения), различного рода фильтры и настройки QoS (или их отсутствие).

Другой «куст» проблем — это комплект ПО и его настройки на клиентском ПК. В пределах одного кампуса, обслуживаемого одной ИТ‑службой, подобные проблемы вполне реально решить. Но когда сотни или тысячи ПК, распределенные по нескольким регионам или даже странам, обслуживаются несколькими совершенно разными и независимыми ИТ‑службами… Вот тогда в портфеле ИТ-проектов и начинают попадаться проекты типа «Стандартный АРМ компании».

А если компания использует несколько платформ, и у каждой свой клиент? Тогда процесс подготовки и тестирования нового релиза клиентского АРМ начинает напоминать процесс разработки сложного приложения.

Удаленная работа пользователей (на сегодня в качестве транспорта почти всегда используется глобальная сеть Интернет) практически идентична работе пользователей через WAN, за исключением повышенного влияния аспектов информационной безопасности.

В итоге при использовании «толстых клиентов» на доставку централизованного сервиса до конечного потребителя оказывает влияние масса факторов. Обеспечение доставки сервиса с качеством, соответствующим качеству предоставления централизованного сервиса, может оказаться весьма нетривиальной задачей. Естественно, наличие или отсутствие проблемы также зависит от множества аспектов, в первую очередь от самого приложения. Например, «толстый клиент» всенародной бухгалтерской системы «1С» при работе через каналы WAN почти гарантированно будет регулярно сбоить. А вот клиент Lotus Notes весьма надежно (хотя и не всегда быстро) работает почти в любой сети и имеет набор встроенных средств для организации и оптимизации работы в конкретной WAN.

На сегодня есть два основных варианта обеспечения доступа пользователей к приложениям через WAN и удаленного доступа к приложениям: встроенный www-интерфейс приложения или запуск «толстого клиента» в терминальной системе.

Основное достоинство интерфейса Web — в его универсальности. Теоретически вы может получить доступ и нормально работать с вашим приложением с любого АРМ. Однако на практике все не так хорошо.

В результате необъявленных войн между разработчиками различных платформ и технологий, применяемых для создания интерфейсов www в последние три-пять лет, разработчикам приходится создавать различные версии для различных сочетаний ОС, браузеров, встроенных языков и плагинов. Поэтому в корпоративных системах, как правило, гарантированно поддерживается один (обычно это Internet Explorer), максимум два браузера определенной версии с некоторым набором ключевых настроек. А если корпоративных приложений несколько, то и их требования к браузерам могут оказаться несовместимыми.

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

Другой момент — при разрыве соединения текущее состояние сессии пользователя в Web-интерфейсе приложения может не сохраняться, и тогда при восстановлении соединения пользователю придется начать сессию сначала.

Еще одна особенность — у некоторых приложений Web-интерфейс не обеспечивает на 100% функциональность «толстого клиента». Второй вариант — запуск «толстого клиента» в терминальной системе имеет свои особенности. Для одной активной сессии обычно достаточно полосы около 60 Кбит/с, что на сегодня достаточно легко обеспечить. Большинство терминальных решений (Microsoft, Citrix и др.) обеспечивают подключение к терминальной сессии локальных дисков, принтеров, портов USB. Однако если для комфортной работы в терминальной сессии достаточно 60 Кбит/с, то для передачи больших файлов и вывода заданий на печать на локальный принтер этого может не хватить.

Как показывает практика, некоторые принтеры и МФУ (вернее, их драйверы) весьма известных и уважаемых производителей не поддерживают печать из терминальных сессий.

Часто возникает и другая проблема: в терминальной системе может потребоваться инсталлировать несколько «толстых клиентов» различных систем. В этом случае администраторам, обслуживающим терминальные системы, приходится заниматься исследованиями совместимости различных версий «толстых клиентов» различных систем и требуемых для их работы библиотек и пакетов. А в последний год все чаще проявляется еще и вопрос разрядности (32&64).

Бывают и совсем экзотические ситуации. Все тот же «толстый клиент» всенародной бухгалтерской системы «1С» (начиная с версии 7.7 и до 8.2) при работе через TerminalServices RemoteApp Microsof откалывает следующий фортель: при движении мышкой по экрану модального окна (то есть окна с кнопками «Да» и «Нет») это окно начинает растворяться и полностью исчезает. Так как система ждет нажатия на кнопку, а пользователь не видит окна с кнопками, то возникает полное впечатление, что система «зависла». Или вот такой случай: в «толстом клиенте» одной информационной системы некорректно производилось распараллеливание задач на ядра процессора. На обычном ПК это «прокатывало», а на терминальном сервере три-четыре активные сессии вызывали дикий перекос в нагрузках на процессоры и их ядра, более чем ощутимо тормозя при работе в терминальном сервере.

Я привел все вышеперечисленные примеры, чтобы подтвердить следующий вывод: централизация приложения решает одни проблемы и вместо них создает другие. Например, упростив жизнь службам, осуществляющим техниче­скую поддержку на местах, вы сильно осложняете жизнь администраторам и системным инженерам, поддер­живающим терминальные системы.