Как только мой канал стал становиться все популярнее (я считаю успехом уже то, что меня читают больше 100 человек), я стал следить за количеством подписчиков, шо за этими вашими бетховенами.
Цифра растет - эйфория, радость, тщеславие.
Цифра падает - самоанализ, паника, «я слишком часто пишу», «я слишком редко пишу», «я пишу херню».

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

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

И пусть я очень рад, что вы со мной, я не буду «фильтровать» контент (в этом и преимущество авторского канала).

Единственная гарантия, которую я вам даю - на этом канале нет и не будет никакой рекламы. Никогда. Это не значит, что в один момент у меня не появится мысль превратить вложенные усилия в доход, но до этого еще далеко, да и монетизировать я буду через какие-нибудь онлайн курсы собственного производства (если конечно мне будет чему вас учить).

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

Я не самый большой фанат киновселенной Марвел, но стараюсь ходить на все свежие фильмы. Не пасхалок ради (я в жизни ни одного комикса не прочитал, разве что “Утиных историй”, когда был совсем маленьким), а так - ради удовольствия от попкорно-жвачковой индустрии.

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

У Марвела есть такой супергерой Тор, комиксовый вариант того самого Тора - бога грома из пантеона северных богов. Скандинавская мифология для меня тема новая и приглянулась после просмотра множества сезонов “Викингов”.
Я всегда считал, что Тор от Марвела был таким (нервным, драчливым, выпендрежным и честолюбивым), потому что так решили его нарисовать американцы. Но как только я начал чтение “Северных Богов” Нила Геймана, я открыл для себя немало прекрасного. Удивить после греческой мифологии сложно (один только Зевс, спящий со всем, что двигается, и его стервозная злющая жена Гера чего стоят), но северные мифы СМОГЛИ.

Вот просто один из многих мифов в книге. Итак, у Тора есть могучий молот Мьельнир, и в один прекрасный день его у него воруют. Тор по обыкновению решает, что это проделки его брата Локи. Когда выясняется, что это не так, Локи отправляется на поиски утраченного оружия массового поражения и находит преступника.
Украл его повелитель огров Трюм, который взамен возвращения молота домой желает жениться на богине Фрейе (вообще Фрейю все время ставят на кон, бедная женщина). Когда Локи возвращается в Асгард, товарищи устраивают совет, на котором решают отправить Трюму невесту. В качестве невесты отправляют самого Тора, предварительно одев его в женские свадебные наряды и навесив на него украшений. Дабы тот не раскрыл себя, с Тором на земли огров едет Локи, обернувшийся служанкой. Во время свадьбы, как только появляется молот, Тор срывает свое прикрытие, убивает всех огров и великанов вокруг и едет домой.

То есть еще раз - могучий Бог Грома и его брат-хитрость-во-плоти переодеваются в барышень, чтобы вернуть себе оружие, словно персонажи дешевой американской комедии с Джимом Керри в главной роли. Неудивительно, что Марвел представляет их такими же.

Не знаю, кто и под чем придумывал все эти мифы, но они прекрасны.

А еще у Тора есть колесница, в которую запряжены два козла: Ворчун и Дробила. Обожаю северную мифологию.

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

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

Сразу скажу, если хочется денег - однозначно вверх. Какую бы узкую специальность вы ни выбрали, менеджеры (тимлиды и все что выше) зарабатывают больше. В таком случае надо учитывать, в какой специализации вы планируете расти. Условный Senior Data Scientist будет зарабатывать больше FrontEnd TeamLead’а потому, что тренды, спрос и заинтересованность бизнеса (тимлидов пруд пруди, а толкового человека, шарящего в machine learning попробуй найди).
С другой стороны из тимлидов гораздо проще вылезти на ступень повыше (CTO - технический директор). Особенно если быть тимлидом команды, которая отвечает за core business приложения.

Другая причина, по которой люди могут пойти “наверх”, заключается в желании менять (и меняться). Человек может видеть организационные или процессные огрехи, но повлиять на них может только косвенно (чаще всего он может повлиять только на своего тимлида). Повлиять на смежные команды, не говоря уже про менеджмент повыше, не позволяет недостаток компетенций, всяких bigger picture и административного ресурса. Тебя наняли писать код и пилить приложения, так пиши код и пили приложения. Менеджеру это дается гораздо проще.

