Платформы разработки для самых маленьких и не только

Некоторое время назад я был участником команды, реализующей решение, на базе которого можно развернуть internal development platform. В первую очередь мы ориентировались на крупный enterprise с командами разработки от 150 человек, которым важны унификация, контроль, снижение когнитивной нагрузки на команды, безопасная разработка. Сегодня же хотел бы поделиться своими рассуждениями о платформах разработки немного под другим углом — не с учётом команд и процессов разработки (IDP всё-таки заточены в первую очередь решать проблемы в этой области), а с точки зрения зрелости самого разрабатываемого решения. 

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

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

Теперь определим какие стадии развития будем рассматривать:

• гипотеза — проверяем ценность и спрос;

• рост — увеличением объем продаж;

• контроль финансов — стремимся к тому, чтобы выручка была больше затрат;

• унификация процессов — не собираем велосипеды, боремся за каждую секунду lead-time.

На каждом из этапов — один и тот же продукт, но с разным уровнем зрелости. И далее в основе наших рассуждений простая идея: та или иная платформа разработки должна соответствовать определенному уровню зрелости. 

Разберем все стадии на конкретном продукте — SaaS для автоматизации документооборота. Цель данного приложения — помочь бизнесу автоматически разбирать входящие договоры, извлекать ключевые условия и формулировать задачи юристам. Флоу работы сервиса на старте простой: загрузка PDF-документа → извлечение данных → уведомление в мессенджере → дальнейшая работа с документами в панели управления.

Это синтетический пример, на котором мы проследим путь от прототипа до enterprise-решения. 

Этап 1. Проверка гипотезы

На старте есть только идея, которая должна максимально быстро ответить на вопрос, а нужно ли это вообще кому-то. В эпоху повсеместного внедрения ИИ с этим прекрасно справляются сервисы Replit, Lovable и другие аналоги. Механика работы с ними простая: описываем продукт текстом → получаем реализацию → дорабатываем → деплоим в один клик на предоставляемый платформой хостинг с автоматически поднятой БД (обычно Supabase).

На старте выбираем Replit и за пару дней запускаем прототип и сарафанное радио. Через месяц у нас: 600 посетителей, 50 регистраций, 10 активных клиентов. Обрабатываем 250 документов в месяц. Первая выручка MRR (monthly recurring revenue) — 500 $, но на самом деле это не самое главное. Главное, что за наш MVP готовы платить. Теперь нужно придумать, как масштабироваться. 

Ах, чуть не забыл про косты! У Replit это примерно 50 $ в месяц на фиксированном тарифе. Отдельной платы за трафик нет — ресурсы ограничены рамками тарифа. Пока это не так важно. Но только пока…

Этап 2. Рост

Гипотеза успешно проверена — запускаем маркетинг. Проходит еще пара месяцев: 10 000 посетителей, 500 регистраций, 80 активных клиентов, MRR — 2000 $.

Кажется, неплохо. При этом нагрузка растёт, мы уже обрабатываем 6 000 документов в месяц. И вот тут начинаются подписания сервиса. Всё-таки Replit — это шаренная инфраструктура с ограниченными CPU и RAM. При росте объёма трафика начинается throttling, event loop в Node.js блокируется долгими синхронными операциями (парсинг PDF занимает 10–40 секунд), горизонтального масштабирования нет.

Появляется потребность в асинхронной очереди. Это один из первых архитектурных паттернов, которые невозможно нормально реализовать в Replit, так как там нет persistent workers, гарантии доставки и retry-логики.

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

Но есть выход: на сцену выходят managed-runtime платформы вроде Vercel, Heroku, Fly.io, Deno Deploy, а также российские решения, такие как Dockerhost и Amvera. 

Они дают автоматическое масштабирование, CI/CD «из коробки», preview-окружения для каждой ветки, CDN с edge-кэшированием, встроенный TLS — и всё это при минимальном участии инженера по инфраструктуре.

