Scaling Up в е-коммерции

Роберт Шайер

Начало в выпусках: #128

Управление уровнями

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

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

"Разбив предприятие на три уровня, можно по необходимости добавлять аппаратное обеспечение к каждому из них", - подчеркивает Вайнер.

Число посетителей HSN.com увеличилось с 325 тыс. в январе прошлого года до 2,3 млн. в декабре. Митчелл объясняет, что, поместив большую часть логики в средний уровень, компания смогла многократно использовать компоненты.

"Прослойка" типа XML

Практически всем компаниям приходится связывать веб-приложения с системами товарно-материальных запасов, бухучета и платежей. Часто, как в случае с Avis, эти системы являются приложениями мэйнфреймов и не созданы для 3-уровневой архитектуры (не говоря уж об Интернете). Однако отказываться от них и разрабатывать новые слишком дорого.

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

Такое планирование требует расходов, которые разработчики и руководство предприятия должны учитывать при срочном запуске новых приложений.

"Я рад, что мы позаботились об архитектуре данных, которая поддержала переход Avis к хранилищу. Но это далось нелегко", - говорит Киндер. Получение информации из центрального хранилища данных обошлось на 10-15% дороже, чем встраивание в старую базу еще одного последовательного приложения.

Преуспевающие веб-архитекторы придерживаются принципа "pay-as-you-go". Киндер считает, что каждый проект ИТ должен давать конкретную деловую выгоду и "развиваться в направлении целевой архитектуры, хотя бы понемногу".

Сталкиваясь с проблемами несовместимости последовательных систем, руководители отделов ИТ узнают, что цель наращиваемой веб-архитектуры - делать деньги. Митчелл говорит: "Будь проще. Решай задачи и обслуживай клиентов, а не корми технологического монстра".

Роберт Шайер (Robert L. Scheier) - независимый писатель, RScheier@charter.net.

Три истории успеха