Istio moved to CNCF Graduation stage
github.com
github.com
I have a love-hate relationship with it. It is very complex and builds on 5 other layer of abstraction (K8s, Envoy, Iptables,...). Grasping what is going on requires you to understand all of those layers first. Istio essentially adds one layer of proxy for all your ingress/egress requests and from an engineering/performance/cost perspective that is not amazing.
Once it is working and deployed though it provides a solid set of functionalities as part of the infrastructure directly. AuthN/Z, mTLS, security, metrics and logs are all deployed by default without the end-user having to do anything.
Eventually I expect Istio will evolve to a model that makes more sense with Ambient/eBPF (For cost/performance reasons)
The community behind Istio is especially helpful and one of the main reasons why we went with this project.
Yeah this is a definite no for me.
A year ago, a number of Envoy gateway maintainers (including Contour) announced their intention to join up to build one implementation of an Envoy gateway. They haven't made a lot of noise since, but they are apparently up to v0.4.
https://blogs.vmware.com/opensource/2022/05/16/contour-and-c...
You can also use the Gateway API to manage Istio. So, if you are using Istio, you probably don't need Envoy Gateway either.
Wherever you look, it's still Envoy. Unless of course you look at Linkerd, who have their own thing.
Last commit at Nov 28, 2022.
In kubernetes world it means that this project is dead, I guess?
We still haven’t achieved an amazing distributed tracing strategy, we don’t use its MySQL or Redis interfaces, and haven’t rolled out more advanced features like smart retries. It’s hard to get momentum on that versus other must have work.
But for mTLS and authn and authz, it works great. Thanks for the hard work.
There is little doubt in my mind that gRPC is a larger and more impactful project than Istio.
Full disclosure: This is my tool
A bit awkward to use but lots of great info there. I use it every now and then (I'm a maintainer of Dapr).
If you goto to https://devboard.gitsense.com/dapr/dapr?board=gitsense_examp... you can see how my DevBoard widget system is different than Grafanas. Note, the repo that I talk about in the Intro page hasn't been pushed to GitHub yet, but will be soon (hopefully by the end of this week). I'm planning on creating widgets where you can just feed it some numbers and it will generate a graph, but since my widgets can be programmed, you can do much more with the data to tell a story and to help surface insights.
Unlike the other gRPC implementations, it's also taken seriously by MSFT's entire developer division. MSFT contributed a bunch of performance improvements to the protobuf runtime and generated code for .NET, the Kestrel webserver team runs gRPC benchmarks, and support for gRPC-Web is baked right into the core frameworks. From a user perspective, it's clear that someone cares about how all the pieces fit together.
Maybe it is about time to gRPC Windows. :)
Reading between the lines, it sounds like the main problem is Google's tight control over the project. Apple contributes to the Swift implementation and MSFT drives the native .NET implementation, but there's little non-Google input in decision-making for Go, Java, C++ core, or any of the implementations that wrap core.
More subjectively, I'm impressed by the CNCF's willingness to stick to their stated graduation criteria. gRPC is widely used (even among other CNCF projects), and comes from the company that organized the CNCF - there must have been a lot of pressure to rubber-stamp the application.
It decouples the service addresses via a pubsub architecture.
So if I want service A to send a request to service B, then it is done by subscribing to a shared topic, there is no service discovery.
It kind of replaces GRPC and Istio.
I like the “static typing” and code generation you get from grpc so a hybrid of the 2 would be my preference.
I actually solved the code generation part for NATS though by using AsyncAPI (like Open API but for messaged based systems). Would be better if baked in.
Would love to see this work supported by the core Nats team. A standard spec so others could make clients.
I love a good queue, but these are “orthogonal” to borrow a favourite HN term.
If you don’t think about the tech between services, at the end of the day my service is using some protocol to send and receive data, using grpc or otherwise.
NATS has a clean request/reply paradigm built in that makes this simpler.
The proto files format is ok, because it has nullability defined in the type.
However everything else is bad. I had to use grpc on a project and it was a pain and created problems.
Want to use postman to test locally? Forget it, you have to use some grpc client, and all of them are not ideal.
Want to write automation tests? Good luck finding a tool that supports grpc.
Want to add distributed tracing to calls? You have to use some unofficial code, and better learn the grpc implementation details if you want to be sure that the code is good.
Use json over http, or json over http2 if possible. You will have a much better and less frustrating experience.
Grpc is good for servers moving petabytes of data and for low latency needs (compressed json over http2 would be the same performance in terms of low latency, maybe a few percent slower). I guess 99% of it's users would do much better with a json over http interface.
Nowdays it is very easy to make an http call. In java it can be done with an annotation over an interface method, ex: https://docs.spring.io/spring-cloud-openfeign/docs/current/r... It is also recomended to store the data types used in the interface externally, similar to how proto files work, so that you don't have code duplication on the client and the server.
gRPC itself runs on top of HTTP.
On a personal level, it's one of those projects that someone obsessed with "perfect engineering" develops, regardless of the human cost. Crappier solutions (ex. JSON-over-HTTP) are better in almost all cases.
gRPC _does_ require support for HTTP trailers, which aren't used much elsewhere. If you want to use streaming RPCs, you also need a proxy that doesn't buffer (or allows you to disable buffering).
You couldn't get a better example of good pragmatic engineering than gRPC compared to something like CORBA or DCOM. I can't talk about "all cases" but in the cases I've come across it's a much better solution than JSON over http.
Ignore the CNCF for a second. Both are open source, so will survive regardless, but the former has a single vendor behind it, and the latter has almost all the cloud industry.
There are valid use cases for FreeBSD, but the default choice is Linux.
More than half those companies ran istio in production at large scales.
The same could be said about Apple products, but that doesn't mean people should be dissuaded from using them. Quite the opposite: being in charge of a technology means you can be 100% focused on it and be relentlessly focused on making it great for your customers.
Anyone who reads these comments should be able to get an understanding of both service meshes without having to research other software.
Are you saying that istio IS kubernetes and linkerd is not? I don't think linkerd WANTS to be kubernetes.
I love your podcast, Craig, but this "hot take" is too hot to hold
Part of these decisions are based on things like “What is the rest of the industry doing?” “How vibrant/diverse is the community?” “How mature is the project _for enterprise adoption_?” “What vendors are available for enterprise support?” “Is it already available in my platform of choice?” etc.etc.
The sting of “picking the wrong container orchestrator” is still fresh in a lot of organizations.
We see Istio make it through these questions with good answers for a lot of organizations where other/alternative service mesh vendors strike out pretty quickly.
This is even before we get to the “feature comparisons” for usecases these large organizations focus on/have.
As an enterprise Hashistack customer, every time I contact Consul support, they assume I'm using Kubernetes instead of Nomad, and when I tell them I'm using Nomad, I get blank stares.
Vault is great, and Consul is...fine, but the Consul PMs saw which way the orchestrator market was trending (towards k8s domination) and have adjusted their priorities accordingly. But if I had my way, I wouldn't touch the Nomad+Consul stack with a 20-foot pole ever again.
Thankfully we don't have to talk to Consul support very often, but each time we meet with Consul product people it's like they don't even know Nomad exists.
We're starting to adopt Consul Service Mesh with Nomad and I am not excited.
https://github.com/cncf/toc/blob/main/proposals/graduation/i...
Same thing happened to Knative.
CNCF definitely has some politics but its been interesting to see large OSS projects be essential dead on arrival now if its not in a vendor neutral holding org.
I personally try to favor vendor neutral projects now. Slightly smaller chance of being burned like I was with Grafana switching licenses.
for each there are conditions, including number of contributors, number of companies oficially backing it, etc.
It’s basically saying: If you were shying away from using Istio in production, we graduated, take a look now?
And of funding. Some of the hoops such as a 3rd party audit are _not_ cheap
Nothing protecting them from rotting or dying or breaking obviously, but at least you know you won’t be shouting at it alone.
Funding can be attained more readily if you have a project that reaches any of these stages.
Of course it's also possible to use this tech to actually get stuff done. But that's not what it's widely used for in this consulting environment.
The typical end-customer is you (the tax payer.) You have no influence over what you paid for, though. Also: it's a recurring cost, like Netflix. It doesn't really stop...
I mean, you've got to admit, it's a repeat of history?
Not kubernetes level https://devboard.gitsense.com/kubernetes/kubernetes but still very good.
Full Disclosure: This is my tool, but I figure the insights would be interesting/useful.
Now CNCF needs to figure out how to get Istio to work nicely with the networking k8s addons
Jokes aside, Envoy really deserves some spotlight.
How do I do that exactly? I need to install some iptables rules inside a pod to redirect pod traffic to envoy?
You're spot-on about using iptables rules. There is an example here with a yaml configuration and some iptables commands: https://github.com/envoyproxy/envoy/blob/main/configs/origin...
You might be able to re-use some of that. It should be pretty easy to get metrics for outbound/inbound http requests, but I don't remember the exact yaml incantation.
install istio, turn off mtls if you dont want that (https://istio.io/latest/docs/reference/config/security/peer_...) and you have what you’re looking for. doesn’t get simpler than that.
Also I'm worried about its pervasiveness. Is it possible to enable those side-cars only on selected pods?
It's not possible to disable mtls with meshed services, no configuration option for this particular feature.
There's no pervasiveness with linkerd, one need to add `linkerd.io/inject: enabled` annotation to the target service and restart deployment.