Stay The Hell Away from Anything That's Not Cloud Portable

I want to talk about something that's going to sound a little debatable, but I don’t want others to make the same mistakes I did. 

There are multiple opinions on Hacker News on whether being cloud-portable is a complexity that’s worth taking on or not. 

For startups, choosing a cloud provider like AWS makes total sense early on. The abundance of services and scalability is extremely attractive. And the temptation to use AWS’ proprietary databases, queues, and load balancers is strong. They seem to perfectly solve problems and get you moving quickly. 

However, the moment you start building tight integrations with these niche, proprietary cloud services, you're putting your startup's future flexibility at serious risk.

Want to migrate? Sorry, but Dynamodb has no real equivalent on other clouds. Need multi-cloud for compliance? Too bad, we don’t have any alternative to SQS.

Early on, you may not realize how debilitating vendor lock-in can be for scaling, optimizing costs, expanding globally, or accommodating enterprise customer needs. It also puts you at a competitive disadvantage because you’re not able to use that new serverless offering that came to market.

I’m not here to say you need to sacrifice cloud-native functionalities. But when you do use them, use them with caution. 

What I mean by that is you need to have a "blue cloud" mentality - stick to using standard, open, and protocol-compliant resources as much as humanly possible. And when you do leverage proprietary capabilities for a key advantage, wrap them in clean abstractions so you can easily swap out implementations across clouds if needed.

For example, for databases, leverage standard database services like PostgreSQL or MySQL RDS rather than proprietary PaaS databases.

If you do use proprietary services for specific advantages, wrap them for portability. For example, if using AWS Lambda for serverless functions, build an abstraction layer around it using CDK or Serverless Framework. That way your functions could theoretically be ported to GCP Cloud Functions or Azure Functions with the wrapper handling the differences.

Even for higher-level services, consider portable alternatives. Instead of proprietary caching, use portable Redis. Instead of proprietary queues, use portable RabbitMQ or Apache Kafka. The options are endless.

The upfront engineering work to keep provider dependencies enclosed is much less costly than the massive asset/revenue risk and technical debt of getting stuck in a lock-in prison.

Cloud portability may seem like a daunting task when you're just trying to ship MVP features and grow. But I guarantee you'll be thankful for putting in those abstractions down the road when new opportunities and challenges arise. Keep your options open, prioritize portability early, and avoid my scars of proprietary regret.

Comment on Hackernews.