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.

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.

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.

Let me ask you a question:

How do I abstract this unique idea of IOPS that AWS has?

You try, fail, and end up with a leaky, useless abstraction.