Инфраструктура для людей

Подавляющее большинство современных инструментов управления инфраструктурой сделаны не для людей. Имея на руках кучу отличных технологий и карт-бланш, из-под рук “творцов” всё равно выходят уродливые пародии на Do Nothing Machine, которыми потом приходится пользоваться несчастным инженерам.

По идее, с течением времени уровень абстракции должен повышаться, а сложность управления — уменьшаться. Когда выстрелила Lambda и serverless-движение, то казалось что вот он — конец громоздким архитектурам и серверам. Увы, на деле всё не так просто и Lambda стала еще одним инструментом для узкого круга задач.

Меня сильно огорчает это положение вещей. Большинству проектов нужно всего ничего:

  • Балансировщик-гейтвей с SSL-терминацией
  • Эфемерные сервера приложений и минимальный service discovery между ними
  • Крон, выполнение кода по расписанию
  • Managed базы данных (реляционные и нереляционные) с бекапами, копированиями, автоматическим масштабированием
  • Объектное хранилище (S3) и CDN для него
  • Очереди (SQS и всевозможные *MQ)
  • Чтобы всем этим можно было управлять по API
  • Blue-green (red-black) deployment[1], клонирование окружений, canary releases
  • Все это в одном месте и чтобы запускалось одной кнопочкой

Всё. Этим набором (а то и меньше) можно закрыть почти всё что угодно. Конечно, вдобавок надо еще мониторинг физических и бизнес метрик, централизованное логирование, фаерволы и всё остальное из 12-factor application[2] набора, но то уже плюшки, поначалу можно жить и без них. Но для того, чтобы всё это настроить, завести и потом поддерживать, надо приложить титанические усилия. Большинство держит для этой чёрной работы специального человека или целый отдел.

К сожалению, индустрия идет по пути культа больших компаний и пытается скуксить (“натянуть наоборот”) решения, выросшие из потребностей гигантов, на свою маленькую проблему. У нас появляются кубернетесы, но кубернетес из коробки слишком сложен поэтому давайте сделаем еще десяток инструментов для упрощения кубернетеса: minikube, k3s, kind, еще черти что, для конфигурации возьмем Б-го мерзкий YAML а для гибкости навернем туда разнообразных шаблонизаторов и сделаем компиляцию одного ямля в другой. На одном из проектов, где я сейчас работаю, все крутится в кубере. Даже с учётом того, что мы используем GKE, окружения не сильно сложные и все деплоится через helm, у меня просто лютейше подгорает от всего этого. После пары месяцев работы над инфраструктурными задачами я совершенно перехотел заниматься тем, что называется DevOps. Пустите меня обратно в коробочку, откуда я могу выдавать код, который “работает на моей машине”, а дальше делайте с ним что хотите. Я бомблю каждый день от невероятной сложности всего происходящего и до меня теперь на самом деле дошла шутка про Senior YAML Engineer. Мне кажется, люди могут лучше.

Вопрос не в том, что я не могу в сложные системы. Я могу. Но совершенно не хочу быть тем самым говнолазом, который наставлял джуниор ассенизатора “учись, а то всю жизнь подавать ключи будешь”[3]. Мне неприятно работать с современной инфраструктурой, мне не доставляет никакого удовольствия заниматься её конфигурацией и поддержкой. Мне не нравятся решения, не нравится “декларативный” (он только на бумаге такой) подход, не нравятся инструменты. Хорошая инфраструктура — эта та, которую не видишь. Как менеджер, или политик.

Лучшим, но далеко не идеальным средством управления инфраструктурой для меня сейчас является Heroku. Разработанный в годы хайпа по Rails, как мне кажется он воспринял философию RoR “машина для человека”. Нажал две кнопочки, git push heroku master и все задеплоилось. SSL сертификат выдался, база данных создалась, трафик крутится лавэха мутится. Почти идеально. Я считаю что Heroku-like подход в современном мире сильно недооценен. До определённого уровня усложнения проекта (а он наступает очень-очень нескоро, или вообще не наступает) можно почти не думать про инфраструктуру. Конечно, всё это построено на дырявых абстракциях. Рано или поздно может оказаться что железо под вашим dyno барахлит, у амазона outage или еще какие-то проблемы. CPU троттлится, рядом шумные соседи и ваши нагрузки плохо держатся. Но до этого еще надо дожить.

