It sounds like you have a preference for choosing portable interfaces when it comes to storage. And you've abstracted out the non-portable lambda interface.

My position isn't don't use AWS as a hosting provider, it's that you ought to avoid being locked into a proprietary non-portable interface when possible.

Not really. My company has plenty of business risks. Out of the those, a dependency on AWS is the least of them.

Vendor lock in isn't really a problem initially. It's something that creeps up on you over time.

Over time, we will have an “exit strategy” that makes it “someone else’s problem” and then we will be well enough capitalized to migrate if needed.

Or the Twitter model - very bad architecture that always crashed, find “product market fit” and then get funding to fix any issues.

Or the company goes out of business, I put X years of AWS experience on my resume and make out like a bandit as an overpriced consultant.

I don’t see the downside....

The downside could be going for a new round and not getting that valuation because projected costs prevent scaling.

I don't really see cloud-provider competition lessening or hardware getting more expensive and less efficient or the VMs getting worse at micro-slicing in the next 5 years. So why would I be worried about rising costs?

Speaking of micro slicing.....

https://aws.amazon.com/blogs/aws/firecracker-lightweight-vir...

I think spending one of the newly-raised millions over a year or so can help there, including hiring senior engineers talented enough to fix the shitty architecture that got you to product-market-fit. This isn’t an inherently bad thing, it just makes certain business strategies incompatible with certain engineering strategies. Luckily for startups, most intermediate engineers can get you to PMF if you keep them from employing too much abstraction.

Isn’t employing too many abstractions just what many here are advocating - putting a layer of abstraction over the SDKs abstractions of the API? I would much rather come into a code base that just uses Python + Boto3 (AWS’s Python SDK) than one that uses Python + “SQSManager”/“S3Manager” + Boto3.

That is indeed what many here are advocating. There are only so many possible interfaces or implementations, and usually abstracting over one or the other is an effort in reinventing the wheel, or the saw, or the water clock, and not doing the job as well as some standard parts glued together until quite far into the endeavor.

Stop scare-quoting "lock-in". Lock-in means development effort to get out of a system, regardless of how trivial you think it is.

If writing code to be able to move to a different cloud isn't considered lock-in, then nothing is since anyone can write code to do anything themselves.

Lock in is an economic concept, it’s not just about code but about “switching costs”. Ecosystem benefits, data gravity etc all come into play.

There are two kinds of lock-in: high cost because no competitor does as a good a job - this is good lock-in, and trying to avoid this just means you’re not building the thing optimally in the first place.

There is also high switching cost because of unique interface and implementation requirmenrs that don’t add any value over a more interopable standard. This is the kind that’s worth avoiding if you can.