С большим удовольствием узнал, что руководство разработкой в 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.

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

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

​​Когда вы работаете с большими нагрузками в AWS, возникает потребность иметь перед глазами простую визуализацию.

У AWS есть инструмент под названием CloudFormation Designer, который может генерировать шаблон из интерактивной карты и наоборот. Аналогичный функционал выкатил LucidChart, модифицировав его в поддержку сторонних провайдеров. Очень круто и удобно (если не считать того, что нужно какому-то левому приложению на левом сервере давать доступ к своему аккаунту). Все это имеет свои ограничения и не может покрыть всех требований.

И вот под фанфары сам вендор выкатывает новое прекрасное решение, разработанное в закромах AWSLabs. Бросая все, я бегу на сайт имплементации и вижу квинтессенцию шуток про запуск Wordpress на облаке Амазона.

Итого, для того чтобы получить визуализацию моей нагрузки мне понадобятся: CDN (но... зачем?), GraphQL и RESTful API, IdP, пачка Lambda-функций, графовая база данных Neptune, контейнерная оркестрация с набором задач, build система (?!), AWS Config, DynamoDB и что еще я не разглядел на этой картинке.

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

Собственно вот не так давно заведенный Твиттер. Туда я буду писать короткие и внезапные мысли (и не только рабочие), а также выкладывать ссылки на свои посты тут и на Медиум. Вестись он будет на английском, но русским брезговать не собираюсь. 🙂

Вдобавок, то чего не ждали ни вы, ни даже я - 5ая глава глубокого погружения в AWS IAM.

Как получить ключи доступа в AWS при наличии аккаунта в Google? Как использовать тэги для тонкой настройки доступа к ресурсам? Зачем версионировать политики? В этой главе я отвечаю на эти и другие вопросы.

​​Дорогие читатели, я рад сообщить, что мне официально был присужден статус APN Ambassador.

Что это означает? Из хорошего - будет много контента. Правда контент будет в большой степени про AWS. Из очень хорошего - мне выделили необходимых ресурсов, чтобы я мог экспериментировать!

Пишите мне в вязанный свитер, какие хитровыделанные вещи вы хотели попробовать сделать на AWS, но стесняетесь попасть на неприятно большой счет!

Самое хитрое, интересное и стремное (но про то, что можно и написать) будет мною изучено, развернуто и описано.

Со всеми регалиями тому безумцу, в чьей голове эта идея и родилась. 🙂

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

В условиях пандемии это особенно проявляется с теми, кто работает из дома. Можно сказать, что это мутировавший рудимент Синдрома Самозванца с щепоткой Чувства Вины и нотками Прокрастинации.

Или обычный трудоголизм.

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

Своим приятелям и друзьям, кто обращается ко мне с похожей жалобой, я делаю простое замечание: "Мертвецы и больные карьеру не строят."

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

Сдал только что AWS Certified Database - Specialty.

Ожидание:
- Тонкая настройка Read Replicas
- Рассчитать консистентность Aurora Global Database в разных сценариях
- Всякий high load с моделированием данных

Реальность:
- Как подружить корпоративный AD с MS SQL Server
- Как затолкать Oracle в AWS
- RDS
- RDS
- DynamoDB
- DynamoDB
- DynamoDB
- DynamoDB
- Еще DynamoDB

Ну раз хотите динаму, будет вам динама!

Автор уходит на отдых и скоро вернется с первой главой Amazon DynamoDB Deep Dive.

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

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

Да и мульти-кросс-гиперфункциональных людей (этакие Т-shape на стероидах) на рынке нет от слова совсем, надо перекупать у конкурентов. А наберете вы очень дорогих спецов, сверху еще потратив на их поиск и выкуп… Наверняка захотите на серьезный инфраструктурный внутряк или core business.

Что я понял из опыта - Скрам с его спринтами хорошо работает только для небольших проектов строго на микросервисах (где изменение завозится в течение пары недель), либо на молодых продуктах, судьба которых не определена. Инфраструктурщина и системная инженерия лучше работает по Канбану, причем по формуле “Это будет сделано, когда будет сделано.”

С адекватными и честными сроками, разумеется.

Кого не пугает английский язык, приходите на AWS Community Day Amsterdam.

Я и остальные Летучие Голландцы будут там вещать.

Ваше воскресное чтиво - первая ступень в нашем глубоком погружении в Amazon DynamoDB.

Что есть DynamoDB, в чем ее отличие от других NoSQL СУБД, как создать таблицу и что-то в нее записать - в этом обзорном материале.

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

Дальше будет гораздо сложнее и больше.

Я еще тут. И хочу поговорить с вами про аутсорсинг.
https://telegra.ph/Pro-greblyu-na-galerah-10-12

Немного контекста: у меня с Мишей (@anykeynotes) был недавно разговор про работу в аутсорсе, который стал его постом выше. Продолжением беседы будет мой ему ответ.

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

Говорить за всех аутсорсеров не берусь, использую только свои условия, информацию, которой владею, и говорю только о своем работодателе. Вместо слова “галера” я буду применять “консалтинг”, коим EPAM de facto и является.

Мнение, разумеется, только мое, и говорю я только от своего имени.

“Весь бизнес компании строится на том, что клиенту вас как сотрудника продают с наценкой, …”

Не совсем. У консалтинга есть определенное портфолио проектов с экспертизой в разных областях бизнеса. Заказчик приходит с запросом “Хочу Х”. Консалтинг “отгрузит” необходимое количество рук и мозгов, которое может реализовать желаемое в определенные сроки. Поскольку требования могут на ходу меняться (мы живем в реальном мире), то договор заключают как раз по месячной работе кадров разных профилей и специализаций. Отсюда и наваждение, что консалтинг это body shop.

“Клиент не оплатил вовремя, клиент долго стартует проект, у клиента кончились деньги и объем проекта уменьшился, у клиента резко сдвинулись сроки в меньшую сторону - всё это риски, которые несёт компания.”

1. Эти риски оговариваются в контракте. 2. Эти же риски могут присутствовать в любом внутреннем проекте большой компании с бюрократией, бюджетами и прочими прелестями enterprise-сектора. Смотрим “кладбище Google”.

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

Не класть все яйца в одну корзину вполне логично, но ни один менеджер не станет назначать 100% billable сотрудника на несколько проектов. В теории, я могу договориться о работе на нескольких проектах одновременно (двух или трех), что приведет к тому… что я не буду работать ни на одном. Это не принесет пользы ни мне, ни работодателю, ни заказчику.

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

“Единственный риск, который компания не может хэджировать - сроки сдачи проекта. Овертаймы в аутсорсинге будут всегда.”

Вздор. Срок контракта != Срок сдачи проекта. Если в проекте меняются или появляются новые требования, сроки сдачи всегда пересматриваются, и нормальный заказчик на это идет.

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

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

Действительно, решение о выходе в промышленную эксплуатацию принимает program/project board (ну а кто же еще). Это решение принимается на основе десятков ПМИ - performance test, dry-run и прочих, которые являются маркерами technical readiness.

Вдобавок есть еще operational readiness, при котором эксплуатация заказчика подписывается под тем, что готова обслуживать проект на первой и второй линии поддержи. Эксплуатация, к слову, хоть и не является членом program board и по сути обладает правом Вето.

—

Дальше идет то, что я просил Мишу раскрыть, а именно так называемое “галерное мышление”. Про это поговорим чуть позже.