Legacy Code

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

Подавляющее большинство современных инструментов управления инфраструктурой сделаны не для людей. Имея на руках кучу отличных технологий и карт-бланш, из-под рук “творцов” всё равно выходят уродливые пародии на Do Nothing Machine(https://www.youtube.com/watch?v=Bp4tGTNNi1I), которыми потом приходится пользоваться несчастным инженерам.

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

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

- Балансировщик-гейтвей с SSL-терминацией

- Эфемерные сервера приложений и минимальный service discovery между ними

- Крон, выполнение кода по расписанию

- Managed базы данных (реляционные и нереляционные) с бекапами, копированиями, автоматическим масштабированием

- Объектное хранилище (S3) и CDN для него

- Очереди (SQS и всевозможные *MQ)

- Чтобы всем этим можно было управлять по API

- Blue-green (red-black) deployment, клонирование окружений, canary releases

- Все это в одном месте и чтобы запускалось одной кнопочкой

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

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

(если у вас есть комментарии и возражения, например о том что все на самом деле хорошо, то обязательно оставляйте его у меня в блоге: https://www.rozhkov.me/post/infrastructure-for-a-people/)

Возникает вопрос, а что важнее всего для заказчика в разработке?

Это очень простой вопрос, и ответ очень простой. Заказчику от разработки -- неважно, внутреннему или внешнему -- важна СКОРОСТЬ. Можно усилить: по сути, больше ничего не нужно. Да даже сама разработка (продуктовую, имею в виду) и ее приемы -- она исключительно про скорость.

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

Микросервисы? Чтобы можно было взять те команды, которые есть в наличии, и писать на том, на чом умеют; сладкие сказки про масштабирование и прочий шрот уже сверху придумали, потому что по-честному такую сложную и ненадежную машинерию ни один инженер не взвалил бы на себя (вспомните soa: а теперь там на порядки больше единиц развертывания). Лучше всего микросервисы масштабируются только по одному измерению: количеству людей в разработке.

Хорошая архитектура и прочий кодинг-стайл сегодня? Это чтобы завтра можно было писать быстро и не сбавляя скорость.

Автотесты? Чтобы отлавливать ошибки ещё на этапе, когда не потребуется возвращать продукт в доработку, потому что это долго и снижает скорость.

Специализация в разработке? Ну вы поняли.

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