31–40 of 123 posts
Google Cloud Platform Blog Post: https://cloudplatform.googleblog.com/2017/05/istio-modern-ap...
IBM: https://developer.ibm.com/dwblog/2017/istio/
Redhat: https://blog.openshift.com/red-hat-istio-launch/
Pivotal: https://content.pivotal.io/blog/pivotal-and-istio-advancing-...
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
One important difference I see is istio works only with kubernetes/bluemix, whereas linkerd has many more deployment options.
The initial release for Istio is targeted at kubernetes. However, Istio is designed to be easy to adapt to other environments. With community help, we anticipate extending it to enable services across cloud foundry, VM, and hybrid clouds. We hope to have major new releases every 3 months, including adding new environments.
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 problem with SOA-in-practice was that everything flowed through a monolithic ESB as both client and origin server, that needed to have omniscient knowledge of every route, transformation, etc., and was often a single administrative bottleneck, fault domain, etc. Some SOA frameworks had service mesh patterns where you could deploy decentralized engines with your services, but without cloud IaaS/PaaS circa 2006-2007, there was no way to maintain/deploy/upgrade these policy agents without a heavy operational burden.
In sum: CORBA, COM+ or SOAP/HTTP were about mostly-centralized approaches to distributed services, REST was about extreme decentralized evolution over decades, most are looking for something akin to a dial where they can have something a bit more controlled than dozens of independent gRPC/HTTP/Rabbit/Kafka producers-consumers but not stupid like the SOAP/HTTP days.
Modern cloud native service mesh approaches like this Istio thing (NetflixOSS Zuul+Eureka+Ribbon or Linkerd are alternatives) are just decentralized gateways and proxies, possibly with a console/management appliance that makes it easy to propagate changes out across a subset of your microservices. This has the benefit of allowing you to default to decentralized freedom for your various microservices but for areas where you want administrative control over policy over a set of them , you don't have to go in and tweak 15 different configs.
NetflixOSS really pioneered this pattern. Netflix managed to use things like Cassandra and Zuul hot-deploy filters as the means to updated routing/health/balancing configs across their fleet of microservices. There are alternative ways to handle this of course - Hashicorp's Consul piggybacks DNS and expects your client to figure things out via their REST API or DNS queries. There are also things like RabbitMQ or a REST-polling mechanism to propagate config changes perhaps, as not everyone wants Cassandra. New frameworks like Istio or Linkerd are further alternatives. We're spoiled for choice, better or worse..
[Deleted]
Full Disclosure: work at IBM, but not in Watson.
[Deleted]
Earlier quoted context omitted.
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.
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…
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…