Re:Google Kubernetes Engine is introducing a cluster managem...
by onefuncman on Thursday March 05, 2020 @06:30AM
(#22492672)
I think you're wrong -- containers aren't ready for legacy enterprise, VMs are a better choice of abstraction for an initial move to cloud.
Get your data centers all running VMWare, then VMDK import to AWS AMIs, then wrap them all in autoscaling groups, figure out where the SPOFs have moved to, and only then start moving to containers.
In the mean time, all new development happens on serverless.
Don't let anything new connect to a legacy database directly, only via API at worst, or preferably via events.
Re:Google Kubernetes Engine is introducing a cluster managem...
by varshithr on Thursday March 05, 2020 @04:32AM
(#22492183)
Have you considered the Google App Engine on GCP in standard mode? That seems like a good fit based on your explanation but I could be wrong.
Re:Google Kubernetes Engine is introducing a cluster managem...
by jiggawatts on Thursday March 05, 2020 @06:52PM
(#22499725)
I had a similar conversation with a government customer, saying that they should pool their web applications into a single shared Azure Web App Service Plan, because then instead of a bunch of small "basic" plans they could get a "premium" plan and save money.
They rejected it because it's "too complex to do internal chargebacks" in a shared cluster model.
This is what I mean: The cloud is for orgs with one main application, like Netflix. It's not ready for enterprises where the biggest concern is internal bureaucracy.
Meanwhile most of my large government customers have a couple of tiny VMs for every website. That's it. That's already massive overkill because they see 10% max load, so they're wasting money on the rest of the resources that are there only for redundancy. Taking things to the next level would be almost absurd, but turning things off unnecessarily is still an outage.
This is why I don't believe any of the Cloud providers are ready for enterprise customers. None of you get it.