Миграция на другую платформу для стабильно работающего веб-приложения

Введение

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

Само функционирующее приложение состоит из двух основных компонентов — фронтенд и бекенд. Исторически сложилось так, что на фронтенде используется технология .NET на сервере IIS, а бэкенд работает на Java на сервере Tomcat.

Основной задачей данного проекта было уйти от части .NET на сервере IIS на единый стек технологий (Java + JavaScript).

Заказчик при этом получает следующие преимущества:

1. Упрощается разработка и поддержка приложения, благодаря уменьшению стека технологий.
2. Можно перейти на Linux-сервер, что позволит внедрить контейнеризацию на проекте. Заказчик при этом получает ряд преимуществ в рамках CI/CD культуры.
3. Стоимость владения инфраструктуры существенно уменьшается.

Основной challenge проекта

Миграции на другие платформы являются в каком-то смысле типовыми задачами, потому что проблемы одинаковы:

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

В нашем кейсе заказчик изначально не знал, есть ли смысл инвестировать в данный проект и ему нужна была подробная оценка трудоёмкости. А как сделать оценку, если проект сложен, имеет в себе массу нетривиальных решений и требует массу времени только на начальное исследование?

По этим причинам дорожная карта нашего проекта была следующей:

1. Сделать базовое исследование и описать текущую архитектуру приложения.
2. Предложить несколько вариантов архитектуры, на которую мы предлагаем перейти.
3. Применить технику “оценка оценки” для того, чтобы согласовать с заказчиком время, которое нам необходимо на первичное исследование трудоёмкости проекта.
4. Создать работающий прототип нового приложения.
5. Доработать прототип до полностью готового решения.
6. Внедрить решение на production.

Рассмотрим каждый этап подробнее.

Описать архитектуру приложения, как она есть на текущий момент

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

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

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

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

Определить возможные варианты решения

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

На основании анализа текущего состояния системы команда предложила несколько вариантов:

1. Переместить фронтенд часть на имеющийся Tomcat сервер, на котором расположен backend. При этом .NET часть приложения переписать на Java.
2. Заменить IIS на ещё один Tomcat, переписав .NET часть на Java.
3. Заменить IIS на сервер Apache, оставив на нём только статическую и динамическую JS части фронтенда, а функционал .NET реализовать в виде отдельного модуля на бэкенде.

Наилучшим вариантом был выбран вариант №3, так как в этом случае предполагаемая трудоёмкость и риски были минимальны. Результатом работы на данном этапе стало создание диаграмм развёртывания и последовательности будущего приложения.

Как оценить трудоёмкость проекта с очень высокой степенью неопределённости?

У нас есть противоречие. Нам необходимо принять решение — нужно ли делать проект. Решение принимается в том числе исходя из трудоёмкости проекта. Но так как в проекте очень высокая степень неопределённости, то непонятно как работать с риском того, что трудоёмкость сильно превысит заявленные сроки.

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

В рамках нашего проекта мы пошли по второму пути. И первый же вопрос, который у нас возник, а сколько времени займёт глубокая оценка проекта? Для ответа на данный вопрос мы применили метод “Оценка оценки”.

Весь проект глубоко декомпозируется. В нашем случае работы над проектом были разбиты на 63 задачи по 14 разделам. По каждому разделу разработчик должен был дать оценку — сколько времени ему потребуется, чтобы оценить время выполнения работ по нему. То есть выполнить оценку оценки.

Результат такой подробной декомпозиции дал нам достаточно точную оценку времени, сколько нам необходимо, чтобы спланировать и оценить работу по переходу с IIS сервера на Apache. То есть это только то время, которое нам необходимо, чтобы оценить работы по переходу и сформировать план работ. В конечном итоге оценка оценки заняла приблизительно 25% времени от всего объёма работ. Ещё около 25% процентов ушло на выполнение оценки. Таким образом заказчик получил точки принятия решения по исследовательскому проекту, что позволило серьёзно увеличить уровень предсказуемости проекта.

Заказчика устроил данный результат и он одобрил проведение исследовательских работ по оценке трудоёмкости самого проекта.

Оценка трудоёмкости проекта

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

В итоге в качестве результата мы предоставили заказчику исследование с оценкой времени и показали прототип с базовым функционалом.

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

Создать работающий прототип нового фронтенд-приложения

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

Так как покрытие приложения GUI-автотестами достаточно высокое, заказчик одобрил приёмку работ через успешное прохождение прототипом ключевых GUI-автотестов.

Доработать прототип до готового решения

На этом этапе сначала были определены все оставшиеся функциональности, которые не были перенесены в прототип.

Далее работа строилась по стандартным процессам разработки:

1. Добавить оставшийся функционал.
2. Проверить его работоспособность GUI автотестами и вручную.
3. После реализации всего функционала на stage сервере сделать полное предрелизное тестирование.

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

Заключение

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

Однако наш опыт реализации подобного рода проектов помог нам правильным образом подойти к проблеме. А наличие нужных экспертиз у наших инженеров позволило успешно завершить проект.

Технологии

Стек: jQuery, Ajax, Spring Framework.
Инфраструктура: AWS, Bitbucket, CloudWatch, Jenkins.

Скриншоты

Свяжитесь с нами, чтобы обсудить Ваш IT-проект