EN

Как сделать инфраструктуру для стартапа, если в кармане $20

5213
3

Считается, что хорошая и дешевая инфраструктура — это миф и в реальной жизни так не бывает. Автоскейлинг, инфраструктура как код, Kubernetes, мониторинг и логирование — это звучит очень дорого. А что делать стартапу, у которого нет денег? DevOps-инженер и автор самого большого Telegram-канала о DevOps в Украине Олег Миколайченко в колонке для AIN.UA рассмотрел два примера, как сделать осмысленную инфраструктуру за копейки и не ограничивать бизнес плохими решениями.

Когда строить инфраструктуру для стартапа 

Часто случается так, что первая версия продукта готова, а запустить ее негде — просто нет инфраструктуры, или она в супер плачевном состоянии. Это очень печально — стартап теряет время, а конкуренты не спят.

Инфраструктура —  это сервисы, процессы, площадки для запуска проекта. По сути, это вся обвязка продукта вместе с вычислительными мощностями. Это сервера, процессы разработки и выкатки, мониторинг, сервис для логов, и большое архитектурное видение: а что будет “если”. 

Таких “если” может быть огромное количество (о которых нужно позаботиться еще до публичного релиза): 

  • если пойдет трафик,
  • если появятся пользователи,
  • если стартап купят,
  • если пользователи не придут, и это будет мертвый продукт.

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

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

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

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

Этапы развития стартапа

Допустим, гипотеза уже подтверждена и прошла этап валидации, вы решаете ее реализовывать, на выходе получаете продукт, несколько раз его меняете, попадаете в топ на Product Hunt и… занавес.

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

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

Быстрый цикл обратной связи, быстрая разработка и частые релизы — это то, что нужно для стартапа.

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

Кто должен делать первую версию платформы  

Я бы очень рекомендовал найти DevOps-инженера на part time — в результате он сможет за несколько дней реализовать нормальную начальную инфраструктуру по этой статье и лучшим практикам.

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

Чего у вас больше — денег или времени — решать только вам.

Рассмотрим ситуацию: в кармане с названием “инфраструктура” есть $20. Что делать в таком случае?

Best practises дизайна инфраструктуры

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

Разберем по очереди, что важно: 

1. Масштабируемость

Какая разница, сколько времени потрачено на валидацию гипотезы и разработку, если на публичном релизе полная лажа. Инфраструктура должна быть спроектирована с учетом роста, ведь это самое важное для стартапа. Эту проблему решает Kubernetes + облачный провайдер. 

Пришло 1000 пользователей — хорошо, увеличим количество виртуальных серверов в облаке. Пришло 10000 — ладно, еще увеличим. Начинает подтормаживать база данных (а мы это видим по графикам мониторинга) — окей, увеличиваем ее размер или тип. 

Всегда нужно руководствоваться здравым смыслом: шардирование БД для стартапа — нет, увеличение размера виртуального сервера БД — да. 

2. Инфраструктура как код

К счастью, в 2020 году никто инфраструктуру руками не поднимает. Если ваш инженер так делает — скорее всего у вас нет инженера. Изменения “руками” подразумевают огромное количество рутинных действий, приводят к ошибкам, никто никогда не знает, в каком состоянии инфраструктура. Никому не понятно, как оно вообще работает и может работать. Эти проблемы принято решать с помощью Terraform

3. Цена

Круто, если мы можем запустить приложение и платить за инфраструктуру копейки. Если мы стартап на начальном этапе, то денег еще не зарабатываем — чем меньше стоит инфраструктура, тем больше времени можем пробовать “выстреливать”.

4. Фокус на пользе

Все что не касается приложения и базовой инфраструктуры нужно максимально выносить в SaaS. Нужен мониторинг? Datadog или Newrelic. Некуда складывать логи? Logentries или LogDNA. Нечем собирать приложение? TravisCI, CircleCI или Github Actions. 

Если пытаться поднимать и сопровождать свой Jenkins, Prometheus, Elastic stack — будет и сложно, и неэффективно. 

5. Отдельные аккаунты и кредитки

Заведите отдельный почтовый ящик для регистраций сервисов и отдельную банковскую карту для оплаты услуг. Это суперполезный совет с любой точки зрения. 

Serverless в AWS: сначала копейки, потом камаз

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

Стоимость Lambda: $0.20 per 1M request + duration billing 

Возьмем самое логичное решение: Lambda + API Gateway. Это работает так: описываем бизнес логику в Lambda-функциях, и сверху накручиваем роутинг между несколькими функциями с помощью API Gateway.

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

Второе преимущество — масштабирование из коробки. Внезапные A/B тесты, которые гонят трафик, никак не отразятся на стабильности: каждый пользователь будет обслужен. 

