Разработчики — бизнесу: как масштабировать цифровой продукт правильно

Вариант развития событий, в котором разработанный сервис, сайт или приложение нужно масштабировать, бизнесу лучше продумать еще на этапе планирования разработки. Это логично: проще сразу «подстелить соломки» и разрабатывать продукт с заделом на будущее, чтобы встретиться с минимальными издержками, когда окажется, что нужно расти.

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

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

Самые частые способы масштабирования цифрового продукта.

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

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

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

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

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

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

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

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

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

Как понять, что пора развивать монолит?

Переход монолита на микросервис становится актуален, когда понятно, что эта структура ограничивает возможности роста и развития бизнеса:

В этом случае внедрение микросервисной или сервисной архитектуры — отличный вариант. Это экономит время: так разработчики не мешают друг другу, у каждого своя зона ответственности.

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

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

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

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

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

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

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

В результате получится монолитная архитектура, с которой не возникнет трудностей при трансформации в сервис и затем в микросервис.

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

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

Другие варианты перехода позволяют обеспечить непрерывность работы продукта.

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

«Параллельное развертывание» — этот процесс тоже идет параллельно с существованием монолита, но он подразумевает постепенное переключение трафика на микросервисы.

«Переход по функциям» подразумевает идентификацию ключевых бизнес-функций и постепенное выделение этих функций в микросервисы.

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

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