Итак, я обещал вам конкурс, я даю вам конкурс!

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

Первая книга уйдет тому, кто напишет интересную вводную статью, вторая - более продвинутый материал (максимум жести).

Условия следующие:
1. Статья должна быть на английском (выкладывается на Medium) или русском (выкладывается на Хабр) языке.
2. Если статья на русском, в ней даем ссылку на этот канал. Если на английском, то ссылку на профиль в Medium (так я пойму, что статья писалась для конкурса).
3. Никакого плагиата и переводов, пишем годный авторский контент!
4. Пишем именно технические статьи - про всякий Agile и DevOps написано достаточно.
5. Тема на ваш вкус. Мне одинаково интересно читать про все, будь то описание алгоритма сборщика мусора в Go, особенности типов виртуальных машин в GCP, запуск кластера ScyllaDB в EC2 AutoScaling groups на Spot'ах, сравнительный обзор MPLS и SDN, или как работает NUMA... Да хоть паттерны проектирования систем на Perl!
6. Объем материала - 10 минут на чтение (но можно и дольше, главное чтоб интересно).
7. Постарайтесь не писать How-To, их и так пруд пруди.
8. Статьи должны быть удобочитаемы и хорошо оформлены. Статьи для "новеньких" должны быть понятны хоть студенту, а статьи для "дедов" должны содержать ссылки на пояснения узкоспециализированных терминов или источник в документации.
9. Как статья попала в публичный доступ, сразу отправляйте ее мне (в телегу или на почту), я занесу ее в табличку. Кто первый отправит, за тем материал и закрепляется.
10. Срок приема материала до 28.07.

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

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

Запись моего стыда можно посмотреть тут, а те куски кода, что я осилил написать за два часа тут. Особенно полезно тем, кто зачем-то называет меня мэтром.

Код на Go обязательно допишу, незакрытый гештальт не дает уснуть.

Надеюсь, стрим был интересным! Я открыт к предложениям для будущих эфиров.

@pzartem делиться перлами со вчерашнего стрима: https://clips.twitch.tv/RoughColorfulMageCharlieBitMe

Насчет вчерашних тупок - удалось таки разобраться.

В Python я использовал абстракцию boto3.EC2.Instance, которая возвращает объект с нужными мне полями.

А вот вызов метода DescribeInstances, что в Go, что в Python возвращает мне массив объектов с типом данных Reservation!

Что это именно за объект, я пока не могу понять, а беглый поиск не дает нужной информации... Не думаю, что речь о reserved instances, скорее тут имеет место быть capacity reservation. Если вы не используете их, скорее всего вам присваивается capacity reservation по умолчанию...

Код залит в репозиторий, а я посмотрю более элегантный способ достать нужные данные не залезая в Reservation. Дополнительно я хотел рассказать про работу с SAM, но на это не хватило времени, а делать отдельный стрим про это... ну не очень хочется (маякните мне, если хотите послушать про SAM)

Второй момент - бесконечная возня с указателями в AWS SDK для Go. Поскольку я прихожу из мира Python, где работа с указателями скрыта под капотом CPython, для меня это было в новинку.

У указателей есть полезное преимущество: их грамотное использование помогает экономить память и не дублировать одни и те же данные между методами в коде.

Если у вас есть какая-то строка, структура или иной тип данных, то зачем вам ее таскать туда и сюда, если вы можете забрать адрес этого объекта в памяти (чем и является указатель) и передать его куда надо? С этой точки зрения имплементация AWS SDK для Go вполне эффективна с точки зрения локальных ресурсов.

Классный язык все-таки, этакий С для ленивых архитекторов, вроде меня. И отдельно приятно вновь чувствовать себя глупым (даже на камеру).

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

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

Вместо "писательского" конкурса я предложу вам сыграть в игру. В игру, вдохновленную обеими частями S3Game - отвечаем на вопросы, находим коды, двигаемся дальше.

Кто дойдет от начала до конца быстрее других, получит приз.

Как вам такое?

​​Another Wednesday, another stream!

На этот раз будем заниматься ПИРФОРМАНСОМ амазоновских хранилок!

Среда, 15 июля, 20.00 по Москве (19.00 по Амстердаму).
Язык: Английский (для меня, вы можете говорить хоть на арамейском).

Подписывайтесь, ставьте лайки, готовьте помидоры!

Дабы не потерять событие, держите ICS:

Can you release when the GitHub is down? (c) Adam Surak, Own your reliability.

^ Да, я уже давал ссылку на этот доклад. Судя по шуму, никто на своих ошибках не учится.

Начинаем через час!

Ссылка на запись эфира.

Я возьму некоторый перерыв в вещании и вернусь к вам, как только у меня будет готова игра и другой полезный для вас контент (и нормальная гарнитура)!

Между делом я планирую устроить стрим-лекцию про CloudFormation, SAM и CDK c AMA сессией после! Вопросы можно будет задать заранее, на них я буду отвечать в эфире, а вы сможете услышать ответы в записи, если вдруг не сможете попасть на эфир.

Видеозаписи предыдущих стримов я выложу на Youtube канал! Дело за малым - завести Youtube канал.

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

Поговаривают, что я буду на DevOpsConf 2020.

Не счесть, сколько всего я хочу вам рассказать интересного, но я лишен либо времени, либо ограничен NDA.

А пока обещанный без 5 минут 3 года назад разбор производительности хранилищ данных от AWS. Специально для любителей текста и тех, кто пропустил не только стрим, но и его запись.

Что вы сейчас прочитаете, не принесет вам удовольствия.

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

Тем не менее, я хотел бы обратиться к моим читателям из Беларуси и им сочувствующим.