Концепция инфраструктуры как код будет отлично работать и позволит описать все ресурсы в Terraform (и несколько окружений для разработки, быстрые релизы).

Дополнительно из коробки будет базовый мониторинг, базовое логирование —  и это все стоит очень дешево, пока продукт никто не использует.

Самое сильное преимущество — фокус на пользе. По сути, все работает само по себе: остается только разрабатывать бизнес логику и ни о чем больше беспокоится не нужно. 

Минусы тоже есть: 

  • vendor lock (если мы спроектируем serverless систему внутри AWS, мы будем ограничены только этим облаком);
  • дополнительная оплата за каждое движение: трафик, логи, мониторинг, время, ресурсы;
  • это будет стоить камаз денег, когда придет реально много пользователей;
  • это будет стоить камаз денег, если систему мы спроектируем неправильно (занимать больше памяти, чем нужно, длительное время выполнения и т.д.).

Получается, что это идеальный вариант, если вы тестируете идею и не ждете огромного количества запросов и пользователей. Классный вариант, если вы получили финансирование от AWS или зарегистрировались на free tier. Если есть нагрузка — будет дорого и супер неудобно.

Kubernetes в DigitalOcean: $20 в месяц  

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

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

Kubernetes поддерживают Google, CNCF и очень большое сообщество.

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

Альтернативы для PaaS Kubernetes — AWS EKS ($120/месяц за пустой Kubernetes cluster), GKE (от $50 за 2 самые маленькие ноды) — намного дороже, но в то же время более production-ready. Можно рассмотреть как вариант миграции, когда у стартапа появятся деньги.

DigitalOcean Kubernetes: 2 nodes — $20/month

Самая дешевая конфигурация — это два виртуальных сервера (можно и один, но тогда будет не отказоустойчиво, так что нельзя один).

DigitalOcean Kubernetes (DOKS) поддерживает концепцию инфраструктуры как код. Ресурсы и провайдер доступны в Terraform и конфигурируются супер просто. Готовый Kubernetes кластер создается буквально одним ресурсом и несколькими строчками кода.

Если в AWS Lambda за дополнительные деньги были сразу доступны Cloudwatch для логирования, Cloudmetrics для мониторинга и X-Ray для более детального понимания, что происходит с приложением, то в DOKS такого нет. Есть совсем базовые бесплатные графики по потребляемой памяти, нагрузке процессора и сети, но этого, очевидно, мало.

С точки зрения масштабируемости у нас есть возможность скейлится как вертикально (увеличивая размер и тип виртуального сервера), так и горизонтально (автоматически увеличивая количество серверов в кластере). Горизонтальная масштабируемость доступна по умолчанию, и работает примерно так: 

  1. В зависимости от метрики (загрузка процессора, память, сеть) DOKS определяет, что нужно добавить виртуальный сервер в кластер;
  2. Kubernetes понимает, что появился новый сервер, и перемещает туда часть приложений;
  3. Когда нагрузка ушла, DOKS постепенно убирает сервера из кластера;
  4. Победа: мы заплатили только за пару часов, пока была нагрузка.

Для того, чтобы реализовать детальный мониторинг и логирование в мире Kubernetes, принято использовать prometheus-operator и Elastic stack. Эти сервисы устанавливаются внутрь кластера и занимают ресурсы. Мы строим инфраструктуру за $20, так что лишних ресурсов у нас нет. Давайте смотреть, как мы можем выйти из этой ситуации.

Datadog pricing: $0 up to 5 hosts

Из всех SaaS систем мониторинга бесплатный план я нашел только у Datadog. С помощью Datadog мы сможем собирать метрики с нашего кластера, смотреть графики в браузере и анализировать, почему наше приложение работает плохо. 

Дополнительно могу рекомендовать использовать Sentry для начального анализа ошибок приложения. У них также есть бесплатный план.

LogDNA pricing: free plan, 0 retention days

Из решений для логирования бесплатный план есть у LogDNA: нюанс в том, что логи будут удаляться через 24 часа. Это немного неудобно, потому что всегда хочется понимать, когда ошибка появилась впервые. Но для наших требований — более чем достаточно.

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

Для старта этого будет более чем достаточно.

А как же дешевые spot instances? 

Spot Instance Advisor: экономия до 90%

Да, отличная идея. Но не для первого релиза.

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

Получается, что приложение должно быть спроектировано специальным образом: дополнительно нужно реализовать graceful shutdown (правильное завершение работы, оно нужно при масштабировании в том числе), добавить очереди сообщений в архитектуру и еще много нюансов. Такой подход — это усложнение продукта, и дополнительный лишний акцент не на основном бизнесе.

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

