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

Мне когда-то запали в душу слова Стивена Кинга:

Называйте меня колбасником. Да, я колбасный писатель. То, что я пишу, — это колбаса. Сел и съел. Я признаю это и не принимаю никаких претензий: ведь я никогда не выдаю свою колбасу за белужью икру.

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

И ещё одна цитата от Стивена:

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

Это не про какой-то божественный талант. Это просто про то, что у тебя как-то получается, и к чему при этом лежит твоя душа. Если у тебя нет потребности писать код — то не стоит себя насиловать. Возможно, стоит поискать себя где-то ещё, в том числе в связанных профессиях. В тестировании (хороший QA получает не меньше разработчика), в devOps (редкий и очень ценный зверь), в DBA (видел много прекрасных людей, которые живут этим), аналитике, и так далее.

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

Самостоятельное обучение жутко неэффективно. То, чему тебя научат, например, за полгода, ты будешь самостоятельно разбирать года два.

Чудовищная ложь. На дворе 2019 год, но до сих пор тебя не научат ничему из того, что нужно и используется в продашне на bleeding edge. Любые материалы устаревают ещё до момента выхода. Самый важный навык разработчик — это умение самостоятельно обучаться. А если уж хочется облегчить себе жизнь — то можно начать с сотен разных платных и не очень онлайн курсов, которые хотя бы дадут базу.
Если же автор имел в вижу, что обучаться можно только работая — это тоже ложь. Поскольку в работе тебе нужно решать конкретные бизнес задачи, и скорее ты приносишь туда свой багаж знаний и инструментарий для их решения, чем его тебе дают там на блюдечке. Обучаться на работе можно только на стартовых позициях при условии наличия хороших сеньёров, или вопреки всему.

Всё вот это длинное нытьё про профильное образование, опыт работы, который получили только те, кому повезло, и ужасных HR.

Сменил 5 мест работы. Ни в одном HR не считали техническое образование необходимым навыком. Сейчас, в большой серьёзной компании на 300 человек, с постоянным кадровым голодом по разработчикам — мы тоже не можем себе этого позволить. Мы берём разработчиков любого пола, возраста, ориентации и образования, предлагая им релевантную их опыту позицию. Критерии — чтобы человек был адекватен, и чтобы хотел развиваться. Всё.
В чём проблема с тем, что автору давали сразу отбой — не знаю, удалённой диагностикой по посту на хабре не занимаюсь. Возможно, в том, что он в жизни общается в том же тоне, в котором написан этот пост. Или нет. Но точно не в профильном образовании или отсутствии опыта.

Ну и последнее. О наличии опыта, компьютера, книжек, и так далее.
Свои первые программы я написал на даче, ручкой на листке в клетку, прочитав взятый с собой учебник.
Свои пет проджекты я писал, когда ещё такого слова не было.
И мне непрерывно хотелось писать что-то больше, сложнее, интереснее.
Насколько я знаю моих друзей, у них было так же.
Их писали не ради денег, не для того, чтобы показать работодателю или заполнить гитхаб. А потому что хотелось. Если этого нет — автор, вы уверены, что вы действительно хотели программировать? Насколько искренен человек, который хочет быть художником, но при этом рисует раз в год?

Статья полна сравнениями тёплого с мягким, сферическими бенчмарками в вакуме и просто дилентантскими утверждениями.

Лень перечислять всё, для примера "один из минусов Node.JS":

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

1) NPM и Node.JS это разные вещи. Как можно делать вывод о платформе на основании менеджера пакетов?
2) Вот уже много лет с этого случая как в NPM запрещено удаление пакетов.
3) Есть альтернативы NPM и в виде менеджера пакетов и в виде хранилища.
4) Есть решения в виде локальных кеширующих NPM серверов.
5) Самое главное — приложения не "перестали работать". Удаление библиотеки никак не повлияло на работу приложений. А вот собираться они перестали.

О качестве остальной статьи делайте выводы сами.

Если у вас пять разработчиков в компании — то безусловно да. И мотивация "стек — отстой" — крайне плохая.

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

Да, часто про molecular слышу хорошее от адекватных людей, но пока ни разу не трогал, о чём жалею.
Порекомендуете по нему хорошей литературы?

есть потребность бизнеса и конкуренты не будут ждать идеальный код перфекциониста.

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

но стал выстрелом в ногу, даже в две, а потом и в голову

Да, ничего не даётся бесплатно. И при переходе на новые технологии и архитектуру ты обязательно сперва выстрелишь себе в ногу — вообще без вариантов. Нужно просто это пережить.

Чуть выше писал — http, redis, rabbit. Обмен по большей части в JSON или ProtoBuf. Наверняка что-то ещё есть, о чём я не знаю. Какой-то единой шины нет — может быть, это принесло бы нам счастье, но навскидку не могу сказать проблемы, которую она бы решила. Но тут как — возможно, я просто не осознаю, что она есть.

Да, это тоже в какой-то момент становится проблемой — когда нужно несколько гигов оперативки на запуск проекта, и вчетверо больше на IDE...

Да, как-то так. Главное — вовремя поймать момент, когда первое состояние переходит во второе, и осилить перейти. Но до него ещё нужно дожить, что выходит не так часто, как хотелось бы.

Да, проблем было гораздо больше, но я был ограничен и временем доклада и размером статьи. Огромное мало кто прочитает. Судя по комментариям, и эту длину многие читали по диагонали.

1. Удалось ли при такой поэтапной миграции полностью отказаться отказаться от старого кода в монолите? И была ли такая цель вообще?

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

На сколько больше у вас стало девопсов в итоге?

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

Мс и монолит у вас on-premise?

Да, конечно. Свои облака, мощности, поднимаемые по запросу и в ответ на нагрузку, и прочие радости.

"использовать криво" — это про людей, а не про монолиты.

Повторюсь. Проблема — не в факте кривизны использования, а в количестве переиспользований, которые надо проверить за раз.

Это проблема дизайна: как сделать так, чтобы глядя на код было очевидно какие эффекты он вызывает. Микросервисы эту проблему вообще никак не адресуют.

Повторюсь. Меньше кода — проще понять.

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

Повторюсь. Перейти на мажорную версию, поправив 10 строчек — легко. Перейти на мажорную версию, поправив 1000 строчек — кошмар.

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

С микросервисами нам стало проще локализовать проблему в конкретном сервисе.

Это проблема JS и к монолитам отношения не имеет. Тут даже наоборот — будь у вас статическая типизация, монолит делал бы любую работу с кодом проще, чем микросервисы.

Это проблема JS+монолита. Я и имел в виду, что при статической типизации было бы порядком проще.

Искушение, конечно, вызвано тем, что зарелизить один сервис "проще", чем два.

В нашем флоу, разработчик делает задачи, и ничего не знает о релизах — так что ему всё равно, сделать правку в одном сервисе, или в двух.

С микросервисами фичи превращаются в "вот этот код, вон тот код, дождаться вон того релиза, и вот потом-то уже сможем зарелизить нашу фичу".

Да нет, просто релизим, но не включаем. Проверить её работоспособность можно и без зависимых микросервисов.

Часто бывает, что проблема в сервисе Z, который вызывает сервис Y, который в цикле дёргает X по 20 раз на каждую транзакцию :-)

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