Третья причина проста и прозаична - надоедает. Надоедает писать, ломать, дебажить, тестировать, релизить и прочее. Если для вас работа не хобби (как в моем случае), то какие бы новые и веселые технологии, инструменты и фреймворки ни появились, вам все равно станет ужасно скучно. Роль менеджера немного разбавляет технологическую рутину рутиной организационной. Нужно планировать бюджет, выбивать себе вакансии, создавать для каждого подчиненного план развития, да и в целом - больше заниматься people management (где people - это люди в принципе, и не только в вашей команде).

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

Что касается линейки развития как специалист, то тут все просто: джун, мидл, синьор, в некоторых конторах principal (это прям еще круче, чем сеньор). Градация повыше показывает вашу как техническую подготовленность, так и определенный кругозор и набор soft skills, например - умение договариваться или вести презентации.

Другим аспектом горизонтального роста может выступать то же желание смены обстановки или желание менять.
Например, вы работаете разрабом в backend, и вас очень не устраивает работа инженеров из эксплуатации: тикеты отрабатывают долго, приложения лежат, мониторинг орет, вот это вот все. Что можно сделать? Придти к ним на помощь (заодно наладите связь с коллегами по ту сторону баррикад). Получается тройной выигрыш - и новые вещи делаете (освоить DevOps tooling, честно скажу, дело не хитрое), и коллегам поможете, и бизнес будет доволен. Такой “переход”, даже временный, дает возможность освоить новую для себя сферу и прицениться к потенциальной работе.
Из DevOps энтузиастов - людей, которые не просто пишут код и/или помогают развертывать и обслуживать приложения, но и разрушают барьеры между “красными” и “белыми” - потом вырастают опытные консультанты и архитекторы, которые “повидали некоторое дерьмо”. За таких в Европе очень много платят.

Стоя на перепутье карьерного роста, задайте себе несколько вопросов:
- Нравится ли вам ваша работа?
- Почему вам нравится/не нравится ваша работа?
- Нравится ли вам ваш доход?
- Нравится ли вам ваша команда?
- Что бы вы хотели в ней поменять?
- Что бы вы хотели изменить в своей жизни?

Еще один опрос для людей, работающих с DevOps.
Сколько вы в культуре? Именно в культуре, опыт работы с CFEngine со дня релиза не считается, общий опыт тоже.

🙃 - до года
😐 - от 1 до 3 лет
😊- от 3 до 6
😈 - от 6 и больше

В 2016-ом году на свет вышла книга за авторством нескольких сотрудников Google под названием “Site Reliability Engineering: How Google runs production systems”. Безусловно, у Google есть чему поучиться: компания предоставляет сервисы для миллиардов пользователей, и на своем опыте я не могу вспомнить, когда хоть какой-то из них слег так же жестко, как S3 в 2017-ом.

Однако, если открыть поисковик от Google и поискать там истории уволившихся сотрудников, ушедших либо на вольные хлеба, либо в стартапы, либо в другие конторы, мы начинаем понимать простую истину, касающихся 99.99% все ИТ-гигантов: Google не всегда все делает “правильно”, и я сейчас не о десятках экспериментальных проектов, которые были закрыты по каким-то внутренним причинам, а сотрудники, болевшие ими, либо ушли, либо были переведены в другие проекты.

Однако Google как, наверное, самый престижный ИТ гигант служит примером для всей индустрии и, пусть и неосознанно, но обладает огромным влиянием на бесчисленное множество крупных, средних и маленьких контор. Некоторое время после выхода книги про SRE, о создании SRE группы заявил LinkedIn - социальная сеть для соискателей и работодателей.

В отличие от DevOps, SRE, на мой взгляд, выступает полноценным фреймворком, поскольку содержит в себе конкретный набор инструкций по внедрению и применению. Основным различием является то, что SRE подразумевает наличие отдельной команды, состоящих из очень крутых специалистов, шарящих и в разработке, и в инженерии. Главным фокусом является не только обеспечение максимально высокого uptime, но и предварительный расчет оптимального значения оного (когда сравнивают расходы на uptime с потерями от падения) - нет смысла гарантировать максимум 10 минут “лежания”, если это стоит миллиард долларов, а “спасаете” вы миллион.