Почему современные инструменты имеют тенденцию к усложнению для меня загадка. Когда изобрели Docker (а он кстати вырос как раз из PaaS компании dotCloud), был некоторый всплеск похожих на Heroku продуктов (“Docker hosting” — напиши докерфайл, а мы сами всё развернём) но они все остались нишевыми и маловостребованными.

Рынок предлагает нам всего ничего: голые VPS с которыми надо возиться руками самому, managed K8S для которого уже надо держать специально обученного человека и вендорские решения контейнерной оркестрации типа ECS где надо писать еще кучу своего тулинга. В своё время я потратил не один месяц на то, чтобы автоматизировать деплоймент в ECS и потом после меня ребята еще дописывали и переписывали этот инструментарий. Живет в продакшене до сих пор. Кубер в то время был еще новой технологией. Или можно взять дорогущий и несколько ограниченный Heroku. Однако я предпочту последний возне с YAML, пусть он и будет дороже и ограниченнее (хотя в свете того что для кубера вам нужно держать control plane и HA кластер тут еще вопрос что будет дороже).

Казалось бы, первую часть эволюции разработки с грехом пополам человечество осилило — embedded application server для Java, толстые go бинарники, рантаймы и контейнеризация — всё это спасает нас от необходимости иметь дело в томкатом и заливать файлы по FTP. Но вот сделать вторую часть, чтобы одной кнопкой всё работало, уже мощностей не хватает. Или не хватает запроса на рынке. Мне лично абсолютно, совершенно, непонятен хайп вокруг кубера. То есть, я умом понимаю какие задачи он решает и какие профиты дает, но сердце протестует, а цена усложнения, которую нужно платить, мне кажется совершенно неприемлемой. Возможно, люди не знают, что можно лучше? Если ты не покажешь человеку, как можно упростить свою работу, то он и не будет догадываться что совершенно необязательно всю дорогу ехать на велосипеде с квадратными колёсами. Непонятно.

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

Одной из основных причин печального состояния инфраструктурного инструментария я вижу то, что DevOps культура так и не стала реальностью. Вчерашний обычный Ops который сидел в терминале и правил конфиги на железных серверах сегодня превратился в DevOps который теперь умеет писать еще и манифесты куберовских сервисов на yaml. Разработчикам инфраструктура как была безразлична, так и осталось. В результате админы просто берут то что есть и довольны. Может быть для них новые системы дистрибуции приложений (Docker) и последующей орекстрации контейнеров (K8S) и упростили жизнь, но от этого в целом сильно лучше/продуктивнее жить не стало.

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

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

2020 год на дворе. Я решительно не понимаю почему мне нужно ждать минуту пока соберется и запушится образ с моим кодом и еще несколько минут пока helm передёрнет кубер и тот зальет его в продакшн (это в лучшем случае минуты). Я не понимаю. Почему нельзя просто поменять код и чтобы все работало? Почему нигде нет хорошего автоматического blue-green деплоя (только через кучу скриптов)? В некотором роде это есть в лямбдах, но для сложных проектов оно не годится. А должно.

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

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

Один из характерных примеров машинно-центричного говнософта сделанного не для людей (но при этом крайне популярного) — это Prometheus[4] и его друзья (AlertManager и иже с ними). В чем это проявляется? У прометеуса есть конфигурация. Конфигурация загружается из файла. Всё. Никакого способа поменять конфигурацию в рантайме нет. Что мы делаем? Заменяем файл на диске и сообщаем (по http) прометеусу чтобы тот перечитал конфигурацию. Отлично, да? Что мешает сделать то же самое, но без замены файла? Разработчики прометеуса отказываются[5] добавлять эту функциональность, потому что "это усложнит конфигурацию". А вы как хотели? Это реальный мир, тут всё сложно. В результате что — в результате делается костыль в виде вебсервиса[6], к которому нужно примонтировать том с конфигом прометеуса и который инкапсулирует в себе http сервер для замены всего этого дела в рантайме и ребут самого прометеуса. Отлично. Десятки тысяч людей во всем мире трахаются с конфигурацией этого всего дерьма и называют это best practice потому что разработчки не думают про людей. Они думают про машины, про удобство для машин, но не думают про людей. Читатель скажет: так ведь и правильно, философия UNIX заключается в том, что каждая программа делает одну маленькую вещь, но хорошо, а вы дальше перенаправляйте ввод-вывод и будет вам счастье. Оно то может и так, но это машинно-центричный подход. Это про компьютеры, это для удобства компьютеров но не для людей. Люди хотят нажать кнопку и пить чай. Вместо этого мы сами себе создаём сложности, костыли, а потом проводим конференции о том, как из буханки хлеба сделать троллейбус.

