Have Polygamous Cloud Relationships
As cloud providers evolve, offering an increasing number of specialized services, its best to not become too intertwined, lest the day comes when you divorce them for something better elsewhere. Particularly for startups, where needs are also evolving, its better to stay agile, with an infrastructure that uses common, not vendor-specific, components. This way if you change to a new provider you can minimize the cost, time, and risk of downtime.
At NUKU we recently made the move to Digital Ocean from AWS, where we had hosted our services for the last six years. AWS has been great–downtime has been minimal, and using interfacing tools with it have been easy since pretty much every service has a defacto connection or instructions on how to connect to Amazon.
Have a policy to not use specialized services when you can roll your own
But we always kept in mind of the day that we might part ways. With it evident that new cloud providers and technologies would arise, we have had a policy to not utilize any of the specialized services (Amazon has many) that were unique to Amazon, if we could avoid it by rolling our own. Importantly, we wouldn't sacrifice our offering by blindly following this policy, but rather we would consider the cost to writeup our own service that could be used anywhere. The core services we used at AWS were EC2, RDS, S3, Route53. We also used their VPC (Virtual Private Cloud).
We decided to switch to Digital Ocean in 2015, due to the cost-effective speed of its servers and simplicity of its design. Since with our design we only core-services (the ones we used with Amazon), Digital Ocean was an easy move. The only service that required us to create our own were in-house databases since Digital Ocean does not offer a RDS-like service.
Since our systems are all micro-services, extricating ourself was simple, since we could move each service individually, with no impact on our system overall as each service simply had their API calls rerouted as our DNS was changed.
Our migration from AWS to Digital Ocean took less than 30 days
The next result of planning ahead and staying polygamous: our whole migration occured in under 30 days, it involved very little programming since each of our services pretty much stand alone, and as a result the cost was minimized and will easily be made up in the cost savings we will pick up at Digital Ocean. Our policy still stands, so we'll see if Digital Ocean keeps offering what we need or someone else comes along with something better.
Carson R Cole