Эксперты SRE переходят в команду конкретного продукта по запросу самой команды. По “правилам” команда может взять либо одного SRE, либо одного feature разработчика. Проще говоря - если максимальный headcount вашей команды 8 человек (и у вас уже 8 человек), и вы хотите себе одного SRE, то придется одного разработчика из команды прогнать. Таким образом скорость доставки обновлений приносится в жертву стабильности продукта.
Есть еще одна “фишка” SRE - взятый в команду SRE эксперт может по собственному разумению уйти из продукта, если (цитата) “он видит, что действия команды по стабильности не эффективны и не приносят пользы”.

Когда мы говорим о применении такого подхода в Google, мы понимаем, что SREшник не покинет продукт просто так - он подставит не только команду продукта, но и себя (его экспертиза ставится под вопрос). Но если представить такое в, простите, русской конторе, где, еще раз простите, царит бардак - получим человека с завышенным ЧСВ, который не смог с полпинка поднять uptime до 99.999% и, плюнув на все, свалил.

На одном митапе про SRE в Амстердаме, презентер сказал, что SRE - это одно из применений DevOps. Других применений он назвать не смог (потому что их и нет), да и сама фраза в корне некорректна. DevOps - культура, увеличивающая скорость поставки за счет уничтожения процедуральных bottleneck и автоматизации всего что можно. SRE - подход, снижающий скорость поставки в угоду стабильности, добавляющий ненужный стресс продуктовым командам. При этом нигде не упоминается, что DevOps не увеличивает стабильность приложений (эффективное взаимодействие команд разработки и эксплуатации дает необходимый эффект).

В общем, к чему я это все. Google сделал немало хорошего для ИТ индустрии и подарил нам множество продуктов для конечного потребителя. Но это не значит, что:
1. Все что делает Google - правильно.
2. Все должны работать так, как работает Google.

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

Который раз натыкаюсь на такие прикольные словечки, как sourcing и influencer. Думал, что же это такое, и пошел гуглить.

Influencer это такая звезда в соц сетях, которая обладает влиянием на свою подписоту. Дескать и точку зрения свою протолкнет, и товар впарит (если заплатить, конечно).
Раньше модно было говорить, что звезда кино и сериалов является “лицом компании” (как например “Чудо-Женщина” Гал Гадот стала лицом Хуавей - причем настолько удачным, что похвалила телефон Хуавей в твиттере, запостив этот твит с айфона). “Влиятель” (я не знаю, как это еще можно перевести на великий и могучий) не является чьим-то лицом официально. Просто левый такой человек, который говорит, что А лучше Б. А мы на это ведемся, потому что он крутой (как Тема Лебедев или Юра Вдудь).

С “сорсингом” поинтереснее. Есть рекрутер. Рекрутер обрабатывает входящие резюме, ведет собеседования, участвует в принятии решений (я уже писал, что рекрутер в Нидерландах влияет на решение по кандидату не меньше, чем сам нанимающий менеджер), отсылает офферы и холодные письма с приглашением на собеседование (даже если кандидат по умолчанию не подходит - так было со мной, пока я не переехал в Нидерланды).
А вот “сорсер” (исходник? ковырятель исходников? Гугл не знает, как такое перевести) занимается тем, что сидит в соц сетях типа LinkedIn и находит потенциальные таланты, которым, если что, можно предложить приехать поболтать. Проще говоря, человек, занимающийся этим пошлым явлением sourcing, это такой PreSale - найдет, изучит, отправит в работу рекрутеру (Sales). Сам “сорсер” на работу или пообщаться не зовет.

У нас были миллионы гендеров, теперь у нас есть миллионы “новых” ролей.

Теперь по поводу картинки. Для начала уберем пункты, которые действительно правильные:
1. Не просите их починить принтер - хочется верить, что в 2018-ом году бизнес-пользователи видят разницу между разработчиком и helpdesk специалистом. Ежели нет - бегите.
2. Не ставьте себя выше них - спорный момент, но есть кадры, которые придерживаются правила “Заказчик == Бог”. Если у вас похожий кейс, то смотрите п. 1.

Вот в принципе и все, что в картинке “правильно”. Перейдем к “неправильно”.

Сразу переходите к сути.

