Re:Kuma – Open-source control plane for your Service Mesh
by jacques_chester on Tuesday September 10, 2019 @06:16PM
(#20934437)
You might be thinking of Netflix, who developed Hystrix and Ribbon.
These are being slowly replaced with other components from Spring Cloud or Resilience4J: https://medium.com/netflix-techblog/netflix-oss-and-spring-b...
Disclosure: I work for Pivotal, but not on Spring.
Re:Kuma – Open-source control plane for your Service Mesh
by core-questions on Tuesday September 10, 2019 @07:27PM
(#20934979)
Are you saying my application doesn't need to have any logic for handling network connectivity problems once I have a service mesh? That sounds hard to believe. Maybe I don't understand what code I wouldn't need any more.
Re:Kuma – Open-source control plane for your Service Mesh
by fosk on Tuesday September 10, 2019 @11:23PM
(#20936313)
You won’t need code for mutual TLS, certificate rotation, routing, canary load balancing, tracing, logging, service ACL, retries, circuit breakers, cross-region failovers and so on. The out of process proxy model makes these features portable across multiple stacks and programming languages too, which is a nice benefit.
Re:Kuma – Open-source control plane for your Service Mesh
by core-questions on Wednesday September 11, 2019 @01:03AM
(#20936712)
Oh. Well, I hate managing many of those things, so maybe I am sold on the idea at this point. The key for me would be to find some case study of converting a traditional setup to use one of these so that I could get a grasp on where you actually start for wiring it up.
I have Consul going, and making decent use of it for discovery, and have a feeling that Consul Connect may be a half-assed version of what you're describing; but I don't hear of many people using it.
As soon as we make any request that goes over a network, we need to make sure that connectivity cannot be disrupted and that observability is in place. LinkedIn famously wrote a "smart" client to do that in Java, that every team must use and they keep maintaining over time but that limits them in adopting non-JVM technology in the organization and creates technical debt over time.