До микросервисов нужно дорасти, а не начинать с них

Да, плохой пример.

До микросервисов нужно дорасти, а не начинать с них

Ещё пример. Вам нужно сконвертировать видео загруженное пользователем. Вы будете его налету конвертировать монолитным приложением?

Нормальный подход — сделать для этого отдельный сервис.

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

До микросервисов нужно дорасти, а не начинать с них

Еще 1 пример, для nodejs. Чат на WebSocket'ах. Запустите его на 2 серверах :-)

До микросервисов нужно дорасти, а не начинать с них

Пример, приложение по таймеру делает какие-то действия с базой, например очищает старые записи. Я запустил 10 инстансов и получил 10 очисток, вместо 1.

Понятное дело, что можно начать придумывать, типа, запускать таймер только на 1 инстансе, запускать в 10 раз реже и т.п.

Но не проще ли сделать отдельное приложение для этого?

До микросервисов нужно дорасти, а не начинать с них

Файлы вы храните в S3. Видео перекодируете в AWS ElasticTranscoder. RTMP транслируете через Red5. 3D модели рендерите SolidWorks. Email-ы рассылаете через SES. Картинки конвертируете ещё чем-то. И т.д.
Да, на мой взгляд, это уже будет сложно назвать монолитным приложением.

До микросервисов нужно дорасти, а не начинать с них

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

До микросервисов нужно дорасти, а не начинать с них

Всегда ли монолитное приложение можно разместить на 6 серверах?

До микросервисов нужно дорасти, а не начинать с них

Вы также можете вынести отдельные тяжелые операции в фон на отдельный сервер с помощью очередей, если это возможно

Но это же уже будет не монолит?

если что, это вовсе не микросервисы

еще раз, я не говорил про микросервисы, я имел в виду минисервисы.

До микросервисов нужно дорасти, а не начинать с них

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

До микросервисов нужно дорасти, а не начинать с них

Потому что монолитное приложение можно разместить только на 1 сервере. 1 большой сервер дороже нескольких маленьких.

Я уверен что любое приложение можно на начальном этапе разделить как минимум на 2 части:
— с состоянием
— без состояния

На часть без состояния обычно приходится основная нагрузка. И эту же часть легко масштабировать. Для этого, например, в AWS/Azure существуют готовые решения: auto scaling groups / scale sets. Это позволяет держать 1 меленький сервер, а в пиковые нагрузки запускать дополнительные.

До микросервисов нужно дорасти, а не начинать с них

Это не микросервисы. Но это же уже и не монолит, верно? В статье рассматриваются 2 крайности — монолит или микросервисы. Но есть же еще среднее между ними.

До микросервисов нужно дорасти, а не начинать с них

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

До микросервисов нужно дорасти, а не начинать с них

Если сервера находятся в одном датацентре, то не думаю что сетевые задержки существенны. Иначе можно предположить что БД, кеш, elasticsearch и др. нужно держать на одном сервере, чтобы избежать сетевых задержек.

До микросервисов нужно дорасти, а не начинать с них

Это да. Но без первого второго не получится.

До микросервисов нужно дорасти, а не начинать с них

Также можно сказать про ООП, ФП и другие подходы. А может просто кто-то не хочет говнокодить?

До микросервисов нужно дорасти, а не начинать с них

Вы прочитали 1 книгу и делаете выводы. Есть очевидные места где надо делить. Просто не надо впадать в крайности.

Размещение веб-приложения на Amazon Web Services. Дёшево. Возможно ли это?

Интересно, почему вы пользуетесь Azure? Какие у него преимущества? Мне приходится им пользоваться, но для меня это испытание.

Способы синхронизации вкладок браузера

Для меня хороший пример синхронизации вкладок — это login / logout.

Как обезопасить C

Как оказывается, видеть машынные инструкции уже не достаточно (а может и смысла не имеет): С — не низкоуровневый язык

BEM'a не должно существовать

Да, вы правы:) vithar что вы на это скажите?))