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.
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.
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.
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.
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.