Масштабирование ПО: изменения вглубь и вширь

ИТ-системы не могут без развития и масштабирования

Рынок технологий и ИТ-решений неизменно растет вместе с объемом данных и потребностями общества. Мысли о масштабировании компании знакомы каждому владельцу бизнеса. Развитие компании может потребовать больше пользователей (сотрудников, партнеров и клиентов), новых подразделений, информации для обработки, а значит – больше задействованных серверов и компонентов систем.

100% задач бизнеса в этом случае решает заказная разработка.

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

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

Что важно бизнесу при реализации проекта?

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

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

Коробочное решение – это некая готовая база, которая покрывает и обеспечивает основной функционал. Далее под вашу специфику и задачи дорабатываются надстройки, и новые элементы и микросервисы, проводится проводится интеграция с текущим ИТ-ландшафтом и кастомизация продукта.

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

Спойлер: единого универсального решения нет. В эпоху интенсивной цифровизации появилась тенденция к модели “ставим коробку с дальнейшим замещением на крупную заказную разработку”. Когда бизнес берет готовое решение с минимальными доработками, чтобы обеспечить жизнеспособность систем на текущий момент времени. Параллельно готовит новое гибкое решение с богатым функционалом и возможностями оперативной его доработки.

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

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

1. например, объединить нескольких готовых систем;
   
2. взять готовое решение и на его базе дорабатывать свою систему собственными силами или силами вендора;
   
3. комбинированная сборка с применением и своих разработок, и готовых систем, и заказной разработки.

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

Трудности и риски для российских компаний

В России еще не так много зрелых готовых продуктов. “Молодое” решение должно претерпеть большое количество внедрений и изменений, чтобы стать действительно зрелым универсальным продуктом и быть применимым в самых разных ситуациях. Со временем, когда отечественные разработчики набьют руку в решении новых задач и за их спинами будет не 4-5 успешных рейсов, а десятки, ситуация изменится.

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

Случается, что выбранное решение у заказчика работает сразу (это большая редкость, вам повезло). Но также есть риск, что компании сперва покупают нечто дорогое, а после им приходится серьезно кастомизировать большую часть исходного функционала, вести разработку нового кода и нового функционала, чтобы получить желаемый результат. И возникает вопрос: “А за что мы заплатили столько денег? Фактически мы использовали малую часть. По сути, сварили кашу из золотого топора.”

В любом случае при приобретении готового ПО у отечественного вендора, следует внимательно смотреть на следующие моменты:

1. Организация сопровождения и поддержки. Вендоры должны быть способны с вами общаться и оперативно решать задачи. Выделять на это ресурс и время, не забрасывая бэклог на полгода. Многие российские вендоры, по отзывам партнеров, перегружены задачами: слишком много компаний на рынке и уникальных вызовов за короткий промежуток времени, а вендор организационно и финансово не готов организовать такой расширенный уровень поддержки.
   
2. Наличие команды с опытом масштабной разработки и внедрения ПО Ряд технологий и процессов внутри российского бизнеса перестраивается на новые принципы работы. Когда выполняется большая кастомизация коробки с итоговым нестандартным решением – разработка в разы усложняется. Появляется больше задач по миграции ПО, интеграции систем. Приоритет сейчас за технологиями, которые включены в Реестр российского ПО. Важно понимать, в состоянии ли ИТ-подрядчик обеспечить разработку на актуальном стеке и с учетом новых вызовов. Если нет, то эти ресурсы стоит искать внутри своей компании или у компании по заказной разработке.
   
3. Возможность открытия кода. Часто, чтобы провести то или иное изменение нужно спуститься на очень глубокий уровень работы с кодом, переписать большой его объем. Вы можете столкнуться с невозможностью масштабирования. Если вендор не готов (нет свободных ресурсов и кадров) делать глубокую кастомизацию, нужно договориться о возможности открытия кода для вашей команды или партнера, чтобы провести модификацию и необходимые изменения.

Наглядный пример: “Поспешай неспеша”

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

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

Что получилось в итоге? Последовало около 3 месяцев внедрения, тяжелый запуск в одном из цехов, а после – работа вовсе встала. Потому что несмотря на схожесть стандартов и документации с предыдущей компанией, коробка требовала “ломать” бизнес-процессы этого заказчика под новое ПО. Дополнительных изменений в части кода внести самостоятельно было невозможно – открытость не подразумевалась вендором изначально. Масштабирование системы оказалось дорогим, лишь частично оправданным и незавершенным. Ждать, пока партнер освободится и возьмется за проект времени не было. И тогда предприятие вновь занялось ИТ-проектом, но на этот раз с нуля и используя услуги опытной компании-разработчика.

Чтобы таких ситуаций не возникало, мы рекомендуем подробно и тщательно продумывать план действий.

Как правильно масштабировать проекты?

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

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

Задача: “Нам нужно, чтобы системы выдерживала в три раза больше запросов/пользователей, так как мы увеличиваем количество пользователей, число сотрудников, объем технологий и мощностей, данных для обработки”.

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

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

Отечественные ИТ-компании предлагает построение частных облаков, когда ты буквально «сам себе Амазон». Облака подходят как для эксплуатации текущих решений, так и для построения новых. Они упрощают ведение разработки и тестирования благодаря автоматизации этих процессов. Помимо этого технологии позволяют использовать искусственный интеллект для отслеживания паттернов пользователей или оборудования, чтобы оперативно расширить или распределить нагрузку по серверам компании.

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

Где она – золотая середина?

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

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

Прелесть выстраивания ИТ-проекта с применением заказной разработки в том, чтобы брать лучшее из любого подхода, преумножая пользу для бизнеса. Прогноз Гартнера о том, что к в современном мире большая часть ИТ-систем будет собрана, а не куплена – сбывается. Комбинированный подход позволяет бизнесу в разных отраслях в разы оперативнее решать стратегические задачи. На созданную под вас цифровую платформу легко можно добавить и интегрировать коробочные или OpenSource решения, адаптировав их под себя так, как этого требует ситуация в конкретный момент.

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