HN user

sg1234

24 karma
Posts0
Comments12
View on HN
No posts found.

The industry is changing. Coding is becoming a commodity, which means other skills will have to be developed and mastered to meet the future demands. We will still need people to build a platform to run AI. To maintain software to do Inference, to maintain a pipeline to train AI...

The abstraction layer is being pushed higher

OSS has always been vulnerable to this. AI is accelerating, but changing the license doesn't guarantee adoption. It's not just because someone forked a project and changed license that suddenly everyone will start using that tool/library..

And the comparison to the music industry is fair, but the key difference is that in Software we had a Free/OSS movement for a while, and it did not kill the industry, on the contrary, it benefited from it.

[dead] 1 year ago

KRO (pronounced “crow”) or Kubernetes Resource Orchestrator is an Open Source tool built in collaboration between Google Cloud, AWS and Azure.

Kube Resource Orchestrator (kro) is a new open-source project that simplifies Kubernetes deployments . It allows you to group applications and their dependencies as a single, easily consumable resource. It's compatible with ECK, ASO and KCC

GitHub - https://github.com/kro-run/kro

Google Cloud - https://cloud.google.com/blog/products/containers-kubernetes... AWS - https://aws.amazon.com/blogs/opensource/kube-resource-orches... Azure - https://azure.github.io/AKS/2025/01/30/kube-resource-orchest...

[dead] 2 years ago

GKE Newsletter for those who want to keep up with what's going on with GKE. Also contains Google Cloud News

Would you feel more comfortable if you had an in cluster agent that dial into a Google Managed API and receives command from it ? This way your control plane can be private and you don't have to handle Managed Authorize Networks.

Sorry, but that's the nature of standardisation, and the price you pay if you want to show you're really vendor-neutral. For me, actions like these make Istio go from the almost de-facto default choice for a service mesh, to suddenly wanting to consider other stuff.

That's not what the Cloud industry is about, it's about speed and time to market.

and it's in their best interest that things are complicated as they can make money out of that.

Valid point, i have no evidence to support this, i just feel like CNCF looks for any opportunity to monetise itself for reasons i don't understand (Certifications, Conferences...). For a non profit that doesn't hire the core developers of the tools they support (most are hire by tech companies) i don't see why kubecon should cost 1k$+

Disclaimer: i work for Google Cloud and use istio daily.

I don't think this matters to practitioners, it's a solution to fix trademark issues.

Open Source Licenses (like Apache under which istio is released) doesn't solve the trademark (TM) issue, they are vague around this topic, so the use of the name/logo/mascot to release any sort of managed or supported solution based on an OSS tool becomes a hurdle, a lot of money is at stacks here (imagine if k8s was still under the control of Google, AWS or Azure will never be able to launch something called Kubernetes engine because there is a risk Google will sue them).

The problem with CNCF and why istio was not transferred to that org is that CNCF acts as a mediator, so any decision around trademark takes soo much time and effort because CNCF has to get the blessing of everyone or build something neutral (like the k8s certification), and it's in their best interest that things are complicated as they can make money out of that.

The OUC was created to solve the TM issue and allow decisions to move fast, the usage guidelines haven't changed and will likely not change.

I do have to admit that myself i don't understand why no one from IBM is in the initial board of OUC