One of the other commenters already pointed out services like Docker are letting us abstract away from the specifics and just run the software wherever there&#x27;s an OS that&#x27;ll take it. That reduces the hold any one provider can have and forces them to compete on price &#x2F; features rather than technology lock-in. If one of them implements a requirement you must use their standard APIs for XYZ, then you&#x27;re probably going to get a mass exodus.<p>Longer term, I think Amazon&#x27;s cloud will continue to eat market share, especially as an entirely new generation of techies comes online whose only experience has been working with AWS and other cloud providers. Kind of like the transition from desktop software in the 80s&#x2F;90s to server-based web apps in the 90s-early 00s. If you&#x27;re building a company &#x2F; app today, the first move is to go to the cloud and get on AWS. That&#x27;s the &quot;safe&quot; business move now rather than spending capital to buy hardware, getting a sysadmin, etc. etc. etc.<p>For the market, I&#x27;m hoping we see someone develop a set of common APIs that abstract away common specifics across AWS&#x2F;Google Cloud&#x2F;Azure and let you run a generic web stack and dynamically move parts of your app around based on pricing. If Google drops below AWS and your demand is spiking, you setup new instances on Google, rather than spinning up AWS instances, and use a micro service API to interact with the database. Behind the scenes, the API layer tracks the different clouds you configured for and dynamically moves most pieces of your application except data storage as your target conditions change. I envision spot cost, demand, latency, and host availability &#x2F; provisioning time all playing a role in this cost algorithm. Eventually you end up with agnostic applications that don&#x27;t ever live anywhere. They migrate and dynamically adjust across different clouds turning each individual cloud in part of a larger, more agnostic cloud for some services.