У вас же основной заказчик акиматы будут? Так для начала сходите к ним, узнайте действительно ли 3 камаза и бригада рабочих для них проблема? Возможно для них это наоборот возможности (пилить бабло например). А вы тут инвесторов ищете на продукт который ВОЗМОЖНО никому не нужен

С такой техникой нужно рассчитывать на международный рынок, а не на казахстан

Потому что размер рынка в Казахстане - очень скромен

Имеется в виду производство такого прицепа, который будет стоять над колодцем канализационным стационарно и к нему 3 КАМАЗа и бригада рабочих будет свозить снег с округи, чтобы он его топил и сливал в канализацию😉
И овцы целы и волки сыты и инфо повод для мэра😂

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

И его не хватает на текущий объем снега

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

Там ещё со снегом и мусор и химикаты и соль, отличной супчик🙈

это, наверное вопрос к @NurzhanMM ))

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

Или инновационный способ топки придуман?

Некорректный перевод
Слово services переводится не как «услуги», а как «сервисы», то есть службы в Операционной системе

Но контекст вы сильно подпортили :)

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

Или пойти купить сервисы у гугла и амазона :)

получается у backend разработки будущего нет?

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

Неожиданный вывод )

Любая архитектура, любое решение несут плюсы и минусы. Цена микросервисов - высокие накладные расходы на инфраструктуру и снижение скорости разработки по отношению к одному разработчику. Плюсы - масштабирование команды разработки и сервиса

У монолита обратные плюсы и минусы :)

Все относительно. Например в случае построение инфраструтуры на докере, цена сопровождения множества сервисов не намного дороже решения "все в одном". С монолитом можно делать прототипы, которые трудно скейлить. А сложная архитектура имеет все шансы не дожить до продакшна.

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

Все относительно, вы правы. Мы перешли на микросервисную архитектуру, у нас десятки команд, у каждой команды несколько сервисов, обновления каждый день идут

Доп расходы: есть отдельная инфраструктурная команда, которая поддерживает все это добро (очень дорогие специалисты), и не делают ничего продуктового

А докер - лишь упрощает перенос с машины разраба на продуктовую машину )

И при этом - сам докер это тоже точка отказа

Докер перекрывает много инфраструктурных моментов. Это не просто "дев машина -> прод машина".  Простой пример автоматически преднастроенные функции отказоустойчивости и бекапирования.
В последнее время я больше склоняюсь к мысли, что архитектура проекта 100 раз будет меняться, пока не станет оптимальной для бизнеса.

Расскажите про функции бакапов в докере? Видимо мы по-разному знаем докер :)

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