Kind of interesting offer when you think what kind of implications it has related to this:
https://www.wsj.com/articles/amazon-scooped-up-data-from-its...
Amazon AppFlow
91–100 of 112 posts
Re: Amazon AppFlow
#92Earlier quoted context omitted.
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.
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:
* 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.
Re: Amazon AppFlow
#93I 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…
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…
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.
Re: Amazon AppFlow
#94Earlier quoted context omitted.
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.
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.
Re: Amazon AppFlow
#95Earlier quoted context omitted.
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…
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 especia…
> Vendor lock in is very expensive.
Multi-cloud is complicated and not cheap.
Re: Amazon AppFlow
#96Really curious how well the salesforce integration works. Heroku has a product that does this (Heroku Connect), but it doesn't work well with large tables and you have to pay them an obscene amount of money to even properly test it (which might have something to do with them being owned by Salesforce). So many companies with tons of data trapped in Salesforce's expensive walled garden and no way to get it out. Dumpin…
We use Heroku connect to sync a few hundred thousand rows and it works really well for us and has been way more reliable and quicker than the Salesforce API. Heroku connect let’s you sync data from Salesforce tables which are the source of truth. There’s also another product (which you pay for separately) called Salesforce connect which lets you sync data from a Heroku database as the source of truth.
Re: Amazon AppFlow
#97I 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…
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.
Re: Amazon AppFlow
#98This seems like a Zapier killer, makes sense.
Interesting that Amazon seems to rarely acquire competitors. Instead they (slowly) begin to meet their use cases one by one.
It seems that Amazon have quite strong internal standards for services that they're going to roll out, for example all critical services are required to use DynamoDB, which would make it difficult to integrate a competitor into their wider ecosystem of AWS services. They've also got a vast pool of people to draw from around the company which allows them to implement new functionality on top of existing tools they've already built, rather than having to do everything from the ground up.
Re: Amazon AppFlow
#99> Hydrate data lakes The power of metaphor right there. Although I've never seen that phrase before, I know exactly what it means.
I found it very clever. This product does not replace your data lake, it flows into your data lake.
Re: Amazon AppFlow
#100Earlier quoted context omitted.
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…
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 especia…
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.