[HN Gopher] Istio moved to CNCF Graduation stage
___________________________________________________________________
Istio moved to CNCF Graduation stage
Author : AlexB138
Score : 151 points
Date : 2023-07-12 16:57 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| alanwreath wrote:
| I may have missed the announcement where Istio's ownership was
| being transfered to a vendor-neutral foundation like the CNCF, or
| is the Open Usage Commons What can be used in place?
| mikeyouse wrote:
| Yeah they joined CNCF last September;
|
| https://istio.io/latest/blog/2022/istio-accepted-into-cncf/
| SomaticPirate wrote:
| I think this just demonstrates the power of vendor-neutral
| Open Source. I don't mean that in an inflammatory way. Istio,
| a collaborative project from Google/IBM that was arguably
| going to be a slight differentiator for their respective
| clouds was forced to go vendor-neutral after Linkerd did.
|
| 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.
| sdesol wrote:
| Here is some community information for istio
| https://devboard.gitsense.com/istio/istio
|
| 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.
| crb wrote:
| Hi everyone, I'm the person who drove the CNCF process for Istio
| (and made the linked commit). I'm happy to answer any questions.
| hsaliak wrote:
| And yet -- grpc is still "incubating". Do these statuses really
| mean much?
| throwawaaarrgh wrote:
| Some of Google Cloud's critical APIs only seem to use gRPC over
| HTTPS. It relies on such an esoteric part of the TLS
| specification that many (most?) proxies can't carry the
| traffic. You end up hunting for 2 days to find out why your
| connections don't work only to realize they probably never
| will. So I would say it's good that gRPC isn't being pushed
| hard yet.
|
| 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.
| qbasic_forever wrote:
| IMHO that's accurate for grpc. The project works great if
| you're all golang on backend. As soon as you use other
| languages it gets complicated and the story falls apart--you
| almost certainly have to pull in tooling to manage protobuf
| generation, and proxying your grpc backend code to web frontend
| code (easy if your backend is golang, but many more options and
| questions if not). The fact grpc (and protobufs in general)
| need so much extra tooling is a bit of a code smell of
| immaturity and incubation IMHO.
| hsaliak wrote:
| Yes you need additional tooling but often, such as in C++
| it's the nature of the build environments for that language.
| There are many organizations using gRPC in mission critical
| environments along with C++.
| pjmlp wrote:
| .NET tooling is quite good, although I have only used it in
| toy examples.
| akshayshah wrote:
| It's maintained by James Newton-King, so it's in the hands
| of .NET royalty :)
|
| 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.
| pjmlp wrote:
| Even if I only briefly used it, I wish they had the same
| love for the COM tooling, after 30 years, Visual Studio
| still can't offer an IDL editing experience similar to
| editing proto files.
|
| Maybe it is about time to gRPC Windows. :)
| jayd16 wrote:
| +1 for gRPC for .NET. Its quite nice _except_ on macos. I
| forget the exact issue but there's some extra friction to
| hosting https locally on macos that makes the dev flow a
| lot more cumbersome.
| akshayshah wrote:
| gRPC had a graduation application open for 3 years. It was
| rejected very recently: https://github.com/cncf/toc/pull/300.
|
| 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.
| bushbaba wrote:
| 100% this. GRPC has nearly all its code contributions by
| google. If google removed its funding the project would be at
| risk. It's closer to a proprietary offering with source code
| available than a mature FOSS ecosystem. Think redhat
| enterprise Linux is to gRPC where-as istio/k8s is closer to
| Debian.
| phillipcarter wrote:
| They do have meaning, but the meaning is orthogonal from
| metrics like total use throughout an industry:
| https://github.com/cncf/toc/blob/main/process/graduation_cri...
|
| There is little doubt in my mind that gRPC is a larger and more
| impactful project than Istio.
| arein3 wrote:
| Hopefully grpc will never graduate as to not encourage people
| to use it. There are better ways.
| hardwaresofton wrote:
| c'mon, you gotta at least drop some of the "better ways" you
| prefer.
| devmunchies wrote:
| I prefer another CNCF incubating project, NATS. (nats.io)
|
| 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.
| dilyevsky wrote:
| There's a proto service implementation from NATS folks
| that I think does what you want -
| https://github.com/nats-rpc/nrpc
| devmunchies wrote:
| Nice! We don't use Go though :) we use F#, Rust, and C.
|
| Would love to see this work supported by the core Nats
| team. A standard spec so others could make clients.
| FridgeSeal wrote:
| Nats is a message bus/queue though, which is different
| from the serialisation format and rpc framework offered
| by protobufs +grpc.
|
| I love a good queue, but these are "orthogonal" to borrow
| a favourite HN term.
| devmunchies wrote:
| Yeah completely different tech but it can solve the same
| problem--connection and communication between services.
| Implementation details.
|
| 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.
| retinaros wrote:
| what do you people use for inter service com? http??? why?
| sdesol wrote:
| Here's the insights for grpc
| https://devboard.gitsense.com/grpc/grpc They are attracting
| less people than istio but not by much.
|
| Full disclosure: This is my tool
| AlexB138 wrote:
| Here's the PR: https://github.com/cncf/toc/pull/1000
| aidenn0 wrote:
| Enough searching around told me what CNCF is, but I still don't
| know what it means to "graduate"
| gattacamovie wrote:
| there are 3 stages of a CNCF project:
| incubation,sandbox,graduated
|
| for each there are conditions, including number of
| contributors, number of companies oficially backing it, etc.
| GenericDev wrote:
| Why would you want this?
| captn3m0 wrote:
| A "graduated" project might find it easier to get adoption,
| contributors, as the guarantees (stability, integrity,
| security, governance) are some of the criterion that org
| use while deciding on tooling.
|
| It's basically saying: If you were shying away from using
| Istio in production, we graduated, take a look now?
| nickstinemates wrote:
| Funding can be attained more readily if you have a project
| that reaches any of these stages.
| jrockway wrote:
| What are some major CNCF projects that have gotten
| investor funding in the last year?
| cyrnel wrote:
| The graduation criteria I care about is "Have completed an
| independent and third party security audit". Lots of
| software in the cloud native world puts security in the
| back seat sadly!
| mkl95 wrote:
| It's a statement that it's not some personal project and it
| is backed more or less consistently by a bunch of people.
| akhayam wrote:
| You can read more about incubated and graduates CNCF projects
| here: https://www.cncf.io/projects/
| akhayam wrote:
| Tldr: you can bring your open source project to CNCF and if
| there are enough infra/platform developers vouching for it
| then you can become an incubated project. After that, there
| is a bunch of boxes (traction, integration, stability) that
| you need to check before CNCF endorses you as a graduated
| project.
| aidenn0 wrote:
| So it's just a stamp of approval?
| AlexB138 wrote:
| Sort of. It's also a statement of maturity.
| mdekkers wrote:
| > Sort of. It's also a statement of maturity.
|
| And of funding. Some of the hoops such as a 3rd party
| audit are _not_ cheap
| eddythompson80 wrote:
| Also a lot of projects in sandbox or incubation are
| "finding themselves" so to speak. It's what used to
| happen when a project would release a v1 that's really
| mostly a POC, then have some major overhauls/rewrite in
| v2/v3. At least in theory by "graduation" or v3, you know
| that this thing has a non-trivial user base, fairly
| defined in what it does and how it does it. Some
| independent reviews and established patterns etc.
|
| Nothing protecting them from rotting or dying or breaking
| obviously, but at least you know you won't be shouting at
| it alone.
| dpedu wrote:
| But what does it actually mean? Is this in incubator in the
| same sense as a startup incubator? This just sounds like a
| popularity contest, where the winners get a stamp of
| approval from the CNCF, provided you play by their rules.
| What value does the CNCF add?
| dwaite wrote:
| Think of it as process maturity. They don't want to just
| rubber-stamp some company's project as a "CNCF" project,
| only to have it collapse when the company pulls employees
| off it.
| nickstinemates wrote:
| As a gatekeeper (and as a result, status, attention,
| prestige, etc.)
|
| Funding can be attained more readily if you have a
| project that reaches any of these stages.
| zgluck wrote:
| It's about the modern day J2EE - Kubernetes. Approximately the
| same cost per "getting something done" ratio. Exactly the same
| kind of orgs (both on the seller and buyer sides). I hear the
| money is good though, if you're into that kind of slow work.
| jupp0r wrote:
| You might not know what J2EE or Kubernetes do if you compare
| them like that.
| zgluck wrote:
| I know and understand both technologies in enough detail,
| thank you. They were/are abused as instruments of
| complexity by consulting firms. They are both fantastic at
| this purpose.
|
| 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...
| KnobbleMcKnees wrote:
| The problem you're describing is consultancies, not
| Kubernetes.
| zgluck wrote:
| Yeah, but like J2EE, Kubernetes will become synonymous
| with waste [in the public sector] in about 5-10 years
| from now.
|
| I mean, you've got to admit, it's a repeat of history?
| goalonetwo wrote:
| We are using istio at scale.
|
| 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.
| ushakov wrote:
| have you tried Contour yet?
|
| https://projectcontour.io
| crb wrote:
| Contour is a gateway: a controller that manages Envoy proxies
| at the edge of a Kubernetes environment. Istio is a service
| mesh: a controller that manages Envoy proxies at the edge and
| alongside each workload. If you are using Istio, you probably
| don't need Contour.
|
| 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.
| datadeft wrote:
| > It is very complex and builds on 5 other layer of abstraction
|
| Yeah this is a definite no for me.
| Niksko wrote:
| Boy do I have bad news for you about all of modern
| software...
| davewritescode wrote:
| We also run Istio at scale and feel the same way. During
| adopting it's a pain, when it's up and running it's a dream.
| awestroke wrote:
| If I needed a service mesh, I'd probably use Linkerd. What would
| I be missing out on?
| crb wrote:
| I like to equate the question to "If I needed a container
| orchestrator, I'd probably use Nomad. What would I be missing
| out on with Kubernetes?"
|
| 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.
| otterley wrote:
| > the former has a single vendor behind it, and the latter
| has almost all the cloud industry
|
| 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.
| 0xEFF wrote:
| This is a good analogy. For more context in the past 5 years
| working with customers in the Bay Area I've not encountered
| one who mentioned linkerd let alone ran it in production.
|
| More than half those companies ran istio in production at
| large scales.
| AlexB138 wrote:
| Here's the official CNCF announcement:
| https://www.cncf.io/announcements/2023/07/12/cloud-native-co...
| meepmorp wrote:
| In case anyone wants to read the rendered markdown:
|
| https://github.com/cncf/toc/blob/main/proposals/graduation/i...
| akhayam wrote:
| Finally... took a while.
|
| Now CNCF needs to figure out how to get Istio to work nicely with
| the networking k8s addons
| dirteater_ wrote:
| The CNCF doesn't really dictate that kind of stuff. If
| something doesn't play nice try the Istio slack or file an
| issue on the main repo: https://github.com/istio/istio
___________________________________________________________________
(page generated 2023-07-12 23:00 UTC)