Also, user "nslog" only posts Amazon stuff and never comments.
The cost calculus doesn't usually switch until you've pretty far along on solving those things.
I would argue that real infrastructure or vendor "lock in" is due to the friction of learning the API's associated with each cloud platform. Obviously, one can choose to use all the services of the cloud platform they will deploy to. However, and in most cases, that is not a strict requirement to use the cloud platform to begin with. "Lock in" seems more like a self-created problem than anything.
And it's not just cloud platforms. Every tool you use becomes more engrained the more you use it.
Put plainly: It seems silly to me how people will shout "vendor lock-in" when using a service like DynamoDB or Kinesis, but will be more than happy to learn how to set up and maintain a Cassandra or Kafka cluster, along with Zookeeper, Puppet/Chef, and all that goes along with it. Those are not insignificant costs!
I get that those aren't vendor-specific, but at some point you're just doing a lot more work, maintenance, and tying yourself down to a stack (and whatever employees became experts in them), and for what benefit? So you'll theoretically be able to move away faster if AWS goes rogue, long after your startup gains traction?
I think those reflexively dismissing cloud services due to vendor lock-in need to take a step back and look at the big picture.
Costs are high for aws. You might be able to pay a little more now but when you need to scale you may find you are priced off of aws.
More importantly, though: you quite possibly won't ever find yourself "priced off of aws." Netflix isn't. Workday isn't. Spotify isn't. Pinterest isn't. Dropbox only transitioned off very recently (reportedly for more control). Some of the biggest players on the web were able to scale and grow beyond most of our wildest dreams without it holding them back, yet still some recommend adding significant man-hours and complexity up-front just on the off-chance it becomes necessary after it's successful?
Let's be realistic here.
Yeah, their server software itself sucks a bit (low tick-rate, odd "de-sync"), but scaling itself has not been any issue: it feels the same now as it did with a tenth or a hundredth of the players it has right now.
Compare that to the growing pains that, for example, league of legends had, where even several years in the whole of EUW would be practically down on weekends. (log in "queue" over 9000)
If you have some product-market fit, vendor lock-in probably doesn't matter.
If your business is growing quickly and you have the ability to raise a strong Series A investment (if you wanted to), then vendor relationships are worth thinking about and engineering for the long term.
Giants like Amazon, Facebook, and Google don't want to "control your stuff before you even make it" because most things that people make aren't worth their time. Once your business is growing steadily, however, this might change.
But otherwise I agree, vendor lock in seems out of control.
Hiring will be a pain, especially if you are competing with giants or millions of dollar valuation startups. One less person you have to hire is eons you can spend on other things.
Sales/Marketing would suck, you would spend more on getting the deal then you will make from that in 2 years. Your first 10 ideas to make the app viral will fail. Your dev time not going in ops. can be used to squeeze in that feature, the big fat wallet is asking for.
Don't worry about vendor lockin, React patents, green earth. 90% chance you'll die before you hit that, make that 99% if you are worrying about that. You'll anyway rewrite/rearch. the thing you are writing, as your understanding of market will improve.
The only goal that matters for an early stage startup is product/market fit. If you can demonstrate traction you can raise money to buy yourself more time.
For this, rapid iteration is critical. Use whatever tools help; vendor lock-in is something you solve when you have 20mm+ in the bank.