Re:Google Kubernetes Engine's third consecutive day of servi...
by geggam on Monday November 12, 2018 @07:40AM
(#18432242)
Quit using vendor lock in resources then asking why its hard to leave that vendor.
Re:Google Kubernetes Engine's third consecutive day of servi...
by scarface74 on Monday November 12, 2018 @10:22AM
(#18433097)
You’re always “locked in” to your infrastructure. People have this brilliant strategy of thinking they have this brilliant strategy of avoiding “lock in” and again they get the worse of both worlds. They end up spending more to avoid lock-in and they aren’t taking advantage of what thier provider has to offer.
At the end of the day, changing your underlying infrastructure is so risky and usually not worth the cost benefit analysis, it’s rarely done.
Re:Google Kubernetes Engine's third consecutive day of servi...
by scarejunba on Monday November 12, 2018 @02:15PM
(#18434846)
Oh, I see. You intend to use purely EC2 or GCE instances and just run everything one would run in a colo on them. All right.
That's a pretty manpower intensive way of operating. I think the fact that you get cloud agnostic this way is probably not worth it.
Re:Google Kubernetes Engine's third consecutive day of servi...
by geggam on Tuesday November 13, 2018 @11:59AM
(#18442511)
The requirement was to be cloud agnostic. This is one of the few ways possible.
Re:Google Kubernetes Engine's third consecutive day of servi...
by scarface74 on Tuesday November 13, 2018 @07:42PM
(#18446315)
In that case, why be in the cloud at all? I still think it would be cheaper to have a colo in two geographically dispersed areas on bare metal.
The syntax for provisioning these doesn’t work that well for some find and replace to work. Are you using a templater to generate cloud-specific HCL from a template or something? Sounds like a pretty big problem to solve to me and not just something where you can win via discipline.