Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Amazon AppFlow

aws.amazon.com

Post reply on HN
Print view View original

101–110 of 112 posts

Re: Amazon AppFlow

#101

Post by throwaway894345 »

hobofan wrote: post #66
dataminded wrote: post #62

Earlier 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 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.

Re: Amazon AppFlow

#102

Post by tigroferoce »

theshrike79 wrote: post #79
degenerate wrote: post #8

The full list of SaaS integrations: https://aws.amazon.com/appflow/integrations/ Amplitude, DataDog, Dynatrace, Google Analytics, Infor Nexus, Marketo, Salesforce, ServiceNow, Singular, Slack, Snowflake, Trend Micro, Veeva, Zendesk. I feel like a notably missing product from this list is Jira. As horrible as it is, lots of companies use Jira for tasking so it should have been supported out the gate.

Jira is like Agile, it needs to be modified to the company and WAY too easy to do wrong. At its core Jira is just a tool you use to track who's working on what issue, maybe link it to your version control to see what commits have been done. BUT, then the Suits come in and start adding timesheets and reporting and 42 different categories for everything and it becomes a hellscape of forms you need to fill just to get s…

I agree 100%. I once integrated Jira in a product and it was a nightmare. Integrating is pretty straightforward, but then Jira has its own way of naming the custom fields that the user added, so you end up in making a ton of API calls to discover what are the custom fields, their name, which are mandatory, what is the data format, and so on.

And don't get me started with creating a GUI so that the user can insert the data for a set of fields you don't know in advance.

Re: Amazon AppFlow

#103

Post by throwaway894345 »

thawaway1837 wrote: post #94
abhiyerra wrote: post #76

Earlier quoted context omitted.

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”.

Re: Amazon AppFlow

#104

Post by rkangel »

theshrike79 wrote: post #79
degenerate wrote: post #8

The full list of SaaS integrations: https://aws.amazon.com/appflow/integrations/ Amplitude, DataDog, Dynatrace, Google Analytics, Infor Nexus, Marketo, Salesforce, ServiceNow, Singular, Slack, Snowflake, Trend Micro, Veeva, Zendesk. I feel like a notably missing product from this list is Jira. As horrible as it is, lots of companies use Jira for tasking so it should have been supported out the gate.

Jira is like Agile, it needs to be modified to the company and WAY too easy to do wrong. At its core Jira is just a tool you use to track who's working on what issue, maybe link it to your version control to see what commits have been done. BUT, then the Suits come in and start adding timesheets and reporting and 42 different categories for everything and it becomes a hellscape of forms you need to fill just to get s…

Jira is a classic example of a product oriented towards how companies buy things.

Every time a moderately expensive purchase is needed companies get together, write down a list of things that they need the product to do and then compare the options on the market. This process results in a 'winner' who checked the most checkboxes.

It's a process that doesn't take into account the subtler more analog things we should be rating products on - basically how 'nice' they are to use (in a corporate setting I would phrase that as how 'efficient' they are to use, but it's the same thing).

Re: Amazon AppFlow

#105

Post by hobofan »

throwaway894345 wrote: post #101
hobofan wrote: post #66

Earlier 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.

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 Amaz…

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.

Re: Amazon AppFlow

#106

Post by madmulita »

throwaway894345 wrote: post #101
hobofan wrote: post #66

Earlier 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.

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 Amaz…

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

Re: Amazon AppFlow

#107

Post by throwaway894345 »

hobofan wrote: post #105
throwaway894345 wrote: post #101

Earlier quoted context omitted.

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 Amaz…

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!

Re: Amazon AppFlow

#108

Post by aledalgrande »

nicoburns wrote: post #90
aledalgrande wrote: post #74

Earlier quoted context omitted.

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/Li…

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.

Re: Amazon AppFlow

#109

Post by aledalgrande »

pydry wrote: post #92
aledalgrande wrote: post #74

Earlier quoted context omitted.

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…

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.

Re: Amazon AppFlow

#110

Post by soumyadeb »

grwthckrmstr wrote: post #46

Noob here with a question - is this in any way a competitor product to Segment?

Founder of RudderStack here (we are an open-source Segment alternative)

Segment (or RudderStack) is primarily for routing event-data from your apps to multiple destinations (cloud SaaS, warehouse etc). On the other hand, AppFlow is for syncing data that lives on cloud applications with AWS products like RDS, RedShift etc. So, both the nature of data is very different (event-streams vs database update batches) and also the destinations where they are sent (multiple cloud applications + data-warehouse VS only datawarehouses/databases).

Segment also has a product similar to AppFlow called Segment Sources but that's not what Segment is known for. There are a bunch of other products in that space like Blendo & FiveTran.

Post reply on HN