Остановим свой выбор на Vercel — это позволит дальше развивать возможности продукта: добавить работу с разными типами документов, статусную модель обработки (received, parsed, validated, completed), базовые роли, мультитенантную логику на уровне приложения (поле organization_id в таблицах). Тут важно, что этот простейший подход к мультитенантности закладывает архитектурный долг: один баг в WHERE-условии — и клиент А видит данные клиента Б. На следующем этапе этот долг придётся погашать — либо через PostgreSQL Row Level Security, либо через schema-per-tenant, либо через полную физическую изоляцию (хотя пока до этого дойдет, то либо ишак, либо падишах…).

Что касается затрат: использование Vercel на данном этапе обойдется в среднем порядка 500 $ в месяц.

Этап 3. Зрелость и контроль

Проходит еще полгода, и теперь у нас уже порядка 200 клиентов (причем начинают появляться и корпоративные), MRR — 6 000 $.

И вот тут могут начать происходить странные вещи: косты могут составлять порядка 2500 $ в месяц. И главная проблема тут даже не в размере счета, а в его непредсказуемости — рост количества посещений сайта на 30% может увеличить счет на 70%, что рушит всю unit-экономику. Счета могут составлять 40% от MRR.

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

Да, Vercel решает задачу быстро и предсказуемо деплоить, но не задачу контролировать инфраструктуру. И это сознательный подход к архитектуре платформы: вы получаете простоту в обмен на контроль. Вы не забыли, что на текущем этапе появляются первые крупные корпоративные клиенты? А у них обычно бывают следующие вопросы: 

• Можно ли развернуть в отдельной VPC?

• Ограничить доступ по IP? Подключить WAF? 

• А какой SLA? 

С одной стороны, можно попробовать ответить честно, но это будет что-то из серии: «Ничего из этого на текущий момент нереализуемо, потому что есть ограничения платформы, на которой мы разрабатываем». С другой, такой ответ явно не устроит клиента, который готов платить за продукт и хочет получать нужные ему возможности. Идти или нет навстречу крупному клиенту с его кастомными хотелками — это, конечно, отдельный вопрос. Но главное тут то, что это выбор без выбора из-за технических ограничений. И в этот момент, как правило, приходит осознание, что команда не контролирует среду, но при этом несет ответственность перед клиентом.

Тем не менее хочу отметить, что многие решения до данных ограничений Vercel обычно и не добираются. Особенно если продукт не нуждается в сложной сетевой топологии или отсутствуют строгие требования к изоляции данных. Проблемы начинают проявляться только при определённом масштабе и типе нагрузки. Яркий пример — сервисы от Питера Левелса (Photo AI и Nomad List), которые годами работают на минимальной инфраструктуре.

Если всё-таки нагрузка мешает нормальному развитию сервиса, значит, пришла пора оставить PaaS позади и переходить на следующий этап. Тут, правда, речь идет не столько о платформах (как, например, Port), сколько об отдельных сервисах (VPC, managed K8s, SDN и т. д.). VK Cloud, Yandex Cloud, Selectel как облачные провайдеры предоставляют такие услуги.

Данный этап позволяет стабилизировать экономику. При грамотной конфигурации доля расходов на инфраструктуру относительно MRR снижается до 25% — вы платите только за потребленные ресурсы (а не за абстракцию с наценкой). Managed K8s позволяет использовать автомасштабирование в зависимости от реальной нагрузки, spot-инстансы для фоновых задач, раздельные пулы узлов. Также появляется возможность отвечать на вопросы регуляторов и enterprise-клиентов. Хостинг в российских дата-центрах закрывает требования закона № 152-ФЗ. Теперь можно честно ответить на вопросы о VPC, изоляции сетей и журналах доступа. Ну и настройка становится более гибкой — доступны собственные правила маршрутизации, security groups, network policies, интеграция с корпоративными IdP через OIDC.

Точка перелома - инфраструктура начинает съедать прибыль

Этап 4. Унификация процессов

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

Если рассматривать наш пример (SaaS для автоматизации документооборота), то этот этап наступает, когда наряду с основным решением появляются свои продукты (разрабатываемые компанией, а не купленные у вендора), billing, IAM и другие сопутствующие сервисы.

