Непопулярное мнение: большинство противников гибких методологий (в частности Scrum, Kanban, Scrumban и SAFe) не имеют опыта работы с ними.

Ваше выходное чтиво: пост от Кори Куинна (известного в определенных кругах амазонщика) о том, как переплюнуть AWS. Интересный опус и более того - мне есть что на это ответить.

Оставайтесь на связи.

Обещанная ответка: https://medium.com/@thomas.storm/how-to-really-compete-with-aws-240052b74cba

Кто сегодня придет на меня посмотреть, напишите мне после выступления, интересует ваше мнение.

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

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

Сегодня мне удалось успешно сдать экзамен AWS Certified Solutions Architect Professional.

Как и следовало ожидать, этот экзамен - проверка на выносливость. 190 минут, 75 вопросов, вставать и отходить от ноутбука нельзя, проктор-экзаменатор непрестанно бдит.

Как и предыдущий экзамен (AWS Certified SysOps Associate) я сдавал "на шару" - без должной скрупулезной подготовки и зубрежки, надеясь выехать за счет своего опыта. За счет опыта и выехал.

Вопросы, в которых фигурировали AWS Organizations, CloudFormations и IAM, щелкал на раз - в этих темах я собаку съел, да и не только собаку. На некоторые вопросы я отвечал уверенно за счет того, что я с этим работал (AWS SMS, DMS, Athena, Glue). Если вы мало работаете с AWS, то экзамен будет сложный.

Из минусов: некоторые вопросы, как и следовало ожидать, продают AWS. К радости их было немного, да и продажа была не такая агрессивная, как была у меня на Certified Developer Associate.

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

Да-да, в CSA Pro есть вопросы, ответы на которые все "правильные", потому что решают поставленную задачу тем или иным образом (а вам нужно выбрать тот ответ, который лучше удовлетворит потребность вашего заказчика). Но есть вопросы, где все ответы ужасны, и нужно выбрать наименее ужасный.

Зачем такие вопросы есть в экзамене, мне не до конца понятно. Надеюсь, речь как раз о тех самых trade-off'ах, которые ожидают архитектора тут и там.

Скажите, что у меня стокгольмский синдром, но это лучший экзамен из всех, что я сдавал в своей жизни. На втором месте заслуженно останется экзамен по Операционным Системам (Н.А. Иванов one love).

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

Этимология термина "демон" в ИТ и UNIX не имеет никакого отношения к авраамическим религиям... Но когда это кого-то останавливало?

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

Я продолжаю придерживаться тех же взглядов, что и всегда: архитектор, как отдельная должность - абсолютно бесполезная трата денег. Это роль, которую могут брать на себя один или более человек, совмещая ее с основной деятельностью (разработкой, управлением продуктом, you name it).

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

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

Если вообще выявляются.

"Безсерверные" сервисы AWS'а часто не любят за сложность и дороговизну на больших нагрузках.

Пока я слушаю очень крутой доклад по оптимизации serverless приложений, держите полезную ссылочку.

Lambda Power Tuning прогонит вашу лямбду несколько раз на заранее заданных вводных и предложит наиболее оптимальную под производительность и денежки конфигурацию.

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

А если бы я вел стримы на Twitch, где ковырял бы всякое в AWS'е и не только, вам было бы интересно их смотреть?

Начало положено!

1-ого июля буду разгадывать непревзойденную головоломку непревзойденного @VasilyPantyukhin!

01.07.2020 19.00 по Амстердаму (20.00 по Москве).

Пока можете подписаться, поставить лайки и так далее.

Пандемия 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 вполне эффективна с точки зрения локальных ресурсов.

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