GCP Free Tier & AWS Free Tier 

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

GCP Free tier: $300/12 month 

Google Cloud Platform дает $300 на 12 месяцев. Если попытаться построить Kubernetes cluster — это будет стоить около ~$50 в месяц. Получается, что этих денег хватит на 6 месяцев.

AWS Free Tier подразумевает использование определенных сервисов в пределах квот, тоже на 12 месяцев. К сожалению Kubernetes Engine не доступен в бесплатном периоде, но вполне можно построить serverless архитектуру, которую мы рассматривали разделом ранее.

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

Также упомяну о Google Cloud for Startups и AWS for Startups. Если ваш стартап уже работает,  есть пользователи, юридическое лицо, и вы можете показать рост на графиках — скорее всего у вас получится получить финансирование от облачных провайдеров.

Условия и возможности гибкие, в целом их можно характеризовать так: провайдеры ежемесячно будут выделять вам сумму, необходимую на развитие инфраструктуры, сроком до трех лет. За это время вы 100% научитесь пользоваться внутренними сервисами (агрессивный маркетинг и личный менеджер будет этому способствовать), а через какое-то время даже съезжать никуда не захотите.

Послесловие 

Получается, что в реальной жизни можно запустить начальную масштабируемую инфраструктуру с высокой доступностью даже когда совсем нет денег. Конечно, $20/месяц — это минимальная сумма, с которой начинается  самая первая версия самой маленькой инфраструктуры. С ростом стартапа будет расти количество серверов, их стоимость и цена дополнительных сервисов для логирования и мониторинга.

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

В крайнем случае, Kubernetes дает вам возможность легко мигрировать с дешевого DigitalOcean Kubernetes на более дорогой Google Kubernetes Engine, или самый дорогой Amazon Kubernetes Engine после того, как придут инвестиции. В будущем будет возможность переехать и на свои сервера. В конце концов можно будет двигаться даже в сторону cloud agnostic: это когда платформа работает в нескольких облачных провайдерах одновременно. 

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

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

Автор: Олег Миколайченко, DevOps-инженер

Оставить комментарий

Комментарии | 3

  • Годная статья но есть нюансы.
    1. Автор скорее всего ровняет всех по себе и забыл что кубернетес на самом деле достаточно сложная система. Иметь в команде человека который его знает и может им управлять стоит далеко не 20$.
    2. Любой стартап имеет несколько стадий жизненного цикла. Стартап у которого нет вообще клиентов, думать о том что serverless будет дорого когда они доростут до 1кк клиентов в месяц это по меньшей мере странно. Если это стартап, до первого миллиона архитектура поменяется 10 раз, и код который был написан вначале вообще работать не будет. По этому, я бы рекомендовал все же на начальном этапе выбирать архитектуру которую легко менять и эволюционировать, а уж потом оптимизировать финансы. Правило простое:
    Make it work -> make it right -> make it fast -> make it cheap.
    Если идти от обратного скорость такого стартапа будет медленной и он не взлетит.
    А вообще не плохой обзор как сделать дешевле для тех кто знает что он делает и в команде уже есть толковый SRE.

  • Прийшлось зарегистрироваться, чтобы оставить отзыв.
    Начну с того что ДевОпс изначально подавался как методология. А SRE и SE имеет свои не достататки.
    Наличие облака в другой стране, сложности с «заморозкой» продукта. Конвертация валют, и сильная зависимость от промежуточного ПО.

    А после фразы: «в 2020 году никто инфраструктуру руками не поднимает».
    Вообще перестал вчитываться и читать заголовки.
    Как Опсер с 10 летним стажем. Не говори е такие глупости.
    Да, есть программируемые сети, да, есть авторазвертувыемые системы.
    Те кто руками поднимают, как раз умеют «ложить» ваши облака на лопатки.
    Заказчик врядле будет рад за динамические цены или переплату за ддос или прочее дерьмо.
    Так же благодаря этим рукастым, именно рукастым! У тебя есть сейчас 3/4G. И я не видел не одного офиса больше 50 чел. Без опсера, не эникея , а опсера.
    В аларм или рекавери системах, многое тебе не позволить.
    Есть привязка к железу NOC, сегодня у тебя этот проц, завтра он уже тротлит . А ты будешь сидеть и в коде ковырять , а почему.
    ИМХО опсы переживут хайп с облаками. А вот ДевОпс сомневаюсь. Посмотрите флоу их технологий и нововведений, это ссущий заопарк.
    И некоторые руками можно сделать за 3 минуты, когда на программное потребуется день а то и неделя.

Последние новости
12 авг
Смотреть все
  • Спецпроекты
  • Безопасность номера
  • Безпека гаманця
Реклама на AIN.UA

Поиск