Posts

Если вы когда-либо оказывались в той восхитительной ситуации, когда ваше приложение тонет в запросах к базе данных быстрее, чем программист может сказать «попробовали ли вы выключить и снова включить», то пристегните ремни — мы собираемся поговорить об одной из самых недооценённых суперспособностей производительности в Go: Ristretto. Позвольте быть с вами откровенным: большинство разработчиков Go, с которыми я встречался, либо не знают о Ristretto, либо думают, что это какая-то модная итальянская кофемашина для эспрессо (что, справедливости ради, неудивительно, учитывая название)....

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

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

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

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