Статей на тему, чт такое и зачем нужны IDP, написано огромное множество, например вот. Тем не менее важно обозначить этот этап, чтобы картина была полной. Решения такого класса оправданы, когда есть более 150 разработчиков, выделенная платформенная команда (примерно 10 человек) и готовность инвестировать 6–12 месяцев в построение внутреннего продукта.

К решениям класса IDP можно отнести Backstage, Humanitec, VK Dev Platform, Platform V Works, «Сфера», «Марлин». Отмечу лишь, что, по моим наблюдениям, большинство компаний на этом этапе строят платформу под себя, а не покупают готовое — слишком специфичны внутренние процессы.

И еще одно ключевое различие заключается в том, что платформа здесь — это прям отдельный продукт со своей командой, дорожной картой и внутренними пользователями в лице разработчиков. Golden paths, стандартизированные окружения, self-service для команд — всё это появляется именно здесь. Для команды из 20–30 разработчиков это преждевременная оптимизация. Стоимость построения и поддержки IDP будет выше, чем боль от её отсутствия.

Вывод

Итак, мы с вами верхнеуровнево разобрали развитие продукта и предложили модель зрелости. Путь от Replit к Vercel и далее к облачным сервисам и IDP — это определенный подход на каждом этапе. Сначала важна только скорость, потом появляется необходимость пусть в минимальной, но гибкости, затем во главу угла становится контроль, а после стандартизация. Проблема в том, что переходы между этапами бывают болезненными и часто запаздывают — компании эксплуатируют инструмент дольше, чем нужно, потому что стоимость выхода всегда выше, чем кажется на входе. Особенно острой эта боль становится в зоне между PaaS и облаком. Там, где продукт уже вырос из управляемых абстракций, но ещё не накопил ни экспертизы, ни бюджета для полноценного взаимодействия с отдельными инструментами.

Могу отметить типовые проблемы, которые могут возникнуть у неподготовленных: 

• Terraform-репозиторий, который понимает один человек (и он вот именно сейчас в отпуске).

• K8s-кластер, настроенный по туториалу, который «работает, главное, рядом не дышать».

• Новый разработчик не может поднять окружение за день.

• Деплой есть, но стандартов деплоя нет.

Цена ошибки резко возрастает. Неправильно настроенный security group — это потенциальная утечка данных клиентов. Неверное автомасштабирование — счёт в ×5 или ×10 от ожидаемого. Отсутствие network policies — нет изоляции между тенантами на уровне инфраструктуры, даже если в коде всё правильно. В ответ на это обычно звучат слова: «А что, сложно самим terraform-скриптик написать?» Написать не сложно. Сложно поддерживать его 3 года, онбордить новых разработчиков, стандартизировать окружения, не превратить инфраструктурный репозиторий в хаос модулей. Terraform — это инструмент, а платформа — это процесс + стандарты + автоматизация + UX для разработчика.

Возвращаясь к нашим шагам хотел бы обратить внимание как раз на переход с этапа 2 на этап 3. На мой взгляд, тут у большинства команд появляется разрыв — инфраструктура стала дешевле, но не проще. Всё, что раньше скрывала платформа, теперь является ответственностью команды. Компания экономит на инфре, но может увеличить ФОТ. Медианная зарплата выделенного DevOps-инженера в России может быть сопоставима с экономией на инфраструктуре при переходе с PaaS. На горизонте года экономия может быть близка к нулю, зато появляются контроль и возможность масштабироваться дальше.

Тернистый путь от прототипа до зрелого продукта

Мне интересно посмотреть, насколько предложенная модель совпадает с реальным опытом:

• Если вы пользовались инструментами 1 и 2 этапа, был ли у вас момент, когда почувствовали ограничения по затратам или по архитектурным ограничениям?

• Что оказалось самым неожиданным при перехода с PaaS'ов на облачную инфраструктуру?

• Что стало триггером для найма первого DevOps-инженера или перехода на облачную инфраструктуру?

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

Пишите мысли и вопросы в комментариях, буду рад пообщаться!