o
Size: a a a
2016 May 25
ɪᴋ
Когда микросервисов в проекте больше, чем разработчиков :3
Не соглашусь, в том то вся и прелесть, что в теории сервис можно написать и забыть о поддержке.
o
имхо стороны потенциально большой проект будет "проще" писать со временем, в теории. ну т.е. с ростом кодовой базы будет меньше борьбы со старым кодом, время на разработку по идее не должно увеличиваться пропорционально усложнению ядра.
Ну в теории же всегда все хорошо :)
MG
ну да )
ɪᴋ
имхо стороны потенциально большой проект будет "проще" писать со временем, в теории. ну т.е. с ростом кодовой базы будет меньше борьбы со старым кодом, время на разработку по идее не должно увеличиваться пропорционально усложнению ядра.
Причем, сервис можно будет просто выкинуть и переписать. Как Uber недавно, например, переходил с Ноды.
ɪᴋ
В этом то вся пока и проблема для меня. Слишком много вариантов.
o
Причем, сервис можно будет просто выкинуть и переписать. Как Uber недавно, например, переходил с Ноды.
Вопрос в том, почему бы не сделать из микросервисов сервис
MG
недавно на хабре была хорошая аналогия с О большой. т.е. можно например кодовую базу и работу с ней оценивать по методу оценки алгоритмов. ну т.е. если ядро постоянно усложняется - то имеет смысл задуматься о микросервисах. с другой стороны если ядро постоянно усложняется, то вероятно дело уже в людях, и может им уже не помогут микросервисы :)
SB
монолит наше всё
MG
ну т.е. вероятно оценка необходимости по О большой может помочь, в теории )
o
недавно на хабре была хорошая аналогия с О большой. т.е. можно например кодовую базу и работу с ней оценивать по методу оценки алгоритмов. ну т.е. если ядро постоянно усложняется - то имеет смысл задуматься о микросервисах. с другой стороны если ядро постоянно усложняется, то вероятно дело уже в людях, и может им уже не помогут микросервисы :)
Принцип разделения отлично работает на алгоритмах, но тут не меряется сложность алгоритма.
o
монолит наше всё
Фленеган тоже так считает
MG
ну я про сам подход, на самом деле. можно процессы оценивать схожим образом и уже от этого плясать
ɪᴋ
недавно на хабре была хорошая аналогия с О большой. т.е. можно например кодовую базу и работу с ней оценивать по методу оценки алгоритмов. ну т.е. если ядро постоянно усложняется - то имеет смысл задуматься о микросервисах. с другой стороны если ядро постоянно усложняется, то вероятно дело уже в людях, и может им уже не помогут микросервисы :)
Все-таки основной критерий — здравый смысл и техническая необходимость. Для меня микросервис это пакет. При необходимости пишем `cmd/$SERVICENAME/main.go`-обертку и получаем микросервис. Но нужна инфраструктура, а это нужно подсесть на что-то одно. Kubernetes тот же.
MG
Все-таки основной критерий — здравый смысл и техническая необходимость. Для меня микросервис это пакет. При необходимости пишем `cmd/$SERVICENAME/main.go`-обертку и получаем микросервис. Но нужна инфраструктура, а это нужно подсесть на что-то одно. Kubernetes тот же.
по этой причине я и сказал, что если у людей постоянно меняется ядро, то вероятно не хватает здравого смысла. некоторые и микросервисы способны загадить
ɪᴋ
Как быть с реестром этих сервисов, логг рованием, health check?
Как деплоить, версионировать. Я правда сомневаюсь что небольшая команда способна потянуть поддержку всего этого, если будет сама велосипедить.
MG
ну микросервисы это логистика в первую очередь. помню видел выступление системного архитектора с варгейминга, он там немного рассказывал как у них работают со всеми сервисами: расписание релизов, четкие требования, дедлайны. но это в сложном случае. частично совсем простейшие микросервисы могут быть менее критичными в плане сложности, с другой стороны чем проще, тем больше кол-во микросервисов. тут видимо уже архитектор должен решить сам, что ему сейчас нужно. ну и вновь возвращаемся к здравому смыслу.