4 ms·

Thats why you wrap them in api or rather your architect should. You can and abolutely should abstract yourself from cloud provider. Difference with Docker is th

Thats why you wrap them in api or rather your architect should. You can and abolutely should abstract yourself from cloud provider. Difference with Docker is that in case of such a move (already did that in my career) the amount of boilerplate you have to review and adjust is magnitudes lower than what he (OP) proposed in his article.

philliphaydon 8y ago
So you write an abstraction around the provider, and when you switch provider, you still need to implement a new implementation of that abstraction for the new provider. So in this regard, docker gave absolutely 0 benefit. In regards to setting up a new server for a new provider, or docker, you have some boiler plate: -> create script to attach docker to provider New provider... -> create new script to attach docker to provider ---- -> create script to provision server on provider -> run generic script to configure it how I want New provider -> create new script to provision server on provider -> run generic script to configure it how I want In this regard, moving from 1 provider to another, is identical.
EpicEng 8y ago
And this is exactly how you end up with an overbuilt system which is difficult to comprehend because some "architect" decided you need to be able to change cloud providers on a whim. You pay for that decision every day and 99.9% of you are _never_ going to switch providers. Web development is full of engineering astronauts who think they need 8 levels of abstraction to solve relatively simple problems. Oh, and for that 0.1% that does actually switch, they soon realize they're abstractions weren't as good as they thought they were and they have to reimplement every interface anyway.
notyourday 8y ago
Let me ask you a question: How do I abstract this unique idea of IOPS that AWS has?
- EpicEng 8y ago
  You try, fail, and end up with a leaky, useless abstraction.

philliphaydon 8y ago

So you write an abstraction around the provider, and when you switch provider, you still need to implement a new implementation of that abstraction for the new provider. So in this regard, docker gave absolutely 0 benefit. In regards to setting up a new server for a new provider, or docker, you have some boiler plate: -> create script to attach docker to provider New provider... -> create new script to attach docker to provider ---- -> create script to provision server on provider -> run generic script to configure it how I want New provider -> create new script to provision server on provider -> run generic script to configure it how I want In this regard, moving from 1 provider to another, is identical.

EpicEng 8y ago

And this is exactly how you end up with an overbuilt system which is difficult to comprehend because some "architect" decided you need to be able to change cloud providers on a whim. You pay for that decision every day and 99.9% of you are _never_ going to switch providers. Web development is full of engineering astronauts who think they need 8 levels of abstraction to solve relatively simple problems. Oh, and for that 0.1% that does actually switch, they soon realize they're abstractions weren't as good as they thought they were and they have to reimplement every interface anyway.

notyourday 8y ago

Let me ask you a question: How do I abstract this unique idea of IOPS that AWS has?

EpicEng 8y ago
You try, fail, and end up with a leaky, useless abstraction.