Платформы разработки для самых маленьких и не только
Некоторое время назад я был участником команды, реализующей решение, на базе которого можно развернуть internal development platform. В первую очередь мы ориентировались на крупный enterprise с командами разработки от 150 человек, которым важны унификация, контроль, снижение когнитивной нагрузки на команды, безопасная разработка. Сегодня же хотел бы поделиться своими рассуждениями о платформах разработки немного под другим углом — не с учётом команд и процессов разработки (IDP всё-таки заточены в первую очередь решать проблемы в этой области), а с точки зрения зрелости самого разрабатываемого решения.
Для начала разберем, что такое платформа разработки. Это решение, использующее набор абстракций по управлению как жизненным циклом приложения, так инфраструктурой, что упрощает жизнь разработчику, позволяя ему фокусироваться только на реализации продукта.
Теперь определим какие стадии развития будем рассматривать:
- гипотеза — проверяем ценность и спрос;
- рост — увеличением объем продаж;
- контроль финансов — стремимся к тому, чтобы выручка была больше затрат;
- унификация процессов — не собираем велосипеды, боремся за каждую секунду lead-time.
На каждом из этапов — один и тот же продукт, но с разным уровнем зрелости. И далее в основе рассуждений простая идея: та или иная платформа разработки должна соответствовать определенному уровню зрелости.
В статье разберу все стадии на конкретном продукте — SaaS для автоматизации документооборота. Цель данного приложения — помочь бизнесу автоматически разбирать входящие договоры, извлекать ключевые условия и формулировать задачи юристам. Флоу работы сервиса на старте простой: загрузка PDF-документа → извлечение данных → уведомление в мессенджере → дальнейшая работа с документами в панели управления.
Это синтетический пример, на котором мы проследим путь от прототипа до enterprise-решения. Выбрал его, потому что такой продукт проходит через все болевые точки: синхронные пользовательские запросы, тяжелые фоновые задачи (обработка PDF-документов), требования к изоляции данных и неизбежный приход enterprise-клиентов с серьезными требованиями к инфраструктуре.
Этап 1. Проверка гипотезы
На старте возникает главный вопрос: а это кому-то вообще нужно? Необходимо проверить как можно быстрее. Replit, Lovable и аналоги позволяют описать продукт текстом, получить рабочий прототип и задеплоить его в один клик. Никакой инфраструктуры и DevOps — просто идея и первые пользователи. Показательный пример — Питер Левелс, чьи Photo AI и Nomad List выросли на минимальном стеке до значимой выручки. Для многих этого вполне достаточно.
На старте выбираем 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 секунд), горизонтального масштабирования нет.
Подводные камни платформы становятся очевидными: инфраструктура полностью абстрагирована, доступ к настройкам сетей и безопасности ограничен, нет изоляции данных клиентов.
Но есть выход: на сцену выходят managed-платформы вроде Vercel, Heroku, Fly.io, а также российские решения, такие как Dockerhost, Amvera. Они обеспечивают автодеплой из Git, preview-окружения, CDN с edge-кэшированием. И всё это может работать без выделенного инженера по инфраструктуре.
Остановим свой выбор на Vercel — это позволит дальше развивать возможности продукта: добавить работу с разными типами документов, статусную модель обработки (received, parsed, validated, completed), базовые роли, мультитенантную логику на уровне приложения.
Что касается затрат: использование Vercel обойдется в среднем порядка 400 $ в месяц.
Этап 3. Зрелость и контроль
Проходит еще полгода, и теперь у нас уже порядка 200 клиентов (причем начинают появляться и корпоративные), MRR — 6 000 $.
И вот тут начинают происходить странные вещи: косты могут составлять порядка 2500 $ в месяц, что уже составляет значительную долю от доходов. И главная проблема тут даже не в размере счета, а в его непредсказуемости — рост количества посещений сайта на 40% может увеличить счет на 80%, что рушит всю unit-экономику. Счета могут составлять 40% от MRR.
Именно в этот момент инфраструктура только из технического аспекта становится еще и экономическим. Теперь она напрямую влияет на выручку. Да, Vercel решает задачу быстро и предсказуемо деплоить, но не задачу контролировать инфраструктуру. И это сознательный подход к архитектуре платформы: вы получаете простоту в обмен на контроль. Вы, кстати, не забыли, что на текущем этапе появляются первые крупные корпоративные клиенты? А у них обычно бывают следующие вопросы:
- Можно ли развернуть в отдельной VPC?
- Ограничить доступ по IP? Подключить WAF?
- А какой SLA?
С одной стороны, можно попробовать ответить честно, но это будет что-то из серии: «Ничего из этого на текущий момент нереализуемо, потому что есть ограничения платформы, на которой мы разрабатываем». С другой, такой ответ явно не устроит клиента, который готов платить за продукт и хочет получать нужные ему возможности. Идти или нет навстречу крупному клиенту с его кастомными хотелками — это, конечно, отдельный вопрос. Но главное тут то, что это выбор без выбора из-за технических ограничений. И в этот момент, как правило, приходит осознание, что команда не контролирует среду, но при этом несет ответственность перед клиентом.
Тем не менее хочу отметить, что многие решения до данных ограничений Vercel обычно и не добираются. Особенно если продукт не нуждается в сложной сетевой топологии или отсутствуют строгие требования к изоляции данных. Проблемы начинают проявляться только при определённом масштабе и типе нагрузки.
Если все-таки нагрузка мешает нормальному развитию сервиса, значит, пришла пора оставить 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. На горизонте года экономия может быть близка к нулю, зато появляются контроль и возможность масштабироваться дальше.
Промежуточный этап между миром PaaS и полным переходом в облако и стал отправной точкой для создания DeployCode — платформы, которая позволяет напрямую работать в облаке, но без инфраструктурного хаоса. И для того, чтобы данное решение могло действительно было удобным и полезным, я хотел задать несколько вопросов для обсуждения:
- Если вы пользовались инструментами 1 и 2 этапа, был ли у вас момент, когда почувствовали ограничения по затратам или по архитектурным ограничениям?
- Что оказалось самым неожиданным при перехода с PaaS’ов на облачную инфраструктуру?
- Что стало триггером для найма первого DevOps-инженера или перехода на облачную инфраструктуру?
- Какая часть инфраструктуры оказалась самой сложной при масштабировании: деплой, сеть, мониторинг или что-то еще?
Пишите мысли и вопросы в комментариях, буду рад пообщаться!
В следующей статье разберу dyno в Heroku и serverless runtime в Vercel: зачем эти абстракции были придуманы и почему важно разобраться в них до того, как вы примете решение о миграции.