[halbritt]

My org made a similar transition. It's hard to articulate exactly precisely how much we saved as our "production" or revenue generating environments are roughly the same.

We transitioned out of AWS where we had relatively well managed instances of our stack managed with chef and terraform to GKE in Google Cloud where we migrated to a helm chart and custom orchestration tooling on top of that.

Prior to the migration I'd say that 80% of our instances were idle. Currently, all of our k8s nodes with 16 cores are running with an average load 5-7. We try to keep enough headroom to prevent any waiting or queuing, which is an entire medium blog post unto itself.

So, roughly the same or a little more "production" workload, but the number of non-prod instances of our stack quadrupled. Anyone in the org at any time can spin up an instance of the stack for a custom sales demo, to debug an issue, to test a feature, or anything else. There was a great deal of pent up demand that nobody expected and which caused my team to thrash a bit to catch up to when we made the transition.

All in all, our GCP spend is about 20% less than our AWS spend was. We're getting a lot more utility for a little less money.

[falcolas]

Idle instances are what autoscaling groups were made for. Frankly, if there are a lot of idle instances, AWS features are not being taken advantage of - that's not on them.

[adwf]

Only if you've got a homogeneous workload that can scale out.

More typical is Team A working on Project A spin up a test DB + test app server. Team B also spin up a test app server + web server + DB for project B

Then Project A gets productionized and you have SIT/UAT/Stage copies of all of that sitting mostly idle.

Then project C comes along and the devs need to test on a 3 node C* cluster with 3 kafka brokers...

Suddenly you have a whole bunch of dev environments sitting mostly idle. No-one would ever fork out on reserving a t2.medium, but they all add up to $$$$$ every month. With k8s you can reclaim all that idling power, reserve some beefy instances, whilst also gaining easily deployable artefacts, CI/CD, production scaling, etc.

[falcolas]

But those use cases don't change between AWS and GCE. They only change if you start using containers in a container environment; something possible in AWS and GCE.

[halbritt]

The distinction is between traditional config management and instances vs. Kubernetes. I could've seen similar benefits running k8s in AWS. I simply chose GKE because it's superior to other offerings.

There are other things to like about GCP vs. AWS, but that's a bit tangential.

[wgjordan]

Seconded. If the primary driver of this transition was 'getting a lot more utility for a little less money', then simply adopting Auto Scaling Groups within the existing AWS setup could have improved instance-utilization with much less migration effort.