Попробую ответить на этот вопрос кратко.
Когда-то давно, стек для микросервисов на java представлялся общим стеком спринга со всякими Netflix примочками такими как Eureka, Hystrix, Ribbon, Zuul и прочей эзотерикой, которая к слову, на то время сильно продвинула принципы, на коих сейчас держится все убранство Spring Cloud. В данный момент, ситуация обстоит так, java это просто контейнер, прокладка с бизнес логикой и оберкой рестом к базе, ну и в принципе и все. Времена меняются, технологии идет вперед, вот вам и Paas со всеми плюшками, gateway-load-balancer-sleuth в одном флаконе, kubernetes с его discovery, а как вам consul вместо конфига? Зачем сервис ресурсов и авторизации, когда есть Auth0 и прочее прочее, любой cloud iaas провайдер предоставит вам кучу инстансов для контейнеров + всякие балансировшики, фильтры и ламбады. И тут вообще вопрос, а нафига тогда нужна java? Когда вытянуть из базы, найти сервис соседа, куда все это можно закинуть и опять же не через feing, а по amqp где уже 2PC. Экономично же писать однорукому архитектору, который только js и знает, он и фронт напишет и спинку почешет, но по крайней мере у него есть опыт организации как все это будет работать. Момент надежности, если вы сможете надежно сделать архитектуру, которая будет автоскалит сама себя под нагрузкой, ну скажем на java это было можно делать на ribbon определяя NIWSServerList NFLoadBalancerRule NIWSServerListFilter и уже расширяя свои инстансы, то сейчас это можно написать простым скриптом просчитывая нагрузку из мониторов инстансов и подымая сколько нужно, да, нет гибкости, и прочей честной логики, но оно того не стоит так как надежность определяется по самому слабому звену, а это 90% это ваша самоуверенность. В итоге имеем стек из технологий и огромный порог вхождения или старый скрипучий, но ламповый Spring Cloud c его корявостью и недоделками, который уже никто не будет править, так и живем.