Прилетело письмо от поддержки Packt: один из читателей обнаружил в Mastering CloudFormation ошибку. В главе, где я через CDK создаю экземпляр RDS, есть следующий кусок кода:

rds_instance = rds.DatabaseInstance( 
    self, "Rds", 
    master_username="user", 
    master_user_password=pw, 
    database_name="db", 
    engine=rds.DatabaseInstanceEngine.MYSQL, 
    vpc=vpc, 
    instance_class=ec2.InstanceType.of( 
        ec2.InstanceClass.BURSTABLE2, 
        ec2.InstanceSize.MICRO), 
    removal_policy=core.RemovalPolicy.DESTROY, 
    deletion_protection=False)

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

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

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

Breaking change, мою задницу.

Однажды мне пришлось в срочном порядке написать маленькое приложение, которое показывало список приватных IP адресов узлов в определенном кластере. Узлы были в AutoScaling группе, так что мое приложение опрашивало API и возвращало список в формате JSON.

Изначально я хотел написать его на Go, но сроки горели, а я тот еще мамкин гофер: за два часа разве что понял, как инициировать клиента в SDK. Ключ с Usage Policy для API Gateway так вообще руками в консоли создал (срамота)!

Предлагаю следующую тему для эфира - я напишу это приложение на Go и расскажу особенности AWS SDK для этого языка. Ну и про SAM с CFN расскажу, само собой.

Произойдет это в ближайшую Среду 8 июля в 20.00 по Москве (19.00 по Амстердаму).

Ну как напишу - если успею за время эфира! Не узнаете от меня чего нового, так посмотрите на то, как полыхает мой зад.

И one small thing: во время эфира я объявлю КОНКУРС, где буду разыгрывать бумажную копию своей книги (разумеется с автографом)!

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

Mail.Ru "партнерится" с AWS о выходе на рынок РФ.

Ожидание: регионы в России, равертывание по китайской модели, на худой конец Outposts.
Реальность: K8s в федерации.

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

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

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

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

Условия следующие:
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.