​​HashiCode: Terraform remote state backend locking

Awesome article from Daniel Mangum which started a blog post series that his called "HashiCode" where he do deep dives into the source code for HashiCorp tools!

First episode covers everything from .tfstate files to Go polymorphism patterns, all in search of how Terraform handles locking with the S3 remote state backend.
Also, these posts will be a great place to get started if you want to get involved in contributing in the open source community.

#terraform

Как написать самый хреновый софт, который только видел мир. Часть 1
В свое время Хоар назвал изобретение null pointer "ошибкой на миллиард долларов". Может быть и так, но чаще всего NPE -- это просто последствия кривых рук и политики "оттягивания конца". Каждый слышал про fail early, но, почему-то, в боевом коде все предпочитают тянуть до последнего, откладывая или вообще исключая проверку предусловий(описаных тем же самым Хоаром). В результате получается хрупкий код, кидающий NPE отовсюду. Гораздо хуже, если в результате отсутствия проверки предусловий нарушается консистентность данных: допустим, нам надо сохранить профиль пользователя. Профиль состоит из инфы, улетающей в базу, и аватарки, хранящейся в S3. И вот наш замечательный код, естественно без предусловий, сохраняет инфу в базу, а аватарку пользователь не выбрал. И при сохранении в сторадж у нас летит NPE. Хорошо, если мы умышленно сделали аватарку опциональной, но что если нет? В этом случае у нас будет наполовину сохраненный пользователь. И решать такие проблемы придется руками.
Да, пример надуманный, но ситуация страшная. Программирование по контракту и валидация контрактов классов -- единственное что может спасти код от хаоса(если, конечно, вы не любите просыпаться от PagerDuty по ночам)

#eda
Тут интервью с Udi Dahan'ом(евангелистом CQRS и т.д. и т.п) подъехало: https://www.infoq.com/articles/cloud-transactions-dahan Много всего про messaging, consistency и транзакционность.
Кстати у дядьки крутой блог, стоящий того что бы его упомянули хотя бы из-за http://udidahan.com/2011/04/22/when-to-avoid-cqrs/

Chernobyl DevOps: Software Engineering, Disaster Management, and Observability -- статья о том, что DevOps культура может вынести из Чернобыльской трагедии.

+ обсуждение на Reddit. Не конкретно этой статьи, но скорее впечатлений systems engineers от просмотра сериала от HBO

#culture #devops

Статья от Фланта про гитОпс: https://habr.com/ru/company/flant/blog/456754/ как всегда подробно и с личным опытом)

Что мы в Авито знаем о микросервисах?
Рассказывает Вадим Мадисон, руководитель разработки System Platform → http://bit.ly/2ZDqiLS

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

Ж -- жаваскрипт)) https://link.medium.com/s1hNUvEdJX

