Live data from Hacker News

Amazon AppFlow

aws.amazon.com

71–80 of 112 posts

Re: Amazon AppFlow

#71

Related, I've been trying to figure out what the best way to populate a Redshift database from regularly updated SFTP sources is and I can't quite figure it out. AWS Glue? A function in Lambda? This? AWS presents so many options that it's a bit overwhelming.

We, Fivetran, have an SFTP connector. You can be sync'ing data with 10 minutes of effort. Our value is in (nearly) zero configuration, automatic schema migration, and automatic failure recovery. We take the pain out of Extract-Load, and push Transformation into the warehouse. https://fivetran.com/docs/files/sftp

Re: Amazon AppFlow

#72
post #66

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.

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

Re: Amazon AppFlow

#73
We are trying to provide a service based on CRM (Salesforce) data to our customers in China. Salesforce doesn't exist (yet...) in CN, and wondering if something like this could be useful in moving needed data to AWS China. Then I realized that Redshift is not your typical OLTP db and not suitable for regular querying from an application. Curious to hear HNs thoughts.

EDIT: Someone mentioned Heroku Connect in one of the comments. We do use this to archive certain objects (> 75 million records) and I have thought about replicating this data to AWS China (Postgres). Could be one option but some of our data is real time (e.g. customer orders), not sure what the "freshness" of the data would be.

Re: Amazon AppFlow

#74
post #66

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.

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.

Re: Amazon AppFlow

#75
post #25

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.

This is a far cry from the 347 available in Power Automate. Still interesting to see.

wonder if they might create a market for it, like they have with Sagemaker

Re: Amazon AppFlow

#76
post #66

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.

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.

Re: Amazon AppFlow

#77
post #55

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…

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…

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.

Re: Amazon AppFlow

#78
post #55

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…

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

Re: Amazon AppFlow

#79

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 some work done.

Re: Amazon AppFlow

#80
Also known as BPEL, Business Process Execution Language and BizTalk.

Love how these things keep getting re-invented.

Post reply on HN