Live data from Hacker News

Google and IBM announce Istio – easily secure and manage microservices

developer.ibm.com

11–20 of 123 posts

Re: Google and IBM announce Istio – easily secure and manage microservices

#11
post #9

Great documentation and some really great tools included. I was able to get the platform running in minikube really quickly. Interested to compare this to linkerd.

My read of the documentation also indicates a large overlap with linkerd. Hopefully one of the creators is around and can do a compare/contrast.

Re: Google and IBM announce Istio – easily secure and manage microservices

#12

What 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.

It depends on how you view it. Baking everything into the application logic works if you have a homogeneous stack. When you start going down the polyglot route, with 5-6 language runtimes, multiple databases, it becomes really really hard to maintain all the communication logic (discovery, load balancing, resilience) in the app code.

Take a look at AirBnB's smartstack, Yelp, Lyft's Envoy mesh. These are all polyglot applications, where the communication aspects are abstracted out into sidecars.

Re: Google and IBM announce Istio – easily secure and manage microservices

#13
post #9

Great documentation and some really great tools included. I was able to get the platform running in minikube really quickly. Interested to compare this to linkerd.

My read of the documentation also indicates a large overlap with linkerd. Hopefully one of the creators is around and can do a compare/contrast.

Not a complete comparison, but here's[1] a breakdown of Linkerd vs. Envoy (the L7 proxy that sits at the heart of Istio)

[1] https://github.com/lyft/envoy/issues/99

Re: Google and IBM announce Istio – easily secure and manage microservices

#15
post #9

Great documentation and some really great tools included. I was able to get the platform running in minikube really quickly. Interested to compare this to linkerd.

My read of the documentation also indicates a large overlap with linkerd. Hopefully one of the creators is around and can do a compare/contrast.

Some thoughts:

Linkerd is great technology but it is restricted to traffic management only. Istio provides a complete mesh that incorporates authentication and policy enforcement, in addition to traffic management and telemetry.

The Istio Auth subsystem provides certificate management and we are working on extending it to support authorization primitives as well.

The telemetry model is also different. Rather than having direct integrations with different metrics backends, we normalize metrics and pipe them through a single engine that can then re-route to any metrics backends (or multiple).

In contrast to Envoy, linkerd provides a minimalist configuration language, and explicitly does not support hot reloads, relying instead on dynamic provisioning and service abstractions.

Disclaimer: I work on Istio (on Mixer).

Re: Google and IBM announce Istio – easily secure and manage microservices

#16
post #9

Great documentation and some really great tools included. I was able to get the platform running in minikube really quickly. Interested to compare this to linkerd.

My read of the documentation also indicates a large overlap with linkerd. Hopefully one of the creators is around and can do a compare/contrast.

The overlap with Linkerd is around routing, resilience, metrics/tracing, and the deployment model (at high level).

Our deployment model is a bit more transparent. Traffic gets transparently routed via Envoy, without using HTTP_PROXY or direct addressing of sidecars. This implies zero change to application code.

Secondly, Istio brings two more things to the table: policy enforcement (rate limits, ACLs, etc.), and authentication/authorization. Istio enables mutual TLS auth between services with automatic certificate management. The policy plane is extensible, where you can plug in adapters or specific policy implementations.

Re: Google and IBM announce Istio – easily secure and manage microservices

#17

Is this going to be a linkerd vs. istio thing? Like a Docker Swarm vs. Kubernetes?

I was just wondering the same thing, since we use linkerd in production to handle thrift traffic to, from, and within our k8s clusters. But this statement from the examples page put me off a little: "If you use GKE, please ensure your cluster has at least 4 standard GKE nodes."

Re: Google and IBM announce Istio – easily secure and manage microservices

#19

What 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.

It depends on how you view it. Baking everything into the application logic works if you have a homogeneous stack. When you start going down the polyglot route, with 5-6 language runtimes, multiple databases, it becomes really really hard to maintain all the communication logic (discovery, load balancing, resilience) in the app code. Take a look at AirBnB's smartstack, Yelp, Lyft's Envoy mesh. These are all polyglot…

Maybe it depends on the size / complexity of the services. In the 'serverless' trend, such a middleware makes more sense. But essentially, moving too much logic into a middleware may support bad, lazy design decisions that make the middleware a single point of failure - like ESBs.

Re: Google and IBM announce Istio – easily secure and manage microservices

#20

Is this going to be a linkerd vs. istio thing? Like a Docker Swarm vs. Kubernetes?

It seems like it. Envoy was already competing with Linkerd, and "Istio uses an extended version of the Envoy proxy" (source: https://istio.io/docs/concepts/what-is-istio/overview.html). So it does that and more.
Post reply on HN