Why do you think it’s technical debt? Because you might have to pivot away because it might not support your requirements in the future? Then just pay that cost in the future if it ever comes. Building everything in-house seems like premature optimization—you’re obsessing over a case that may never come, and you’re very likely not going to build these web service components as well as amazon for the cost because Amazon has many customers paying for these services such that each customer pays only a tiny fraction of the operating cost—if you roll your own, you have to pay the whole cost (roughly) for every web service you build and no one is paying your company to build web services, so you have to build that cost into the price of your product/service, so your product/service becomes dramatically more expensive (because it has to cover the cost to develop and maintain many full web service component implementations, which are each many times more expensive than the corresponding AWS service). If in the future AWS starts charging each customer the full operating cost for a given web service (which is very unlikely to happen given their business model) then you can spend time pivoting to your own solution, content in the knowledge that you saved many years of operating costs because you didn’t have to maintain your own service.
I am not sure why you (and every other person that replied) assumes that I am suggesting an in-house solution when I explicitly wrote "freedom to choose between vendors".
> Because you might have to pivot away because it might not support your requirements in the future? Then just pay that cost in the future if it ever comes.
That's pretty much the textbook definition of debt.
> I am not sure why you (and every other person that replied) assumes that I am suggesting an in-house solution when I explicitly wrote "freedom to choose between vendors".
I used "build in house" as a simple example of a broader principle--if there is a "freedom to choose" option that magically lets you migrate from one platform to another at zero cost while imposing no overhead over the AWS solution, then absolutely you should do it. But generally these solutions require a significant up front investment and rarely actually deliver on their promise of abstracting away the underlying platform (now you're wed to $ABSTRACTION on AWS, for example), but that's another story.
> That's pretty much the textbook definition of debt.
Nonsense. That's not debt, it's deciding to wait to pay for something in cash until you know you want to buy it. It's not debt to wait to spend $30K (cash) on a car until you're sure you want to buy it. The "tech debt" analogy is intended to convey interest--you know you want to change course but you do the expedient thing now knowing that you're going to continually bump into it (each bump is "interest") until you can pay it off properly. This is the opposite--if you build it in house or use a dodgy "platform-agnostic" abstraction, you're going to be paying interest on something you will very likely never even need!
