[cjsuk]

100% agree with you.

No one accounts for portability. The common mantra is that if portability becomes a problem you will be rolling in VC cash so you can just afford to restart everything from scratch and shrug it off. Basically defer the complicated decisions to later on.

That never accounts for the "grey phase" which a lot of products seem to slide into permanently which is where they are just about scraping by with no investment at all. At this point, the decisions affect your bottom line badly because scaling up customers means an instant cost and geopolitics can mean sudden revenue decreases.

You need to plan for a partial success and a partial success can't handle vendor lock in.

I'd argue, after spending the last 5 years working with AWS, that the learning curve for locking yourself into a vendor has a zero return as well. One product change and start again.

IaaS yes. Anything else, no thanks.

Edit: also some of the IaaS providers make standard services that compete with their own products difficult. Look at SES. If you run IaaS in AWS you have to jump through a lot of hoops to run an outbound mail relay. Their solution: just use SES; it's really easy! It's not!

[dankohn1]

The message of the cloud native software stack, most often built around Kubernetes, is that cloud portability enables you to avoid vendor lock-in.

A look at the stack: https://raw.githubusercontent.com/cncf/landscape/master/land...

(Disclosure: I'm the executive director of CNCF and helped make this image.)

[gaius]

Using cloud as a glorified hypervisor isn't really getting the benefits. To be cost effective you really do need to be using the value-added or layered features, and those are proprietary.

[dankohn1]

I disagree (obviously). There are huge advantages to using the data stores from your cloud provider, but you can pick Postgres or similar options that avoid lock-in. If you use DynamoDB or Spanner, you can work to avoid non-portable features. Many other services like SNS can be replicated with software like NATS.

That said, switching from one cloud to another will never be trivial, so it may be worth using some proprietary services up front if it gets you to market faster. The key thing is to have your eyes open about the choices you make, to ensure you have the ability to switch (or, perhaps more importantly, threaten to switch) in the future if you need to.

[gaius]

Sure, but if you restrict yourself to lowest-common-denominator features so you can migrate between Spanner and CosmosDB then you are paying for features you aren't using and are at a competitive disadvantage to those that can leverage them.

[tracker1]

Agreed, at the very least, anything I've made in the last year can be containerized and retargeted pretty easily from there.