Инфраструктура стартапа

// По другому поводу написал конспект современной инфраструктуры, но получилось достаточно цельно, потому и за эссе сойдёт.
Развитие инфраструктуры идёт в сторону «делать больше, платить меньше». В общем, как и везде на рынке технологий. Небольшие компании не могут позволить себе сотни тысяч долларов ежемесячно, да и большие давно стараются ужаться в подобных расходах (один лишь GitHub на 1K пользователей в год начинается от 15М рублей), потому прогресс идёт вполне ожидаемым путём.
Под инфраструктурой далее подразумеваю всё, что обеспечивает процесс разработки и эксплуатации продукта, а не части самого продукта. Потому, например, Nginx в тренде, но это не инфраструктура.
Упомянутые названия считаю современным [хайповым] трендом. Иначе говоря, если собрать в небольшую толпу десятка два 20..30-летних разработчиков, из толпы будет доноситься то, что опишу ниже. Безусловно, существуют организации, живущие на другом софте, но речь не про них.
Каталог ниже также можно рассматривать, как первый набросок для первых обсуждений в начинающем стартапе. О, у нас есть N копеек и два человека, что мы можем из этого соорудить, чтобы продержаться десять лет до первого миллиона копеек? Если с этой позиции смотреть, так нынешний софт в какой-то мере представляет собою конструктор Лего. Кубики умеют работать друг с другом, редко являются обязательными, конструкцию по мере нужды можно наращивать и даже местами заменять с адекватной миграцией данных, ежели руки прямые. Я как-то прикидывал, нынче при действительно прямых руках можно чуть ли не всю инфраструктуру размазать за $150 в месяц. Не на сто человек, да, но мелкий коллектив вполне. Хорошие времена.

Нулевой круг: хостинг особо упомяну.
В тренде аутсорсинг и облачность. Соответственно, массово выбирают тех, кто на нормальном уровне за нормальные деньги предоставляет все те услуги, которые предоставлялись бы собственной серверной с отрядом админов, железячников, ноков и завхозов. Влёт можно назвать [в порядке убывания универсальности] Amazon AWS, Microsoft Azure, Google Cloud Platform. Это очень разные платформы со своей спецификой каждая, потому равными назвать не могу. Просто разные. Если нужно «в два клика» что-нибудь захостить, есть DigitalOcean. Сервисов на порядок (если не два) меньше, чем у того же AWS, но с задачей справляется.

Первый круг: VCS и Issue tracker.
VCS. Исходный код и прочее надо где-то хранить и обеспечить общину возможностью совместной работы с ним. Совместная работа нынче подразумевает активную вовлечённость, социальность, частично геймификацию, интеграцию со всем на свете. В тренде GitHub, GitLab, Bitbucket. Все три решения сделаны поверх git.
Issue tracker. Весело, молодо и задорно жить без тикетов или обходиться цветными бумажками на доске, но рано или поздно, а команда из этих штанишек вырастает. Задачи надо где-то описывать, обсуждать, отслеживать статус, строить графы зависимостей, получать срезы состояния и прочее. Тут устроить зоопарк проще, т.к. каждый год кто-нибудь пытается повторить успех JIRA (ведущий ледокол рынка трекеров, с каждым релизом бьющий рекорды неудобства). В спину ей дышат Bugzilla (для совсем олдскульных), YouTrack. С ощутимой натяжкой можно упомянуть Trello, но они всё-таки про другое. Но если далеко от системы карточек на доске уходить не хочется, то и Trello сойдёт.

