There is a lot to like about this move. Microservices and service mesh's are certainly an interesting area right now...and this represents a big push from some big players.
Google and IBM announce Istio – easily secure and manage microservices
41–50 of 123 posts
Re: Google and IBM announce Istio – easily secure and manage microservices
#42They're just flailing and trying to see what suckers will pay for.
All of your hats are made of inferior cheese.
Re: Google and IBM announce Istio – easily secure and manage microservices
#43Earlier quoted context omitted.
The REST architecture always included the possibility of gateways and proxies in the end-to-end communication path to delegate shared responsibilities out of the user agent or origin server. This balances the need for centralized admin of some things and decentralized deployment of other things. Most microservices systems, even if they're not using HTTP in favor of something like gRPC, Kafka, or Rabbit, are taking a…
Very well put. From what I see this is like moving hysterix from the sidecar level to the network level. No need for applications to care of even know about leveraging the circuit-breaking. Very excited to try it out!
I'm curious if circuit breaking is better at the method level of the code ala Hystrix or at the network level. We need more in-the-wild experience reports I think...
Re: Google and IBM announce Istio – easily secure and manage microservices
#44There seems to be also other companies involved: Redhat: https://blog.openshift.com/red-hat-istio-launch/ Pivotal: https://content.pivotal.io/blog/pivotal-and-istio-advancing-...
and isn't the entire solution just packaging a proxy developed and open-sourced by Lyft?
Re: Google and IBM announce Istio – easily secure and manage microservices
#45What happened to dumb pipes, smart endpoints? We do the same things again that we did before with SOA, having hard-to-replace middleware / bus systems.
The REST architecture always included the possibility of gateways and proxies in the end-to-end communication path to delegate shared responsibilities out of the user agent or origin server. This balances the need for centralized admin of some things and decentralized deployment of other things. Most microservices systems, even if they're not using HTTP in favor of something like gRPC, Kafka, or Rabbit, are taking a…
Well said.
Besides Netflix, I'd put Twitter as an early pioneer, with their work on Finagle. Both of these companies, for better or worse, took a library-centric approach (Eureka/Hystrix/etc or the Finagle lib). This limited their applicability to the JVM.
The sidecar model that AirBnb pioneered with SmartStack, later adopted by Yelp and others was the cheapest way to get non-Java langs to have similar resilience/observability semantics. And now given the popularity of polyglot architectures, it's probably should be the default choice for companies adopting microservices.
Re: Google and IBM announce Istio – easily secure and manage microservices
#46Earlier quoted context omitted.
Very well put. From what I see this is like moving hysterix from the sidecar level to the network level. No need for applications to care of even know about leveraging the circuit-breaking. Very excited to try it out!
I'm curious if circuit breaking is better at the method level of the code ala Hystrix or at the network level. We need more in-the-wild experience reports I think...
The thing you can do at the code level is integrate it with your exceptions and protect against software integration bugs. Imagine that your RPC against a new version of a service fails because of bad data. With a library level circuit breaker, you can catch the failed exception and blacklist the new version of the service. With the network level, your resolution of failure detection is more limited.
Re: Google and IBM announce Istio – easily secure and manage microservices
#47There seems to be also other companies involved: Redhat: https://blog.openshift.com/red-hat-istio-launch/ Pivotal: https://content.pivotal.io/blog/pivotal-and-istio-advancing-...
and isn't the entire solution just packaging a proxy developed and open-sourced by Lyft?
Envoy is a big part of the solution, yes. But it isn't the only component. A control plane layer, including an auth component and an adaptable policy enforcement and telemetry collection component, is included as well.
More info is available in the overview doc here: https://istio.io/docs/concepts/what-is-istio/overview.html
Re: Google and IBM announce Istio – easily secure and manage microservices
#48Regarding API management in the context of Istio:
https://apigee.com/about/blog/digital-business/simplifying-m...
Re: Google and IBM announce Istio – easily secure and manage microservices
#49Interesting, but there's currently a lot of overlap between competing things that want to inject themselves between service consumers and service producers. There's API gateway products (Apigee, Kong, etc). Load balancers and proxies of various types. Caching and CDN products. More niche stuff like bot blocking, and this attempt to bundle control and statistics. It would be nice if some sort of standard pattern emerg…
Regarding API gateway products, Apigee will actually work with Istio
https://apigee.com/about/blog/digital-business/simplifying-m...
Re: Google and IBM announce Istio – easily secure and manage microservices
#50https://istio.io/docs/concepts/network-and-auth/auth.html
No option for OAuth2 or JWT? Maybe I'm not understanding the problem Istio solves vs. Envoy