Posts

Если вы читаете это, возможно, кто-то в вашей организации оправдывал сохранение той древней системы COBOL или тех серверов эпохи Pentium, которые пылятся в углу центра обработки данных. Вы слышали, как это называют «технической задолженностью», «необходимым злом» или — моё любимое — «мы перенесём это в следующем квартале» (мы оба знаем, что этого никогда не произойдёт). Но что, если я скажу вам, что ваши устаревшие системы на самом деле могут приносить вам пользу?...

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

Существует определённый тип разработчиков, которых я вижу на конференциях: они с абсолютной уверенностью говорят об единственно правильном способе структурирования кода. Они цитируют «Банду четырёх», как священное писание, строят свою архитектуру с точностью швейцарского часовщика и смотрят на ваше прагматичное операторское выражение if-else так, будто вы попросили их отладить COBOL в 1980-х годах. Они не совсем неправы. Просто они забыли одну важную вещь: шаблоны проектирования — это инструменты, а не заповеди....

Представьте: 1969 год, и Кен Томпсон сидит перед практически неиспользуемым компьютером PDP-7 в Bell Labs. Большинство людей увидели бы просто неработающую машину, собирающую пыль. Томпсон увидел возможность. Он только что наблюдал, как огромный, раздутый проект операционной системы под названием Multics рухнул под тяжестью собственной сложности, и подумал: «Должен быть лучший способ». Спойлер: он был. И это коренным образом изменило наше представление об операционных системах. История UNIX — это не только о технологиях, это о группе блестящих людей, которые были настолько разочарованы, что создали нечто элегантное вместо чего-то огромного....

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