Is the sidecar-container-within-a-pod the only deployment option on Kubernetes currently? Is a daemonset deployment (like what Linkerd does) option currently in the works?
Google and IBM announce Istio – easily secure and manage microservices
101–110 of 123 posts
Re: Google and IBM announce Istio – easily secure and manage microservices
#102Earlier quoted context omitted.
"spanning 10,000+ VMs handling 100+ microservices" ?
Sorry...thanks...let me clarify the question, why on earth does Lyft have 10,000 VMs??? They have less than 200,000 rides per day. That's a 1 VM to 20 rides per day ratio.
They likely do a huge amount of data analytics.
Re: Google and IBM announce Istio – easily secure and manage microservices
#103Earlier quoted context omitted.
MQ shines in async calls/event delivery. gRPC / http2 / websockets / thrift is better for synchronous calls ?
With the ISO/oasis standard AMQP you can actually do synchronous calls without an intermediary. You also have 'direct' message routing capability with components like apache qpid dispatch router. 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.
gRPC is built on http/2. I imagine it supports flow control and delivery guarantees already? It's just http/2 + protobuf
Re: Google and IBM announce Istio – easily secure and manage microservices
#104Why aren't more people using MQ for inter-service messaging (something like RabbitMQ) instead of HTTP?
One of the goals of Istio is to move the machinery out of the app. While a message queue/broker such as RabbitMQ or NATS is brilliant at distributing requests, you do have to build the glue — both the client and the server — into every single app, in every single language. You also need to write the edge proxy that mediates between HTTP and whatever the message queue/broker solution uses.
Istio (or rather, Envoy) acts as a plain HTTP proxy, meaning a client can just respect the standard http_proxy environment variable (which most client libraries do), meaning a client can just do HTTP and doesn't even need to know about the proxy. Even "curl" will work with Istio. And it's even simpler on the server end; all a server needs to do work is to accept HTTP connections.
Last I heard, Istio aims to go even further by supporting the proxying of any networking protocol (Layer 4).
Re: Google and IBM announce Istio – easily secure and manage microservices
#105Earlier quoted context omitted.
I'm not sure if you're trolling or genuinely don't understand, so I think I can help you a little bit. Microservices are services that are generally containerized and are easily distributable through some form of a network to be easily replaceable parts. These services are defined by a specification where they do a single task, expose some endpoint or API and are composable with other microservices. There is a need f…
Nice. Thanks. I'm perfectly serious -- obviously the OP didn't define microservices -- you did. Good for you. Bad for the OP. Okay, microservices look like what used to be called agents . For their communications there have been various efforts at ways to define data objects , complete with a registration hierarchy (that is, a case of public naming) and an inheritance hierarchy (roughly like some of inheritance in so…
There's some reading here
https://hn.algolia.com/?query=microservice&sort=byPopularity...
Re: Google and IBM announce Istio – easily secure and manage microservices
#106I know it's a higher architecture. But could anyone tell me the difference between istio and springcloud/dubbo?
Re: Google and IBM announce Istio – easily secure and manage microservices
#107This 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.
I agree with your point about layer 3 networking being unable to easily tackle these problems. I question though, whther Istio is "all that". Securing an endpoint without requiring changes within the endpoint has been done for some time - Whale Communications, which became Unified Access Gateway, F5 Big IP, IBM DataPower... They are called web application firewalls, and unless I'm missing something Istio is no more t…
You are missing experience working in an environment with endpoint scale. You can't configure the O(N^2) paths between application instances changing every hour with those kinds of systems.
Re: Google and IBM announce Istio – easily secure and manage microservices
#108Earlier quoted context omitted.
Sorry...thanks...let me clarify the question, why on earth does Lyft have 10,000 VMs??? They have less than 200,000 rides per day. That's a 1 VM to 20 rides per day ratio.
I guess they're building with future growth in mind. What if they decide to expand to the rest of North America in the near future and have a sudden spike?
Then you spin up more VMs when you do the expansion.
Re: Google and IBM announce Istio – easily secure and manage microservices
#109There 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-...
I am wondering how Istio is related to Openshift (the Redhat blog post didn't give that much information). Will Istio be integrated into Openshift or simply added as an application to be installed from the catalogue?
OpenShift is based on Kubernetes, and I expect istio to integrate well as a general service to service mesh. Catalog exposure will be useful and something that will get targeted at some point (maybe not right away)
Re: Google and IBM announce Istio – easily secure and manage microservices
#110Is the sidecar-container-within-a-pod the only deployment option on Kubernetes currently? Is a daemonset deployment (like what Linkerd does) option currently in the works?
We have been looking into a per-node deployment model from the beginning, which is what daemonset is doing. Things get more complicated across the board with the transparent traffic capture at the node network namespace level, invasive installation requiring tight integration with k8s and reconciling iptables rules, and a more complicated workload identity story. We have started with the sidecar model, but are certainly interested in more deployment options