Hacker News Reader

Comment by zmmmmm | Hacker News Reader

I really wonder about all these services that eat into the layers of implementation that organisations usually do in house, but at the same time quick form a complex web of lock in that prevents you ever leaving Amazon. It seems to me that these services are very seductive but there are very few cases where it's truly in an organisation's long term interest to adopt them. At best, use them as a quick interim solution to bootstrap what you are building and then use that as your requirements for an open source or at least vendor-neutral equivalent.

Curious what the HN crowd thinks about this issue?

View on HN

Why do you worry about vendor lock-in?

If you get to a point where you are locked-in it's because you spent years building into a solution that was your most expedient and renumerative option. At some future point in time, a future you or the person who replaces you may want to reconsider a re-platform. Let them worry about that.

I worry about development working on glue code/solve problems to the detriment of their businesses actual needs.

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.

> Vendor lock in is very expensive.

Multi-cloud is complicated and not cheap.

The old "vendor lock-in" debate.

Vendor lock in is essentially that it’s more effort than you’re able to afford, in terms of time and cost.

There's always a tradeoff, but being all in on a vendor isn't necessarily a bad thing. Embracing a platform and the services they have to offer is how you get the most out it.

Whenever you pick a technology or service, you need to employ an ongoing effort rather than waiting until it's too late to do a one-time effort.

This is true with any choice of technology, whether your rolling your own or using SaSS, an on-going effort is required to avoid being locked in.

use that as your requirements for an open source or at least vendor-neutral equivalent

My clients are all expending far too much energy trying to be cloud vendor neutral with the engineering capacity of your average non-tech large mid-market company. It's killing productivity. They went from VMWare in the data center and open source DevOps tooling to multi-cloud vendor-agnostic container-orchestration all in the name of "cloud but not with vendor-lock in". Meanwhile they could be actually achieving business objectives with these "seductive" managed services.

Here's one simple example, one client is spending about $250,000/yr on what could be accomplished with AWS Cognito for $250/month. But "no", they say, "then we'd be locked in to AWS".

I just can't.

In my opinion the answer is "write the code so that it can easily adapt to change":

- keep the business logic away from your implementation details

- generally speaking practice clean code

- don't overthink it, if your business goal is solved easily and quickly by using the cloud, use it, otherwise you lose time to market

In a company with huge numbers of developers I'd agree with you, it's better to have something you control than a vendor specific thing that's likely to cause problems. For a smaller company with limited availability and a long backlog of features to implement that's not the choice being made though, the choice being made is "do we implement this feature or not", and a tool like AppFlow lowers the cost of development on certain features, likely resulting in at least some things that wouldn't have happened because they'd require a larger investment of time than people were willing to put in.

First, make money and fast. If you have customer, money and growth, you can hire right people to redesign your software.

I told my customers to think about multi cloud and plan accordingly for it.

The reply?

Why? We just want to pick one and stick with.

Customers want the vendor lockin. They even embrace it.

If you're large enough and can negotiate appropriate contracts, it's not problem to be locked in with one vendor. Then you typically also get prices way below what's typically quoted and in line with home built.

A huge problem however for smaller companies that have little power if the vendor raises prices, discontinues products or throws them off the platform. Going all in with AWS as a small company is not only expensive but can be a risky bet.

No, they don’t want lock-in, they want the simplicity of dealing with a single vendor. It’s an important difference.

You can choose to work with a single vendor but switching to a new one should be trivial in case the prices get jacked. It’s that simple.

Reply on news.ycombinator.com