Второй круг: общение, мониторинг и логи.
Общение. Команды часто распределённые (особенно если вы стартап и вам дешевле нанять двух senior’ов из Мордовии, чем одного московского middle), потому тема «где нам обсуждать работу?» поднимется быстро. Важной характеристикой решения является возможность видео на команду. Тут тоже бардак, т.к. долго не было единого продукта, решающего все задачи разработки (закрытые групповые каналы, архив, конференции, plugin’абильность, модные боты и т.п.). Потому у вас сейчас два варианта: устраивать конструктор из Skype / Jabber (ссылка на протокол) / Telegram или использовать Slack. Особняком варианты для knowledge base — что-то для хранения коллективных знаний. Тут у каждого своё, хоть одну из сотни Wiki поднимай, хоть один из вариантов по подписке, хоть закрытый репозиторий на GitHub. «Моделей» слишком много на любой вкус.
Мониторинг. В какой-то важный для команды момент количество тихо упавших сервисов начнёт действовать на нервы, после чего срочно вспоминают о нужде мониторинга живости машин и софта на них. Тут тоже не особо много боевых альтернатив. Частые метрики снимаются либо в Prometheus, либо в Influx. Событийный мониторинг есть смысл делать через всё тот же Zabbix. Приятные глазу графики как смотрели, так и будем смотреть в Grafana. А всякие стектрейсы и прочие ошибки можно отправлять в Sentry.
Логи. Весь софт пишет мегагигабайты логов, об которые ушатаешься ходить на каждую машину и грепать файл за файлом. Потому человечество придумало ELK stack (Elasticsearch, Logstash, Kibana). Держать в инфраструктуре эту триаду — та ещё головная боль, но иметь возможность удобно оперировать логами с кластеров… бесценно.

Последний круг: Continuous integration, Continuous delivery и остальное.
Темпы современной жизни диктуют темпы и разработке. Продукты надо делать быстро. Скорость часто бьёт по качеству, потому элементы CI/CD включают в себя также и максимальное исключение человеческого фактора — автоматизация проверок кода, автоматизация сборок, выкаток. В этой области раздолье и зоопарк полный. На деле же основной проблемой будет совсем не софт, но внедрение разработчикам в головы нужды в CI. Например, там тесты писать надо, а это же таааак скуууучно.
В этом же разделе решения, которые могут примениться раньше, могут позже, могут прямо-явно не относиться к CI/CD, но здорово его облегчают. В общем, список того, чем занимаются, когда хотят сделать всё правильно и есть возможность.
Контейнеры. Удобнее куда-нибудь доставить и где-нибудь поднять уже готовое приложение со всеми конфигами, файликами и прочим. Как минимум, это быстрее. На сцену выходит Docker, царь контейнерного хайпа. Лишь избранные знают и думают о других решениях. На самом деле вполне стоит и подумать, т.к. Docker не панацея и для ряда задач имеет смысл прикинуть альтернативы.
Оркестровка. Нравится это слово в контексте «хорошо, давайте управлять всеми этими контейнерами на этих инстансах в этих облаках». Тут поле боя, на котором рубятся Swarm с Kubernetes. Правда, тут снова тема Docker, но чё уж, мода. Сюда же Nomad для спартанцев.
Сборка и тесты. Так лаконично свёл CI в две задачи. На деле, конечно, решается гораздо больший спектр. Навскидку тут можно назвать три продукта: Jenkins, TeamCity, Travis CI (ваш выбор, если open source). Каждый со своими чудесами, своими лицензиями и ценами. Но вряд ли вы обойдётесь без них при внедрении CI в инфраструктуру. Писать скрипты запуска и сборки по крону занятно, спору нет, но лучше не надо.

Уверен, я не назвал десятки решений, которые вы считаете очень важными или лучшими или ещё какими-нибудь. Это нормально. Их назовёт кто-нибудь другой. Часть из них я просто не знаю. Часть не подходит небольшим командам (у вас целый департамент админов, это круто). Часть… кхм (знаю бойцов, живущих в IRC, им норм). Наконец, 35 ссылок в одном эссе — пока рекорд тут, ставлю запятую.

Инфраструктура стартапа: Один комментарий

  1. Первый круг (и кусочек второго) — vcs, issue tracker и wiki забавным образом сочетаются в fossil (http://fossil-scm.org). Из минусов — система довольно экзотическая, но может служить и небольшим «экзаменом на профпригодность» — если разработчик не может пользоваться консольным интерфейсом vcs и всенепременно требует Tortoise*** — то нахрена он такой нужен?

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

Добавить комментарий