3 ms·
Standardised declarative config/setup I've found really useful, declarative resource specification (as in n servers for service y) I don't really have a use for
by grey-area 6y ago
Standardised declarative config/setup I've found really useful, declarative resource specification (as in n servers for service y) I don't really have a use for though I could see how in larger companies with hundreds of servers and lots of employees it would be attractive. If it is rock solid and reliable and impossible to mess up, I could see it being really nice (as your experiences sounds), though it feels to me like end users of services like GKE should not have to know about kubernetes or its complexity, nor have a chance to mess it up by editing configs directly.
I guess the ultimate goal of services like GKE autopilot is for you not to have to worry about kubernetes at all, just give them your workload and have it run on whatever resources they think is appropriate?
I do think it's important to recognise though that there are lots of ways to host services, and simpler with less abstractions is often better and more reliable and certainly easier to debug when things go wrong.
- te_chris 6y agoI mean yeah, I’m not arguing against autopilot and would probably have used it if it existed when we kicked off. Cloud Run had just come out and I really wanted to use that but the networking wouldn’t do what we needed, so had to go all in. But in the end, we learned enough Kube, we specified it all with Terraform, we haven’t tried to do too many fancy or complicated things, and we have reliable infrastructure fed with a simple deployment/build pipeline (just using cloud build, it’s clunky but it works). I mean maybe I’m conflicted as we’re part of GCS, but the system works well for us. If it didn’t we could’ve jumped to Azure or AWS and got credits there.
- grey-area 6y agoSounds like a nice reliable experience to me, thanks for sharing your experience on it. If I hear more reports like this I might just have to try out GKE :)