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

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

Согласно отчету Virtana: "The report claims that enterprises that suspended cloud migration journeys during the pandemic experienced two and a half times more IT outages than firms that continued their transformation."

Удивительное время. Либо тратишь много денег за то что едешь в облако, либо за то что не едешь.

С другой стороны тоже логично - те, кто продолжил активные проекты, обладают достаточным ресурсом. А с инфраструктурой и квалификацией кадров у таких контор, как правило, нет проблем.

Возвращаясь к разговору про архитекторов и их надобность.

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

В посте про AWS CSA Pro я говорил, что сам экзамен заставляет выбирать из множества стульев с пиками и прочими непотребствами. И это действительно часть работы! Захотите сделать лучшую архитектуру в мире - потеряете все полимеры со сроками - а значит нужно искать где и чем пожертвовать, на какие уступки пойти, и как быть с техническими ограничениями. Неплохо еще думать за других и постоянно задаваться вопросом: "А не бахнет ли? А вдруг все-таки бахнет?".

Следующий момент - кругозор. Не нужно разбираться аки Боженька во всем (не сможете), но имеет смысл обладать эрудицией по разным темам: компьютерные сети, Windows/Linux, разные облачные провайдеры, разные инструменты и языки программирования, СУБД и т.д. За эрудицией идет думалка и возможность быстро "заскочить" на нужную тему и в сжатые сроки обрести необходимый багаж знаний.

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

Из литературы и полезных материалов, можно прочитать следующее:
- Fundamentals of Software Architecture: An Engineering Approach - полезно как раз для перехода из инженеров в архитекторы.
- System Design Primer - тот самый всем известный набор инструкций для прохождения архитекторских и дизайн интервью. Говорят, что его достаточно, чтобы пройти секцию архитектуры в Яндекс.
- The Architecture of Open Source Applications - не нуждается в представлении, просто идите и читайте, как придумали Nginx.

Стартуем через 60 минут!

Понравилось?

Если вдруг не смогли присутствовать вживую или опоздали, то есть запись!

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

Прилетело письмо от поддержки 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 канал.

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