Six months from now half of these abstractions will have been renamed or removed once real users push back on the cognitive overhead. Google has a pattern of releasing infrastructure that's perfectly shaped for Googles problems and awkward for everyone else's
It's super neat! Just like Kubernetes is also super neat at what it can do. It's super neat primarily because consuming it is so easy, provided you already have all the same abstraction layers in place in your infra.
You...do have all the same abstraction layers, right? No? Oh. Well, don't worry, Google/Amazon/Microsoft can sell you those if you don't want to pay your IT staff to prop it up for you.
---
Look, snark aside, yours is the correct take. Google's solutions are amazing, but they're also built for an organization as large and complex as Google. Time will tell if this is an industry-standard abstraction (a la S3 APIs) or just a Google product for Google-like orgs/functions (a la K8s).
[primary author and architect of scion here] Part of this will be pushing that cognitive overhead increasingly onto agents. By how much and when is what Scion is here to explore.
Like Kubernetes?
I think most of the legacy companies that can benefit from Kubernetes don't use it, while most of the companies that are using it are startups doing it for the résumé.
This is the exact opposite of my experience. Maybe it was true 10 years ago when K8s was new and trendy so many engineers wanted to try it out. Now it's just boring tech at large orgs.
I'm proud to say I retired more k8s clusters than I created. And I've created 5 production ones, still in production.
One that I retired was used for serving ftp(among other transfer stuff), ftp of all things, it needs to have ports open and routed back from the client. And for extra points they had the pods capped at 1 cpu. And I had to explain the thing to the perpetrator and their boss, madness.
It's also much easier to bring online these days with managed offerings like GKE, EKS, and AKS.
I have no love for the original bash scripts that booted the cluster from your dev machine.
Now we also have k3s that is a easy option for self hosting something simple (like homelab).
This is not 2015.
Slightly trailing off from your focus, but hopefully within the same sentiment (that k8s was good, albeit an exception)
I would place Google ADK in alignment with Kubernetes more than this project, for the well designed abstractions, the controlplane, and handling the boring parts that every alternative will at maturity.
I can see the agent framework ignorance to the container analogy about what's running inside. ADK lacks the ability to run any agent tool, but you can build most of this projects controlplane on top of it with minimal effort, most of the bookkeeping is there already. It's more about what experience you want to have.
Yes, and unironically.
And angular.
[dead]
kubernetes isnt difficult
k8s is simple because it offload some key tasks to 3rd party like network and storage; it is not easy to: a) setup and maintain a k8s cluster with all necessary components from at least a dozen different sources b) design your application to be k8s native
This. K8s is easy to consume, and a real PITA to actually setup and support from an IT perspective.
If someone wants production K8s, I'm steering them (and their budget) to a managed control plane from one of the major cloud providers. Trying to prop it up locally when it really hates having to work directly with bare metal does not spark joy.
really?
The same way linux isn't. It's easy to start, all the base modifications/configurations are fairly simple, and if you find yourself deep into custom ways of using it, it's open source and fairly well documented with a large community.
100%. Great assessment.