От депрессии к смирению: семь стадий развития Enterprise-проекта
Enterprise — это разработка, заточенная под требования конкретного заказчика. Она чаще всего направлена на решение задач бизнеса, а не конечных пользователей.
Отрицание, злость, торг, депрессия, принятие — в какой-то момент мы поняли, что модель Кюблер-Росс весьма точно описывает эмоции команды и этапы в работе над подобными проектами. Рассказываем подробнее на примере реального кейса по созданию аналитической системы в госсекторе.
Платформа собирает информацию из разных источников, преобразовывает ее, анализирует и отдает пользователям для принятия управленческих решений. С технической точки зрения это транзакционно-аналитическая система с множеством модулей. Проект отличается сложной и переменчивой бизнес-логикой.
Стартует большой проект, на входе мы получаем четкие и вполне стандартные требования к системе, данные о сроках и бюджете. После этого собирается архитектурный совет. Там звучат два предложения: взять новый фреймворк и написать все с нуля за три месяца или воспользоваться готовым решением от крупного вендора. Чаще всего выбор падает на второй вариант, потому что требования заказчика кажутся стандартными, а первый вариант — слишком рискованным. Так что остается только найти серебряную пулю — и дело в шляпе.
Так мы и поступили. В итоге на бэке у нас была шестая Java, Weblogic, Liferay. Бизнес-логика была в базе данных. Данные хранились в Oracle Exadata. SVN мы использовали как систему контроля версии и Oracle BI — как аналитическое решение.
Вступает в игру закон Мерфи: все, что может пойти не так, пойдет не так. И с этим нужно будет что-то делать. Выбранное решение может работать нестабильно, в объемной документации зачастую тяжело что-то быстро найти, в интернете оказывается не так много готовых качественных примеров, а команде сложно работать с vendor lock и не всегда актуальными технологиями.
Мы поняли, что выбранные решения написаны далеко не на все случаи жизни. К тому же Oracle Exadata ел немало денег. Oracle BI нас не устраивал полностью — сложный, медленный, не совместимый с современными браузерами. Логика в базе данных — отдельная боль. В целом стек получился своенравным, было сложно искать людей в команду. Начала падать производительность.
На этом этапе вновь собирается архитектурный совет. Технические специалисты предлагают вернуться к первому варианту — написать все с нуля за три месяца. Но руководитель проекта понимает, что по факту разработка займет все полгода. Поэтому команда приходит к компромиссному решению — переписать только наиболее критичные места.
Нашим первым решением стал переход на Git — работать с SVN было неудобно. В целях экономии мы хотели отказаться от Oracle Exadata в пользу Oracle RAC. А еще — перенести всю бизнес-логику в Java, отказаться от liferay в пользу классического Spring MVC-приложения, от weblogic — в пользу tomcat, заменить Oracle BI на самописное решение.
Выполнить план на 100% не удалось. Мы не смогли отказаться от liferay, поняли, что написать свою BI-систему в разумный срок нереально, поэтому остались на Oracle BI. Плюс у нас возникли технические трудности с Oracle RAC. И если Oracle Exadata нам многое прощал — например, неоптимальные запросы, то здесь такой подход не сработал.
После внедрения компромиссных решений часть проблем уходит, производительность растет, баги чинятся быстрее. Да, какие-то проблемы остались. Но в этот момент руководитель проекта полагает, что проблема в программистах: они просто слишком любят писать все с нуля. Стадия радости редко длится долго.
Несмотря на приложенные усилия, старые проблемы возвращаются. Почему так? Потому что зачастую на предыдущей стадии все выбирают временные решения. А они, как известно, только оттягивают неизбежное.
В нашем случае временные решения не только не спасли нас от старых проблем, но и подкинули новых. Наш монолит настолько разросся, что стал долго отлаживаться и собираться три часа. И с каждой новой фичей время увеличивалось. Задач становилось все больше, и мы понимали, что текущие решения им не соответствуют. В это же время вышел закон об импортозамещении ПО в органах власти, что означало неизбежную замену решения Oracle на Postgres.
В этот момент к руководителю проекта приходит полное понимание трех вещей:
Команда находит проблемы и переписывает бо́льшую часть кода на современные технологические стеки, оставляя только те места, которые слишком долго и дорого переделывать.
Главное, что мы хотели сделать, это перейти на микросервисную архитектуру, чтобы увеличить производительность и решить проблему с масштабируемостью. Также мы решили глобально пересмотреть архитектуру проекта, внедрить гибкие методологии разработки и перейти с Gwt на React\Angular.
В итоге мы успешно выделили микросервисы. Сходу сделать идеальное разделение не получилось, поэтому выбрали итеративный подход. Почти полностью мигрировали на Postgres, отказались от Oracle BI в пользу собственного продукта — «Планеты. Аналитика». И, конечно, внедрили Scrum. Перейти на React\Angular не получилось — мы еще раз проанализировали код и поняли, что переписывать будет слишком дорого, а разработка на Gwt все же идет быстрее.
Эта стадия обычно следует после глобальных доработок, но по-хорошему должна идти либо до них, либо параллельно. Когда разработчик получает «зеленый свет», часто начинается over engineering — усложняются простые вещи, пишутся супер-универсальные решения на все случаи жизни. Важно вовремя ограничивать этот полет фантазии — детализировать оценки, запрашивать обоснование выбора той или иной технологии и просчитывать альтернативные варианты.
На этом этапе мы сделали две вещи: ограничили технологический стек разработки и создали ряд технических требований для микросервисов. Например, все микросервисы теперь должны делиться на бэкенд и фронтенд. На фронте — отображение, на бэке — вся бизнес-логика.
Согласно отчету IDC, рынок Enterprise-разработки в России оценивается почти в 40 миллиардов рублей. Это много. Плюс — это конкурентная среда без выраженных монополистов. Так что да, игра определенно стоит свеч.
И с Enterprise-проектами можно и нужно успешно работать, если помнить о четырех важных вещах.
Узнайте больше об Enterprise-разработке и главных трендах на этом рынке — посмотрите запись вебинара IBS «Кровавый Enterprise. Spring Cloud. Unit-тесты».