Есть такой термин User Story в Agile/Scrum. История отличается от конкретной задачи определенным уровнем абстракции и отсутствием технического контекста. Условная история выглядит так: “Как пользователь портала я хочу иметь кнопочку, которая будет показывать мне корзину в всплывающем окошке”. Как видите - никакой конкретики. Ни где должна быть расположена эта кнопочка, ни какого она должна быть цвета, ни надо ли показывать фото товара во всплывающем окне.
Такие задачи должны проходить через менеджера проекта или банду аналитиков, которые на выходе нарисуют конкретное ТЗ. Stakeholder (условно заказчик) не должен давать ничего больше, чем видение конечного результата. Мало того, заказчик не всегда знает, чего он хочет (что НОРМАЛЬНО), и это работа исполнителей превратить входную информацию в конкретную задачу через общение с ним.

Постарайтесь на самом деле понять, что они говорят.

Один вопрос - почему? Почему конечный пользователь продукта должна понимать технический сленг? Почему владелец продукта должен видеть разницу между jQuery и GraphQL? Если заказчик обладает такими же техническими компетенциями, что и разработчик, то зачем вообще нужен разработчик? На моей памяти разработчики, козырявшие техническими терминами на встрече с бизнесом, хотели потешить своей ЧСВ. Таких надо гнать, не задумываясь (Skilled assholes хуже рака).

Признайте, что они умнее вас (а они умнее).

На моей прошлой работе напрямую с разработкой работали менеджеры по продажам. Они ставили им прямые задачи по функционалу и следили за конечным результатом (этакое acceptance тестирование). Разработчики у нас были высшего разряда, профессионалы, окончившие бауманку и мехмат МГУ. Означало ли это, что они разбирались в торговле и управлению рисками на рынке commodity лучше “продажников”? Никак нет. Делало ли это продажников умнее разработчиков? Тоже нет. Коммуникация, построенная на модели “я умный, ты дурак” обречена на провал, вне зависимости от того, с какой стороны она исходит.

Дальнейший разбор будет позже. Надо и работать иногда. 😉

Продолжаю читать «Скандинавских богов».

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

Боги смеются и делают ставки на то, что раньше оторвется - борода козла или причиндалы Локи.

Продолжаем разбор.

Четко объясните, что вы от них хотите.

Заказчик хочет кнопочку. Хочет экран, отчет, dashboard, симпатичный график, поменять размер шрифта или цвет кнопок. Этого объяснения должно быть достаточно, а все уточняющие моменты должны выясняться аналитиками, руководителями проекта и самими разработчиками.
Я не могу представить себе ситуацию, когда заказчик приходит и говорит: “Сделайте прикольно.”

Дайте им больше времени, чем они просят. Многие вещи в программировании нельзя предвидеть.

Если команда сама написала продукт (а не получила его от другой команды), если текучка в команде небольшая, то программист по умолчанию знает свой продукт достаточно хорошо, чтобы оценить все риски разработки нового функционала. Риск нарваться на неизведанное высок, когда продукт плохо задокументирован. Если это ваш кейс, то стоит дать разработчикам время, чтобы хорошенько пройтись по продукту, написать документацию и комментарии к коду и API. Ежели продукт задокументирован от и до, а разработчик все равно не уверен, сколько времени ему нужно, то компетенцию разработчика можно ставить под сомнение.
Для команд, работающих над продуктом, будущее которого не определено, придумали Scrum и спринты, в которых команда гарантирует доставку определенного количества “фич” и не больше. Этот пункт - камень в огород исполнителя, а не заказчика.

Не отвлекайте их, даже если вам кажется, что они ничем не заняты.

Тут я частично согласен. Где-то в интернете есть пост, в котором человек посчитал, сколько времени ему понадобится, чтобы вернуться к мысли после того, как его отвлекли. В среднем это занимало 20 минут, и если человека отвлекать каждый час, то как минимум треть его рабочего дня будет уходить в молоко.
Однако возникают вопросы, которые можно решить быстро и для этого надо дернуть кого-то из backend/frontend/devops. Чтобы не мучать себя и других, команды на ежедневной основе назначают так называемого “дежурного” - того самого парня/девушку/подставьте_сюда_свой_гендер_по_вкусу, который/ая/ое большую часть дня проводит в чате, отвечая на разного рода вопросы.

Ну и финальное - умственная работа ничуть не проще физической, просто она менее заметна.

