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

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

Вместо "писательского" конкурса я предложу вам сыграть в игру. В игру, вдохновленную обеими частями 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 системами. Бизнес может раскидать свои продукты по трем провайдерам и даже сынтегрировать их друг с другом, только это не многооблачное решение, а просто распределенные по разным местам звенья одной цепи. Да и ваше предприятие зависит не от одного, а уже от трех поставщиков.

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

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

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

Взять например тот же Terraform, который гордо нес звание cloud-agnostic инструмента для развертывания систем на любом провайдере. Много раз я слышал, что он позволяет не привязываться к одному провайдеру, а "просто развернуть инфраструктуру в другом облаке". Это, разумеется, не работает.

Многоплатформенность TF обеспечивается провайдерами, провайдеры - интерфейс-обвязка между декларативной инструкцией Terraform и API облачного поставщика. Действительно, вы можете сменить значение провайдера с одного на другое, но вдобавок придется переписать декларации всех ресурсов, поскольку атрибуты тоже отличаются.

Как результат, из cloud-agnostic у Terraform только его DSL.

По-настоящему cloud-agnostic решение будет автоматически определять, с каким облаком оно будет работать, и подключаться к нужным сервисам тоже само. AWS? DDB, Aurora и т.д. GCP? BigTable и Spanner и пр.

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

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

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

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