#shitcode
Как написать самый хреновый софт, который только видел мир. Часть 2
Из всех мейнстримовых принципов проектирования, мейнстримового SOLID'а, всяких DRYев и прочих GRASP'ов, я наиболее нежные чувства питаю к KISS(keep it simple, stupid) или, по-русски, принципу наименьшего удивления. Как-то коллега сказал: "пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте", но, тема в том, что все эти изменения входных параметров по ссылке(ну ее кортеж же возвращать?!), передача нескольких значений как разделенных запятыми строк, название переменных в стиле item1, item2 и т.д. заставляют глаза даже психически здорового человека наливаться кровью.
Более того, этот код не сможет опознать даже сам автор через пару недель.
Хз что мотивирует писать такое, но лечится это даже не ударом книжки Макконела по голове, а соблюдением четырех основных правил(два из которых можно забить в линтер):
1. Иммутабельность -- тут все просто. Надо стараться, по возможности, оперировать неизменяемыми объектами и переменными(это касается как кода, так и API, если что! Безумно бесят GET-запросы, которые insert'ы в базу делают)
2. Чистота -- результат функции должен быть детерменирован(т.е. при передаче одних и тех же параметров мы гарантировано получим один и тот же результат). Если это не возможно, то это должно быть понятно из названия функции/метода. Это правило лежит в основе CQS Бертрана Меера.
3. Адекватный нейминг. Тут все ясно, но на всякий случай: из названия должно быть понятно что лежит в переменной, из названия должно быть понятно что делает функция
4. Закон Деметры. Спорная штука, но ИМХО, очень сильно улучшающая читаемость кода, если применять без фанатизма

Понятно, что в начале придется много сил затратить на ревью, холивары с "и так сойдет" и т.д., но результат стоит того

Котаны, если кто не в курсе, то вчера по всем восточным европам моргал интернет. Причина -- BGP оптимизации, которые просочились "наружу". Естественно, проблема затронула всех провайдеров облачных сервисов, в том числе и CloudFlare.
Меня в данной ситуации удивляет не столько масштаб бедствия(с каждым бывает), сколько поток токсичности со стороны сообщества в сторону Cloudflare. Говно случается! Пару месяцев назад Яндекс.Облако потеряло клиентские виртуалки. За несколько дней до этого Azure уронило DNS. Про фиаско GitLab с Postgres до сих пор все вспоминают. Цимес в том, что аварии неизбежны и все что можно сделать пост-фактум -- это максимально быстро восстановиться и, конечно же, научиться на своих ошибках.
P.S. блейма от Cloudflare в сторону Verizon я тоже не понимаю
P.P.S. вот статья-постмортем от cloudflare про причины аварии: https://blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today/

#shitcode
Как написать самый хреновый софт, который только видел мир. Часть 3
Учитывая современную тенденцию к распределенным архитектурам, кол-во команд разработки в кампании неуклонно растет. А учитывая, что статичность этих команд до сих пор остается влажной мечтой разработчиков, то девелоперу часто приходится вникать и вносить изменения в код, автором которого он не является. Ситуация сильно упрощается, если все команды придерживаются "принципа наименьшего удивления", о котором я писал выше, но, порой и этого бывает не достаточно.
Представьте ситуацию: вы залазите в код сервиса, предположим, написанного на java, а там весь код на венгерской нотации. Пример смешной, а ситуация страшная) Особенно учитывая, что для всех мейнстримовых языков есть уже выработанные конвенции.
Кароч, котаны, есть конвенции, их придумали далеко не лохи и следовать им очень даже стоит(аргументы "я привык" не оч канают, особенно когда ваш венгерский джава код вылезет на собеседовании). Более того, стоит согласовать конвенции(включая кастомные правила) с коллегами и раз и навсегда зашить их в статический анализатор и вуаля! кол-во багла и wtf\сек со стороны коллег резко сократится

​​Курс по документированию REST API на русском языке.

Тут случилось что-то невероятное. Курс Тома Джонсона по документированию REST API переведён на русский язык. Денис Старков сделал это сам, один, за полгода работы.

Оригинальный Documenting APIs: A guide for technical writers and engineers — наверное, самый полный и полезный открытый курс по документированию. Он рассчитан на технических писателей, разработчиков и студентов. Для техписателей этот курс — точка входа в документирование кода и API, очень интересную область работы, за которую ещё и неплохо платят. Разработчики из этого курса научатся структурировать информацию и понятно описывать свой код и API.

Читайте переведённый курс по документированию REST API, рекомендуйте его коллегам, ставьте звёзды репозиторию. Шлите пуллреквесты с правками, наконец. :)

Факапы, история 3

Очередная история про гугл и k8s. Как вы помните, у гугла существуют maintaince window, во времена которых он без предупреждения может ради обновления версии куба просто положить весь ваш кластер. Да, чтобы вы понимали, не реже раза в месяц ваши ноды будут падать. Может быть все сразу, а может по очереди. Может сегодня одна, а завтра другая. Может она поднимется за 2 минуты, а может за 25. Вы можете заплатить чуть больше денег и разнести ноды по разным регионам, но в любом случае что-то когда-то будет падать. Поэтому делать решение без репликации никак не получится, всегда должна быть реплика, которая обслужит клиента.

Эта история будет про etcd кластер. В кубе etcd можно запускать при помощи etcd-operator. И довольно-таки ошибочно думать про такой кластер, как про кубовское решение с этими всеми его шедулерами. Т.е. чтобы вы понимали, когда устанавливается оператор - он делается по всем канонам куба. Вы выкатываете helm, создается deployment, куб будет следить сам за тем чтобы оператор работал. На этом всё. Вы спросите, а откуда же тогда берется кластер? Так вот, после выкатки оператора мы должны принести в кластер один или несколько объектов под названием EtcdCluster. В котором описывается название, размер и версия etcd кластера. Оператор перехватывает событие создания такого объекта, считывает параметры и создает поды нашего кластера в указанном количестве. Что здесь кажется странным? С точки зрения k8s поды без deployment\replicaset это просто некоторый висящий в воздухе контейнер, который можно убить и никто не заплачет. Вот и получается, что всю заботу о том чтобы контейнеры кластера работали берет на себя etcd-operator.

