61–70 of 123 posts
Earlier quoted context omitted.
Good question. The auth work for this release is mainly focusing on service-to-service authentication. We are looking into adding OAuth2 and JWT support for enduser auth in the future release. Disclaimer: I work on Istio
Cool. Also - what does Istio use for persistence? I imagine it's gonna persist the data for auth'ing stuff somewhere.
Earlier quoted context omitted.
Good question. The auth work for this release is mainly focusing on service-to-service authentication. We are looking into adding OAuth2 and JWT support for enduser auth in the future release. Disclaimer: I work on Istio
BTW, if you are interested in Istio auth future work, here is the list: https://github.com/istio/auth#future-work Disclaimer: I work on Istio
Earlier quoted context omitted.
Regarding API gateway products, Apigee will actually work with Istio https://apigee.com/about/blog/digital-business/simplifying-m...
That's an example of the breakage though. Apigee's cloud runs in only 2 specific AWS regions. So once you tie all these pieces together, you end up with a long path, with some functionality that should be closer to the end user.
(I work for the Apigee part of Google.)
Why aren't more people using MQ for inter-service messaging (something like RabbitMQ) instead of HTTP?
Why aren't more people using MQ for inter-service messaging (something like RabbitMQ) instead of HTTP?
But message queues are usually an added complexity for realtime inter-service messaging.
Can someone ELI5 how is this relating to, and complementing, Kubernetes? What does it do that Kube doesn't, and what does Kube do that Istio doesnt?
But it doesn’t help with higher-level problems, such as L7 metrics, rate limiting and circuit breaking.
This is where Istio comes in.
Disclaimer: I work on Istio.
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.
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…
As long as proxies remain transparent to services, I see no problem. It becomes a problem, when proxies are getting smarter in terms of providing cross cutting features, like routing on payload level (not speaking of message headers) or do authentication and authorization on a per-resource level. That puts constraints on how services are built in this particular environment.
But I see the logic behind approaches, developed by Netflix, and now Istio. If you have a lot of services, orchestration and more central communication management is probably a good way to govern, if the constraints (described above) are accepted and services still have the ability to opt out and pursue a different strategy.
The old SOA world was driven by governance. This was a result of the general engineering methodologies and mindsets of this time. Still, API Gateways / smarter proxies / etc. could bring that back...
There 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-...
Earlier quoted context omitted.
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 mul…
But with single point of failure, I don't mean outages. I mean, is it open and transparent enough towards your endpoints, that you can easily replace and / or fix things. Vendors go out of business or even a larger issue: your business changes.