Как раз умственная работа заметна гораздо больше, чем физическая. Благодаря умственной работе мы знаем, что Земля круглая и вертится вокруг Солнца (хотя есть люди, которые в это не верят). Благодаря ей у нас есть персональные компьютеры, смартфоны, тиндер, фейсбук, стволовые клетки, бионические протезы, тезлы, космотуризм и биткоины.
Ни один человек в здравом уме не ставит под сомнение полезность какой-либо работы в принципе. Есть люди, которые говорят: “Фу, сидит за своим компом целый день и жалуется, что устал. Ахаха, устал сидеть”. Но есть и люди, которые говорят: “Ой таскал мешки за 5 рублей в час и жалуется, лучше б в тыжпрограммисты пошел, раз не нравится.”
Любая работа важна. Прогеры-илитки, смеющиеся над уборщицей, ничуть не лучше амбалов-качков, смеющихся на прогерами-илиткой.

Касательно охеревших разработчиков: @CarrolCox поделился очень классным чтивом на эту тему - https://medium.com/software-developer/how-to-be-really-awesome-at-your-job-and-not-be-a-complete-dick-53ff071f5b19

Ребята, количество людей, попавших в DevOps менее чем 3 года назад (согласно последнему опросу), наталкивает меня на мысль: «А не сделать ли мне свой вклад в развитие отечественной индустрии.»

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

Естественно речь идет на о махровых профессионалах, которые пишут Jenkinsfile закрытыми глазами и вместо кубика Рубика собирают кластеры Kubernetes. Интересные мне в данном контексте ребята - линуксовые/виндовые инженеры с опытом в ИТ индустрии максимум один-два года.

Чтобы показать свои компетенции, проведу небольшой мастер-класс, этакий DevOps 101 (тоже платно, но подъемно).
Нравится такое? Жмите на «козу». Если наберется 20 коз, значит интерес есть, и можно пускать идею в работу.

P.S. Только не жмите по фану, мне нужна максимально честная реакция.
P.P.S. Контенту это не повредит, не волнуйтесь (скорее даже поможет).

Офигеть вы шустрые!

(ушел готовить материал)

Я вам так скажу, готовить простенький мастер-класс занятие очень увлекательное. Приходится вспоминать многое из того, что не трогал довольно давно. %)

Сложнее всего начать. Поскольку в Нидерах сейчас аномальная жара, просто заставить себя сесть за работу невозможно, на ноуте так вообще можно яичницу жарить.
Для тех, у кого проблемы с мотивацией или не знаете с чего начать проект, пусть даже небольшой, есть полезный совет из прекрасной книжки “A subtle art of not giving a fuck”.

Совет очень простой: Сделайте что-нибудь.

Вот именно так - что-нибудь. Хоть что-нибудь. Ну хоть малюсенькое что-нибудь.
Когда вы смотрите на задачу или проект, кажется, что работы там настолько много, что непонятно с какой стороны копать. Тут в принципе и кроется суть - начинайте копать с любой стороны.

Ведь мне для мастер-класса что нужно? Найти платформу для вебинара, надо подготовить окружение-песочницу, нарисовать презентацию, написать пару местных приложений. Глядишь на все вместе - кажется задачей на пару спринтов.
А как садишься описывать конфигурацию вагрантовых коробок, там уже и ансиблевые плейбуки прут, и на вебинар.ру зарегистрировался, и приложения решил не писать, а брать готовые (благо на Github всяких hello-world навалом).

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

Если у вас есть животрепещущие вопросы, вы знаете куда писать. ;)

Я начинаю понимать любовь творческой интеллигенции к столице Франции. Город впитал в себя многолетнюю культуру государства, и гуляя по улицам, особенно в темное время суток, чувствуешь себя героем фильма Вуди Аллена “Ночь в Париже”.
Одним из главных пунктов “посмотреть, иначе считай не был” был Лувр. Музей настолько огромный, что меня хватило только на четверть, хоть я и увидел предметы искусства, которые меня интересовали больше всего: Нику, Венеру Милосскую и всем известную Джоконду.

Когда я добрался до экспозиции одного из самых известных трудов да Винчи, я в очередной раз (как это обычно со мной бывает в музеях) познал дзен. Не потому что я увидел саму картину - Джоконда это самый яркий пример оверхайпа во всем мире, который вы когда-либо увидите, посетив Париж. Пространство вокруг картины, надежно спрятанной за бронированным стеклом, кишело туристами, которые стояли напротив картины минутами, снимая ее на телефон (причем некоторые даже снимали на видео).
Надо встать рядом. Надо смотреть на нее в упор. Надо сделать селфи. Надо позвонить дальнему родственнику: “Посмотри на меня, я стою напротив Моны Лизы, она прекрасна и у нее нет бровей!”.

