71–80 of 123 posts
Project Calico Network Policy Engine: https://www.projectcalico.org/welcoming-istio-to-the-kuberne...
WeaveWorks: https://www.weave.works/docs/tutorials/istio/istio/
I'm curious what the benefit of side-loading proxies and load balancing versus centralization provides?
Disclaimer: I work on Istio
1. https://groups.google.com/forum/m/#!msg/kubernetes-sig-netwo...
Why aren't more people using MQ for inter-service messaging (something like RabbitMQ) instead of HTTP?
MQ shines in async calls/event delivery. gRPC / http2 / websockets / thrift is better for synchronous calls ?
I can't see a reason why one would use gRPC/thrift and then having to build flow control, delivery guarantees and other messaging features yourself.
Why aren't more people using MQ for inter-service messaging (something like RabbitMQ) instead of HTTP?
This may be the most important project in distributed computing in a long time. It solves some fundamental problems that layer 3 networking has been unable to tackle. Its initial integration with Kubernetes is great but long term it could be the basis of all application level communication whether it is deployed in a container orchestration system, VMs, bare metal or as an enabler for Lambda (function) frameworks.
Why aren't more people using MQ for inter-service messaging (something like RabbitMQ) instead of HTTP?
Earlier 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…
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/obs…
Why aren't more people using MQ for inter-service messaging (something like RabbitMQ) instead of HTTP?
Maybe I should have blogged about it :)
Anyway, although all the design principles are the same: 1) Transparent and seamless to application code, 2) Control communication end points, the MQ constructs and languages are not as accessible and readily available and visible as HTTP and RESTful.
A MQ can be temperamental and hard to operate. On the other hand, even middle-schoolers can master nginx, haproxy, write their own, etc with a bit of guidance :)
Popularity and rate of adoption depends on availability to the masses and the ease with which the masses can learn to use. If it takes to long (say, 15 minutes) to bring a framework up, hordes of engineers will find a massive number of reasons to roll their own ...
Are those numbers right? Wouldn't it be the other way around realistically?
> Lyft developed the Envoy proxy to aid their microservices journey, which brought them from a monolithic app to a production system spanning 10,000+ VMs handling 100+ microservices. Are those numbers right? Wouldn't it be the other way around realistically?