Comments 12
Очень крутая статья. Автор практически убедил меня, что нужно попробовать помимо Istio его детище — Linkerd.
С другой стороны, я полностью согласен с тем, что Большой Брат в лице Гугла очень навязывает нам две основные технологии в своем портфеле — Kubernetes и Istio да так, что все остальные аналоги (не всегда плохие!) остаются в тени.
Кроме того чисто технически растут накладные расходы, об этом в статье упомянуто. А вот о чём не сказано, так это то, что по-умолчанию Linkerd устанавливает MutatingWebhookConfiguration на который условно можно полагаться только в самых свежих версиях Kubernetes. Да и то я бы не рискнул, уж очень неприятные сайд-эффекты при проблемах. Так что automatic sidecar injection стоит заменять на ручную через CI, которая менее зависима от событий кубернетиса и не вызывает падение всего кластера в случае отказов.
В статье также не указывается одна важная мысль: linkerd в виде sidecar proxy НЕ является Ingress Controller. И все преимущества в виде retry/… НЕ будут доступны для внешних пользователей по-умолчанию, если ваш Ingress не встроен в service mesh. То есть это прежде всего _между сервисная коммуникация внутри кластера_, а не балансировщик нагрузки пользовательских запросов. А вот Linkerd v1 могла выполнять и функцию балансировки для конечных потребителей.
А ещё для того же Canary требуются сторонние тулзы.
Проведя поиск по фразе «service mesh», вы наткнетесь на кучу переработанного низкокалорийного контента, странных проектов и калейдоскопа искажений, достойных эхо-камеры. Любой модной новой технологии свойственно это, но в случае service mesh проблема стоит особенно остро.
Интересно, как скоро Service Mesh настигнет судьба REST?
Аналогичная подмена понятий и девальвация термина из-за маркетингового хайпа.
https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
https://tyk.io/rest-never-crud/
https://stackoverflow.com/questions/19884295/soap-vs-rest-differences/19884975#19884975
https://www.infoq.com/articles/web-api-rest/
https://www.infoq.com/news/2016/07/microsoft-rest-api/
https://github.com/Microsoft/api-guidelines/pull/29
https://en.wikipedia.org/wiki/Talk:Representational_state_transfer
У Netflix была Hysterix, у Google была Stubby, у Twitter — библиотека Finagle. Finagle, например, была обязательной для каждого нового сервиса в Twitter.… Конечно, она работала только для JVM-языков… Однако ее функциональные возможности были почти такими же, как и у service mesh. (На самом деле первая версия Linkerd просто представляла собой Finagle, обернутый в форму прокси.)
… Должен был произойти еще один сдвиг, прежде чем она появилась.
То, что кубер стал популярным ещё не значит что надо сделать этот шаг, отказаться от библиотеки и наворачивать service mesh.
Единственный плюс который я вижу — если в компании действительно есть микросервисы на разных языках программирования.
Если всё пишется на одном — лучше общую либу.
вся модель service mesh основана на этом постулате: в мультисервисной системе, независимо от того, что делают отдельные сервисы, трафик между ними является идеальной точкой для добавления функциональности.
Так себе идея, размазывать логику между кодом и service mesh.
Там скриншоты из внутреннего Slack, не могу скопировать сюда текстом.
Service Mesh: что нужно знать каждому Software Engineer о самой хайповой технологии