Но дзен не в этом. Напротив Моны Лизы, окруженной сотней человек, если не больше, выставлена картина Паоло Веронезе “Брак в Кане Галилейской”, поистине огромная и прекрасная во всем, начиная с кошки, дерущей вазу, заканчивая изображением Христа посередине стола, словно его скопировали с “Тайной Вечери”.
И пока Мона Лиза держалась под натиском толп китайцев и британцев, результат работы Паоло Веронезе стоял одиноко, и всего лишь пара человек остановилась, чтобы разглядеть изображенных на ней псов.

И в этом весь наш мир. “Мона Лиза” в Лувре - это семейка Кардашьян, концерт Джастина Бибера и очередь людей за новым айфоном. “Брак” - Илья Кочергин, взявший золото олимпиады по физике в Цурихе, русские студенты, выигравшие кубок ICPC, Дмитрий Маковкин, закрывший собой смертницу, в Волгограде в 2013-ом году.
Что объединяет этих людей с картиной Веронезе? То что всем на них плевать. Как и на Les Noces de Cana.

Миграционные проекты - одни из моих самых любимых. За всю свою карьеру я занимался “переездами” во всех возможных проявлениях: от тяжелых legacy кластеров до в буквальном смысле переездов из одного офиса в другой.

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

Миграцию при этом надо делать по-умному. Повезло, если у приложения есть окно обслуживания, когда его можно просто выключить на часок-другой. Хуже - когда приложение обслуживает клиентов 24/7, и не дай Бог гламурная нимфетка не сможет с первого раза выложить свое личико на всеобщее обозрение.
В таком случае конторы обычно нанимают под это дело консультантов или контрактников, чья работа заключается в переманивании клиентов на свою платформу и помощи пережить migration pain. Если нет денег на “наемника”, контора делает шаг в пропасть и пытается переехать своими силами. Чаще всего - с огромными репутационными и финансовыми потерями. Поэтому если вам предстоит переезд, выбейте у бизнеса денег хотя бы на обучение.

Миграция делится на два типа: переделывание приложений с нуля под архитектуру новой платформы (читай - переписываешь все под тот же Амазон) и lift-and-shift (перетаскиваем как есть).
Оба способа имеют свои недостатки, и не смотря на “некрутость” lift-and-shift считается самым оптимальным по стоимости и скорости.
Переписывая все с нуля под новую платформу, вы рискуете попасть в неприятную ситуацию, потому что:
1. Неправильно спроектированная архитектура, в виду отсутствия компетенций.
2. Старые проблемы могут быть так же переписаны в новом коде.
На выходе вы получите такой же велосипед на костылях, но зато с IAM ролями вместо API ключей.

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

Если же контора решает устроить переезд своими силами, то обычно организуется своеобразный taskforce - группа людей из разных команд с разными навыками.
Хорошо, когда новая команда сначала проходит обучение. Тогда каждый, набрав определенные компетенции, может предложить идею, которая будет соответствовать best practices. Хуже - когда команда ничему не учится и лезет напролом, гугля разные порции документации.

Вот вам пример - нам нужно перетащить старый MySQL от хостинга в Амазон с минимальным downtime (речь идет о mission critical системе).
Что сделал один из разработчиков-stakeholder’ов? Нагуглил прикольную доку: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Procedural.Importing.NonRDSRepl.html

Правильный ли это подход? Может быть, не могу подтвердить или опровергнуть сразу. Но поскольку Амазон не меньше вашего заинтересован посадить клиента на свою инфраструктурную иглу, тот он наверняка предусмотрел этот сценарий и предложил решение в виде Database Migration Service, где весь этот процесс сделан автоматически, да и к тому же поддерживается репликационная миграция (читай продолжительная).
Чем поднимать руками ЕС2 и настраивать там MySQL мне гораздо проще развернуть репликационный таск и выключить его, когда приложение будет готово работать с промышленной базой в Амазоне. Весь downtime - один рестарт приложения.

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

Поднабив руку в Terraform и Cloudformation, внезапно понял, что мне больше не удобно пользоваться консолью AWS. O_O

Мое состояние, пока в Амстердаме бушует прайд.