Никто и ни при каких условиях не имеет права запрещать вам выражать свое мнение. Равно как и я, не связанный с Беларусью никакими тесными связями, не могу вам что-то советовать и тем более призывать. У меня нет никакого понимания происходящего в стране, и мне остается только наблюдать те ужасы, что летают по соцсетям.

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

С большим удовольствием узнал, что руководство разработкой в LinguaLeo в один момент психануло и решило выкопать труп хранимых процедур.

Для моих читателей, кто возможно не застал этот интересный концепт, немного археологии. Хранимые процедуры имплементируют порядок выполнения в языке подобном языку запросов и позволяют реализовать бизнес-логику на уровне хранилища (чаще всего реляционного). То есть наши любимые SELECT * FROM bar WHERE foo = 1; можно было завернуть в LOOP и даже применить IF.

Из плюсов - у "хранимок" много вычислительных ресурсов (серверы СУБД нередко очень большие), отсутствуют сетевые задержки и имеется практически прямой доступ к данным. Оптимизировать их по производительности приходится редко, разве что нужно уметь в эффективный SQL, да насоздавать индексов, где положено.

Из минусов - их довольно тяжело тестировать без реальных данных, очень сложно журналировать и отслеживать их корректное выполнение, обработка исключений опять же на РСУБД.

По моим наблюдениям, инженеры стали избегать ХП с момента развития NoSQL и появления новых видов хранилищ данных (ключ-значение, колоночные, документные)... Чего греха таить, многие разработчики и SQL-то не знают и не хотят учить. Тем не менее, разработчики РСУБД обязательно включают ХП в список функционала, чтобы не отказываться от определенных ниш рынка (банковский сектор, госструктуры и т.д.).

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

Но у меня все же вопрос - какую проблему все таки решало руководство? Точно ли дело в медленном развитии платформы?

ХП сами по себе инструмент очень мощный, но имплементировать их надо с умом. Иначе будет вот так.

За ссылку спасибо @tech_b0lt_Genona.

Работа архитектором в моем случае - это работа менеджером, который принимает решение по вопросам "Как?". И раз уж работа менеджерская, то за полгода на новой должности я провел на встречах и звонках больше, чем за предыдущие пару лет.

Я уже писал, что переход с "обсудил-нарисовал-имплементировал" на "обсудил-нарисовал-ОТДАЛ" был очень неприятным. Спроектировать симпатичное решение в редакторе (а в своей голове и реализовать), а затем запланировать встречу с разработкой... словно передаешь набросок другому художнику в надежде, что тот напишет картину точь-в-точь, как ты себе ее представил.

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

Но самым занимательным стал случай, когда я принялся за самую что ни на есть девопсно-инженерную задачу, в рамках которой нужно было работать с Terraform, Jenkins и даже с Kubernetes, и понял - все, интерес пропал.

Как и в какой момент случился этот перекос я не скажу, но скажу точно, что в конце сентября меня можно будет наблюдать на экранах во время трансляции DevOpsConf 2020, где я буду рассказывать как раз про развитие специалистов, и более того - я сяду с самим Александром @demeliorator Чистяковым за виртуальный стол и буду обсуждать облака.

Буду рад увидеть там всех желающих, а пока ожидайте небольшой материал про делегирование.

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

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

Вот нужно вам, например, закатить мониторинг, а вы его уже давно не трогали. Можно потратить немалое времени на поиск различных тулов, их поковырять, поднять, посмотреть, исходники изучить... Или можно делегировать право принять решение ведущему инженеру, передав ему свое "видение" (SLA/SLO/SLI/RED/4 золотых сигнала, при желании еще подарив одну никому неизвестную книжку), и пусть он сам все нарисует, запланирует, нарежет задачи и распределит в команде. Встречайтесь раз в неделю да синхронизируйтесь.

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

Поэтому и делегата надо выбирать с умом. На том конце обязательны ответная заинтересованность и минимальный набор экспертизы, но мало того - должно быть еще и доверие.

Вот с доверием и происходит самое интересное. Заинтересованность-то легко получить: кому-то просто хочется набрать опыт с инструментом или технологией, кого-то можно мотивировать материально (прямо или косвенно). Но доверие не появляется на пустом месте, его надо заработать.

И надо быть очень глупым управленцем, чтобы думать, что доверие должен заработать делегат - вам тоже необходимо им обзавестись.

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

Искренне радуюсь за людей, которые получает настоящее удовольствие от работы в коммерческой разработке.

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

Иногда грустно от того, что все самое крутое с точки зрения технологий уже придумали.

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

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

Другое дело сам подход. Идея многооблачного развертывания в том, чтобы не зависеть от одного единственного поставщика. Раз стоит такое требование, то надо использовать открытые решения вкупе со своими разработками, а от провайдера брать только вычислительные мощности (например, виртуальные машины или планировщики задач). Ну и зачем тогда облачный провайдер, если можно закупиться дешевыми мощностями Servers.com, Hetzner, DO?

Есть еще имплементация, когда на конкретном провайдере разворачивается конкретное решение, потому что именно этот провайдер лучше решает задачу. Не секрет, что GCP быстрее и дешевле обрабатывает большие объемы данных, а значит логично запускать там BI системы, AWS предлагает широкий спектр узкоспециализированных услуг, а у Azure отличная интеграция с on-prem системами. Бизнес может раскидать свои продукты по трем провайдерам и даже сынтегрировать их друг с другом, только это не многооблачное решение, а просто распределенные по разным местам звенья одной цепи. Да и ваше предприятие зависит не от одного, а уже от трех поставщиков.

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