Своя инфраструктура

Кит
Кит

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

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

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

Докку

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

Несколько шагов:

  1. сервер от Digital Ocean, Linode или AWS;
  2. первоначальная настройка этого сервера;
  3. один скрипт с сайта Докку;
  4. в твоем репозитории: git remote add dokku $server;
  5. git push.

Вот и замена Хироку.

За несколько лет пользования Докку, он ни разу не подводил. Свою работу выполняет на ура. Конечно, бывают ситуации где что-то требует настройки, но это быстро решается поиском на Гитхабе проекта.

Довод против внешних сервисов

Несмотря на существование популярных платформ-как-сервисов2, таких как Версел (Zeit) и Нетлифай, я того мнения, что разработчикам следует размещать свои приложения самостоятельно. Пользы от этого достаточно:

  • Понять как устроены Юникс, серверная инфраструктура, сеть.
  • Получить преимущество для своего продукта, путем того, что “необычные” случаи будут решаться легче, чем на перечисленных сервисах. Стоит вопрос времени, когда это произойдет, а не о том произойдет это в целом или нет.
  • Внешний сервис ставит твой продукт в положение полной зависимости. Исторически, эти сервисы меняют свою позицию на рынке вводя не совместимые с предыдущей версией обновления. Но ты ведь не хочешь оказаться в такой ситуации.

Я использовал все перечисленные сервисы выше. Скажу очевидное, они хороши несмотря на то, что их конечная стоимость окажется выше. Почему? Потому что разворачивать свою среду занимает много времени и есть высокие шансы ошибиться если это не единственное, чем ты занимаешься. Как говорили “олды” в 90-х, ты не хочешь проснуться в три утра от того, что один из твоих сервисов упал3.

Однако этот аргумент все менее и менее актуален. Хостить среду самому сейчас легче чем когда-либо. Легко воспроизводимые среды с контейнерами и наработанные инструменты позволяют уйти с Хироку, но пока не разворачивать кластеры.

Так и случилось у меня. Как только Докер стал постояльцем в моем инструментарии, более не было причин продолжать зависеть от внешних сервисов. Головной боли больше не было.

Про Кэпровер

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

  • Матомо (веб-аналитика, замена Гугл Аналитике)
  • Эки (веб-аналитика, замена Гугл Аналитике попроще)
  • Сэнди (рассылка с AWS SES)
  • Минио (AWS S3-совместимое хранение)
  • Моника (личный CRM)

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

Бизнес кейс

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

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

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

Сообщество

Я нашел много дельных советов и огромное количество ПО готового к использованию на сабреддите /r/selfhosted и Гитхабе awesome-selfhosted.

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

Конфиденциальность

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

Простой пример в пользу своей инфраструктуры: миллионы людей используют блокировщиков рекламы. Нет необходимости использовать Гугл Аналитику, поскольку она блокируется, и также ухудшает репутацию перед пользователями, “кормя” большой G. Самозапускаемые альтернативы как Матомо или даже что-то простое, как Эки может быть достаточно.

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

Итог

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

  1. Программное обеспечение. 

  2. PaaS, platform-as-a-service. 

  3. «Падением» серверов называют недоступность.