Комментарии 7
И тогда всплыла вот такая картинка, взятая отсюда
И возник у нас тогда резонный вопрос, а зачем нам собственно Spring Cloud, если Kubernetes даст нам тоже самое и еще многое другое?
Для полноты картины можно, конечно, упомянуть вот этот проект, но надо ли так все усложнять?
Kubernetes обеспечивает сервис для ваших приложений на инфраструктурном уровне.
В остальном, это всегда компромис между тем чтобы вынести всё из приложения в инфраструктуру и завязаться на неё, или втащить побольше в приложение сделав его более самодостаточным, переносимым, устойчивым к внештатным ситуациям.
Например: Вот Distributed Tracing указан на вашей картинке и в Kubernetes и в Spring. Разница лишь в том, что самое ценное при трассировке – полная картинка. Frontend->Api1->Api2 трейс не полон. Frontend->Api1->Api2->Database например выглядит уже интереснее
Часто чтобы решать задачу оптимально нужно просто не быть паранаиком :) Решать её на нужном уровне – инфраструктура/приложение/процесс
У вас же микросервисы в докере работают, иначе сложно все становится, не так ли? А когда у вас появляется с пару десятков контейнеров, хочется этот зоопарк как то в порядок привести. Начинается поиск решений и после прочтений нескольких статей приходишь к Kubernetes. А когда начинаешь разбиратся с этой штукой, первое, что приходит в голову: а нафига мне Spring Cloud?
Мой опыт говорит, что надо рассматривать проект в контексте его полного цикла жизни, а не только разработки. Т.е. надо смотреть например, а в какой среде наш проект будет у клиента работать? Как мы его будем деплоить, как мониторить и т.д.
Ну и плюс к этой теме, все чаще появляются статьи, что все что не относится к бизнес логике, надо выносить в инфраструктуру. Т.е. такая штука, как Load Balancer не должна быть в сервисе, ее место в инфраструктуре. Тоже самое касается и например Circuit Breaker. Даже такая штука как Timeout запроса должна быть определена не в сервисе, а в инфраструкруре.
В общем и целом похоже на то, что решения Netflix( но не идеи!), устарели, будущее за такими штуками как Kubernetes.
И еще, почему микросервисы — сразу в докере? Есть ведь и rkt и lxd/lxc, и cri-o, и честная виртуализация. В конце концов, есть честное голое железо со всеми его преимуществами.
А почему именно k8s? А если я захочу заложить в систему свою собственную хитрую специфику, то всё, лапки?
Многие задачи решаются на разных уровнях, от этого есть некая синергия. Вопрос насколько сложно в итоге это реализовать, чтобы бы получить эффективную реализацию
Впрочем, сам Spring Cloud больше интегрирован с PCF нежели в Kubernetes. Хочешь затратить меньше усилий и получить максимум профита — используй готовые связки. Так везде
В какой момент discovery становится выгоднее в обслуживании, чем "static discovery" через к примеру ansible? Считает ли служба эксплуатации схему с discovery удобнее/целесообразнее/практичнее?
Думаю вопрос "в какой момент" зависит от множества условий
- Насколько сложно поддерживать конкретное решение? (Eureka довольно неприхотлива, а с клиентской стороны в случае со spring cloud все организуетсяд довольно просто. Consul несколько сложнее и с ним нужно быть аккуартнее)
- Статическая конфигурация это тоже прекрасно, если умеете ей управлять конечно. У нас вопрос управления ресурсами (железки, mem, cpu, порты, пути балансировки) решается техническим путём – оркестратором (mesos+frameworks). Ну и в этом случае уже без discovery не обойтись, т.к нужно дружить разные системы, делящие одни и те же ресурсы :)
Когда в маленьком кластере 160 разных приложений, управляемых разными командами, уже не хочется отдавать конфигурацию портов на откуп человеческой голове. Это не та задача которой она справляется безошибочно и качественно, человеческий фактор будет стрелять всё чаще и чаще. Поэтому мы пошли по пути шлифования автоматизированного решения.
Служба эксплуатации разбирается в этих решениях, причем и в Consul и Eureka( если говорить про наши реализации). Конечно вегда есть что узнать нового, но в эту сторону мы тоже потихоньку движемся, развиваемся :)
Что такое Spring Cloud и как его готовить – интервью с Евгением Борисовым и Кириллом Толкачёвым