Теперь скрестим ситуацию из первого абзаца со вторым. Если гугл кладет все ноды, то у нас падают все поды кластера. И тут самый интересный момент. Их никто не переподнимет после того как ноды рестартанут. Почему? потому что в etcd-operator заложена такая логика. Нет персистенса - нет переподнятия. В итоге, для того чтобы избежать этой попоболи в CRD нужно добавлять примерно такие строки:

      kind: "EtcdCluster"
      spec:
        pod:
          persistentVolumeClaimSpec:
            storageClassName: XXXXXX
            accessModes:
            - ReadWriteOnce
            resources:
              requests:
                storage: YYYYYYY

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

#fuckup

#infrastructure #devops
Инструкция как поднять пром с таносом и всем-всем-всем:
https://itnext.io/monitoring-kubernetes-workloads-with-prometheus-and-thanos-4ddb394b32c

Сегодня про Istio:

- Пошаговый гайд установки Istio (с помощью Helm)
- Istio оператор от Banzaicloud
- Обсуждение первой статьи на Reddit

- Сравнение Istio и Linkerd

#kubernetes #mesh #istio #linkerd

Поработал? Убери!

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

Делать это нужно так же, как в на верстаке в мастерской: поработал — убери. Оставляй после себя рабочее место чище, чем было до тебя. Видишь бумажку на полу — подбери и выкинь. Видишь говнокод — перепиши.

Если ваш ПР ничего не улучшает для других — это плохой ПР.

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

Если у вас на проекте все начнут следовать этому простому правилу, то ваша кодовая база начнёт ухудшаться гораздо медленнее.

Когда говорят, что механическая коробка передач авто позволяет лучше контролировать автомобиль и экономит топливо, имеют в виду -- обеспечивает возможность лучше контролировать и экономить. На практике 90% "ездоков" умеют на ней разве что на светофоре не глохнуть, а про экономию хорошо показывают тесты Mercedes - те и вовсе отказались делать "на ручке", потому что автомат пролезает в экологические нормы, а средний человек за баранкой - не очень.

Но почему-то про мир программистов так не размышляют.

Юнит-тесты не делают код надёжнее и дешевле вдолгую - они обеспечивают возможность это сделать. Но на практике 90% тестов проверяют "1+1=2" и такое похожее. 9 из 10 разработчиков не открыли НИ ОДНОЙ книги по разработке юнит-тестов.

Или ещё есть подход: комментарии зло, т.к. это значит, что код плохо понятен. На практике почему-то существует непоколебимая уверенность автора, что все (а уж автор - и подавно) умеют писать понятный и без комментариев код. И потому не оставляют комментариев!

Тысячи таких примеров.

#shitcode
Как написать самый хреновый софт, который только видел мир. Часть 4
Никогда не удаляйте старый код! Обросшая ненужным функционалом, распухшая до пары десятков гигобайт кодовая база выглядит гораздо солиднее чем эти ваши хайповые микросервисы! А какое уважение внушает 20минутный билд! Просто упиваешься этим трепетом и ужасом в глазах коллег!
Зачем вообще что-то удалять?! Если не нужно, то, вообще-то, человечество изобрело комментарии. Вдруг потомкам пригодится! VCS есть? Ну и что?! Это еще надо искать потом, ветки переключать! А тут все рядом. Ваще, лучшая документация -- код, это всякий подтвердит, а еще лучше, если это будет вся история кода с 1947года!
Кароч сарказм-сарказмом, но корреляция между хреновым кодом и кол-вом брахла в кодовой базе явно имеется. Так что, коллега прав: поработал -- убери!

​​Написал тут небольшую заметочку (очень общую) о своём опыте приседаний с Kubernetes

Из первых рук, так сказать

#kubernetes

11 советов для тех, кто использует Redux при разработке React-приложений

https://habr.com/ru/company/ruvds/blog/456336/