Откуда берется этот машинно-центричный подход? Я понятия не имею. Возможно потому что у админов, которые этим всем пользуются просто нет выбора? Админ не может написать под себя хороший инструмент, максимум пара скриптов и всё. Поэтому ему некуда деваться и приходиться ходить на конференции по прометеусу, у него просто нет выбора. Почему же разработчики всё время выдают какое-то неюзабельное говно? Наверное, потому что они сами не пользуются этим всем? Не знаю. Могу лишь констатировать факт что всё плохо и никому до этого нет дела. Админы рады новым игрушкам, девелоперам плевать.

Похоже, что никого не беспокоит эта проблема (сложности) и никто не чешется чтобы её порешать. Максимум, на который способно сообщество сейчас — это делать врапперы поверх кубера[7]. Который всё равно рано или поздно протечет и нужно будет брать ключ на тридцать два и нырять в говна.

Один из проектов, который пытается решить сложность разработки и деплоя это DarkLang. Но там ребята решили не париться а сразу сделать свой язык, свою IDE (браузерную) и свою платформу под это всё. Моментальный деплой бекенда, масштабируемая база данных, откаты на предыдущие версии и управление миграциями — все как надо. Одна проблема — это проприетарный язык и платформа. Решение, которое завоюет мир, должно поддерживать любой рантайм и миграция приложений на него должна быть простой.

А вот мире фронтенда всё неплохо прогрессирует. Netlify, zeit.co — отличные примеры того, что я хочу получить для бекенда. Деплой за секунду. SSL за минуту. Мгновенный откат на любую предыдущую версию. Отдельный урл для каждого деплоя. Сборка бранчей и пулл реквестов. CLI для заливки самостоятельно собранных файлов или билд на платформенных мощностях. Где то же самое, но для бекенда?

Еще один пример подхода "для людей" это минималистичные CSS-фреймворки (или библиотеки называйте как хотите). Суть в том, что вы не добавляете CSS-классов и не думаете про CSS вообще. Просто подключаете файл со стилями и ваша страничка начинает выглядеть достаточно нормально. Такой подход используется в Tacit, Water, MVP.

А для бекенда ничего нет. Сотни тысяч людей ежедневно жрут говно но не замечают этого. И так норм.

Надо что-то решать.


  1. BlueGreenDeployment ↩︎

  2. https://en.wikipedia.org/wiki/Twelve-Factor_App_methodology ↩︎

  3. Два ассенизатора, молодой и старый идут прочищать очередной засор. Подошли к канализационному колодцу и старый мигом в него нырнул. Выниривает через полминуты, воздух набрал, и говорит: - "Дай ключ на тридцать два!". Опять нырнул. Выныривает через минуту, кричит: - "Дай ключ на восемнадцать!" - и опять ныряет в дерьмо. Проходит еще полминуты, выныривает весь в дерьме, устало вытирает лоб, лицо и говорит молодому: - "Учись, сынок, пока я жив, а то так и будешь всю жизнь ключи подавать." ↩︎

  4. https://prometheus.io/ ↩︎

  5. https://github.com/prometheus/prometheus/issues/1623 ↩︎

  6. https://github.com/coreos/prometheus-operator ↩︎

  7. https://twitter.com/kelseyhightower/status/1202009305148358656 ↩︎


Сподобалось? Долучайтеся до мого телеграм каналу: https://t.me/full_of_hatred