Без мониторинга вообще не соваться даже. Постоянные сюрпризы

А монолита без мониторинга не сюрпризы?

Монолиты как-то стабильнее чтоли

Ну и в них стектрейсы понятны. А если 1 микросервис дернул 2й а тот 3й и тот упал то проследить цепочку вызовов откуда началось просто так как в монолите не получится - уже инфраструктура нужна

Монолиты - жирные

Фэтшейминг

Ггг)

Начал тут пилить свой проект на питончике и джанге, настало время писать фронт, хотел без всяких модных наворотов, чем проще тем лучше, думал про чистый js c классами, но чет не очень хотелось jsом обмазываться и тут вспомнил про clojurescript, правда с cljs я не знаком, игрался только с cj
И вот вопрос, для фронта cljs нужно свой отдельный бэк поднимать или как там все работает в двух словах и какие есть хорошие практиви для фронта на cljs?

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

и вот этот полученный js просто указываю в html страничке и все будет гуд?

да

единственное что dev-билды нельзя добавлять на страницу асинхронно (потому что google closure compiler в dev-режиме использует document.write)

ок, а стоит ли использовать Reagent, гугл часто ее выдает?

у нас кажется zipkin для решения чего-то похожего использовали

Чистый js с классами уже не очень просто

- зачем классы?
- как ими интерфейс описывать?
- нужен хотя бы react

Именно. Это прямо отдельный класс ошибок, для которого вводят новые инструменты типа Opentracing. Короче, микросервисы - штука оправданная к внедрению далеко не всегда, и тянет за собой более чем приличное количество дополнительной работы.

Собсно в том же Эрланге монолитное ПО не совсем монолитное, а набор отдельных приложений, работающих на erlang node. Т.е. микросервисы на Эрланге появились задолго до того, как это стало менстримом.

И всё нормально работает без докеров и k8s :)

Datadog имеет что то для трэйсинга

Несколько тезисов: 1. Микросервисы должны проходить по границам бизнес функциональности (business unit context), а не по ит-функциональности.
2. Из 1 следует, что сначала надо разделить бизнес если он монолитен. И до этого момента пилить независимые микросервисы нельзя.( как исключение - внутри business unit можно)
3. Если вы не умеете делать монолит, то микросервисы вам не помогут, т.к. они сложнее в управлении.
4. Без качественного мониторинга логов и метрик (инфраструктуры) управлять микросервисами не получится.
5. Вызовы микросервисов лучше не делать дальше 1 hop. Иначе резко растёт вероятность недоступности