Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google and IBM announce Istio – easily secure and manage microservices

developer.ibm.com

Post reply on HN
Print view View original

21–30 of 123 posts

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

#21

Post by dougreid »

markbnj wrote: post #17
misterbowfinger wrote: post #7

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

That suggestion is based on the requirements of the underlying bookinfo sample application and is not related to Istio itself.

Disclaimer: I work on Istio.

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

#23

Post by markbnj »

dougreid wrote: post #21
markbnj wrote: post #17

Earlier quoted context omitted.

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

That suggestion is based on the requirements of the underlying bookinfo sample application and is not related to Istio itself. Disclaimer: I work on Istio.

Thanks for the clarification!

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

#24

Post by rdli »

einrealist wrote: post #19
rshriram wrote: post #12

Earlier quoted context omitted.

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.

The middleware in this case doesn't work like an ESB in the sense that all connections are point-to-point, intermediated by a service discovery mechanism. So you're not putting all your L7 traffic onto a big bus.

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

#26

Post by agentgt »

einrealist wrote: post #19
rshriram wrote: post #12

Earlier quoted context omitted.

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.

I'm a big fan of buses or perhaps more accurately I guess semi intelligent pipes with semi intelligent endpoints.

I have used RabbitMQ (and Kafka at times) for large portion of my career and anytime I tell people this the bring up the single point of failure.

The single point of failure arguments is getting really old and is fairly baseless particularly if your storage (e.g. RDBMS) or network (single zone or even multi zone load balancer) is also not a single point of failure.

So to avoid this red herring of a problem for many who really don't need to solve that problem they create massively complicated endpoints.

This endpoint code is proprietary and often has to be deployed at the same time and creates fairly tight coupling. The Netflix Hystrix creator (Ben Christensen) discussed this issue at length here: https://www.microservices.com/talks/dont-build-a-distributed... (its also ironic that he built Hystrix and various dependencies which are sort of the antithesis of this... I guess 20/20 hindsight).

There are pros and cons and its not always "lazy design decision".

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

#27

Post by puzzle »

einrealist wrote: post #8

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.

Smart endpoints in N different languages means you have to do the same work (auth, rate-limiting, etc.) N times.

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

#30

Post by geodel »

vishvananda wrote: post #11
moondev wrote: 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.

One important difference I see is istio works only with kubernetes/bluemix, whereas linkerd has many more deployment options.
Post reply on HN