Vendor lock-in is just another form of technical debt and should be treated as such.

Sure right now it's your easiest option, but in the future the vendor might be the only one offering a compatible version of CoolNewFeatureXY at prices that make your business uncompetitive to the other businesses that have the freedom to choose between vendors.

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!

If I'm not mistaken, New Jersey is trying to pay that cost just now.

To be honest this looks at code as an asset versus a liability. Most code especially glue code is a liability since you need to maintain it and take care of it versus letting a third party vendor like Amazon be responsible for maintenance. In the end a business is trying to build assets and glue code to push, to say Salesforce, may not be a competitive advantage.

The vast majority of successful tech companies definitely treat their code as assets.

I think you’re confusing 2 things. The technical and developmental side, where code is a liability that needs to be maintained, and the business/usage side, where code is definitely an asset that provides your company with additional leverage against competitors.

Most code doesn’t give you leverage against competitors. Building in-house for 100X the cost (or at 1% quality) of using an AWS component confers a competitive disadvantage unless you have lots of customers who pay a lot to do business with someone “not on amazon” but even then you probably shouldn’t be building it yourself. This is generally implied when people say “code is a liability”.

I'd say that having a (buggy) in house integration with Salesforce is a way bigger tech debt than using AppFlow here.

If one day you want to move off Salesforce to another service, you will just switch off the configuration in AppFlow for the new service. Sure you're locked in AWS, but it takes tech debt away from other things, plus might save you migration costs.

> I'd say that having a (buggy) in house integration with Salesforce is a way bigger tech debt than using AppFlow here.

That assumes that the AppFlow code is not buggy. In my experience these services are very hit and miss. This might be a good one, but it's impossible to tell until you use it (or read experience reports of others using it). Reliable 3rd party services can be a big time saver, but Unreliable/Buggy/Limited 3rd party services can easily take 5x more time than something in-house.

I'd gander that an AWS team would be more capable than your average startup team. And testing if AppFlow works for you will take way less than building your own.

I'd say that:

* About 70-80% of what you want to do with a service like appflow to integrate with a service like salesforce will be possible. The other 20-30% of your requirements will require building a bugging in house integration from the ground up. Might as well start off that way.

* As soon as you hit a wall with a service like appflow that is usually it. You'll raise a ticket and be stuck until they get around to implementing it. There are fewer roadblocks with home grown implementations of integrations.

Not saying it will work for all cases, but a majority of integrations are pretty basic. I have done a few. Usually just data mangling between different systems, which is exact what AppFlow is good for. Also if you are on a business plan, the response time is pretty good. I got feature requests done in Sagemaker.

Nothing is stopping you from rolling your own, or...developing some multicloud solution.

It's a good point - and part of the reason I'm asking this is I don't know the answer 100%. Some of it is gut feeling. I guess part of the problem is that by outsourcing this layer of work you actually fail to develop internal competency to do it yourself. Then when later on you find your requirements expand beyond what can be done, you're now functionally incapable of doing it, and you start being constrained by that. I've been in companies that end up paying ridiculous amounts for consultants to do utterly trivial things to systems just because they've been bred to be functionally dependent on systems they don't understand / can't control. That isn't this, but I feel like it's a step towards it.

Vendor lock in is very expensive. At the moment vendor lock in is providing AWS with more profit margin than Amazon's entire retail division. It's more profitable than McDonalds.

It's also A) frequently not all that hard to avoid B) worth doing for reasons other than sheer cost (e.g. flexibility, ability to unblock oneself more easily, ability do deal with bugs by oneself).

If you work in a company that isn't especially worried about hosting costs it's fine (mine isn't, for instance), but most companies are at least somewhat concerned with these costs.

I agree that vendor lock-in is expensive. It's not as expensive as the investment companies make in keeping their tech cloud-agnostic, investments that never seem to pay off. Either the day never comes, or when it does, switching costs are still surprisingly high.