Как стать автором
Обновить

Комментарии 16

Микросервисы для MVP решительно не подходят. Ваш бюджет кончится раньше, чем вы что-то реализуете. MVP у вас будет хоститься на Raspberry Pi со статическим IP или VPS за 300 баксов в год, а микросервисы на каком-нибудь AWS будут потреблять тысячи баксов, это без затрат на DevOps'а.

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


Да и опять же, с чего это AWS будет таким дорогим? Пару простецких сервисов в нем не так дорого обходятся пока нет нагрузки

Правда, как всегда, где-то посередине. MVP у нас про что? Про то, что надо быстренько сваять то, конечный вид чего есть в лучшем случае у 1-2 человек. И простенький монолит тут будет быстро и легко закрывать какие-то базовые вопросы, давая возможность сосредотачиваться больше именно на запуске.

Микросервисы же требуют более глубокого понимания бизнес-модели. Ведь часто они именно её и отражают. Ведь (правильные) микросервисы состоят не просто в том, чтобы хоть как-то распилить монолит и раскидать его по контейнерам/виртуалкам/Raspberry PI, а выделить некие области задач этими сервисами решаемые. И на этапе MVP часто этого понимания просто нет.
Монолитные приложения состоят из взаимозависимых, неделимых блоков и имеют очень низкую скорость разработки.

Какое голословное утверждение. Клепать новый функционал в монолите можно просто с невероятной скоростью, тут прокинул через глобал, тут нарушил инкапсуляцию, хренак-хренак и функционал готов.
Да можно ничего не нарушать.
Монолит — это монорепа, очень легко добавлять изменения куда угодно. В случае микросервисов монорепа — это боль. А значит надо либо использовать git modules, что тоже боль. Ну либо делать общие зависимости какими-то общими пакетами, что сильно замедляет разарботку. Другого способа я что-то не вижу.

Разные репы для микросервисы тоже боль. Ведь кроме микросервисы есть ещё их клиенты. Обновил API микросервиса надо и клиента обновить во многих случаях и тут монорепа имеет ощутимые плюсы.

Полностью согласен.
Скорость разработки для монолита сильно зависит от того как он написан, какая степень связанности компонентов в нем.


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

как-то я совсем не согласен с автором в контексте mvp + microservises. да даже далеко ща пределами mvp микросервисы в большинстве своем излишество. если смотреть через призму хайпа и неограниченных ресурсов — да, отличное решение, но если смотреть правде в глаза — первые несколько лет не стоит даже вспоминать про из существование. а ещё лучше последовать примеру гигантов, например Амазон, который о микросервисах задумался когда у него штат был овер 3к сотрудников и выручка что-то около полу лярда в год. (точных цифр и источник не скажу).
точных цифр и источник не скажу

Помогу. Тем более что это вполне по теме статьи.
К тому времени, когда Амазон осознал необходимость перехода на SOA, у них было 7800 сотрудников и они продавали товаров на 3 миллиарда долларов в год.

Отсюда
Разрабатывать монолит гораздо быстрее чем микросервисы, не говоря уже о содержании. Все знают главное правило микросесрвисов: если можно их не использовать, то лучше не использовать. SOA для шизиков очень специфическая штука. Serverless — как будто абстракция ради абстракции, не очень понятно, что делать, если понадобиться залезть в «сервер», ну и вендорлок к тому же. Это что же, получается что в 2019 году монолит рулит? А вот получается, что да.
Жаль, что монолит скейлится только целиком. Если, конечно, вообще скейлится.
Иногда несколько копий монолита будет дешевле (по железу и поддержке) иметь, чем стадо микросервисов. Ну и мы же говорим про MVP. Потом можно и монолит попилить на куски, это будет гораздо проще чем писать микросервисы с нуля.

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

Исключительно на основе опыта. Не забываем, что имеем дело с MVP, т.е. многие вещи вероятно переделаются. Переделки микросервисов обходятся сильно дороже. Кроме этого, в работающем монолите проще понять как нужно побить на сервисы, чтобы не было больно.
В случае, когда в ТЗ все-все прописано и ничего не поменяется и сразу понятно, что надо микросервисы пилить, то да, лучше сразу их и делать. Но такое редко бывает, с MVP почти никогда.

С монолитом есть нюанс: как правило он билдится и деплоится только целиком и долго. Исправление опечатки в сообщение одного маленького модуля может вызвать длительный билд, а, главное, даунтайм всей системы. Решается костылям разной степени типа инкрементальных билдов и сине-зелёных деплоев, которые неплохо живут и с микросервисами, но в монолит их внедрять захочется гораздо раньше

Да, монолит не идеален. Можно придумать модули и тому подобное, правда, это не очень удобно. В своем предельном исполнении идеи с модулями, получаем те же микросервисы, но тут можно выстроить и что-то компромиссное.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий