> Hydrate data lakes The power of metaphor right there. Although I've never seen that phrase before, I know exactly what it means.
Does "hydrate" add some nuance here that "fill" doesn't? If so, I'm missing it.
Amazon AppFlow
81–90 of 112 posts
Re: Amazon AppFlow
#82I 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…
The reply?
Why? We just want to pick one and stick with.
Customers want the vendor lockin. They even embrace it.
Re: Amazon AppFlow
#83Earlier quoted context omitted.
Jira is good for tasking, but has a clunky UI and is riddled with bugs. I mean horrible because Atlassian made it.
Of their products, Jira does surprisingly well for us. I dislike quite a few of their products but Jira just works for us, though some things seem to be more work than necessary to do. Some of that can be blamed on company processes though.
Re: Amazon AppFlow
#84The 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.
What are some good Jira alternatives? We use Trello, but it's limited and plugins are needed for everything.
Re: Amazon AppFlow
#85I 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…
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.
Re: Amazon AppFlow
#86I 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…
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.
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.
Re: Amazon AppFlow
#87This seems like a Zapier killer, makes sense.
"Killer" - No. 90% of the market for Zapier is people who have no technical knowledge. Those people won't be jumping on AWS any time soon. Obviously pulling the 90% out of my ass, but I'm heavy Zapier user for my e-commerce business. I have (Or had - Haven't renewed as e-com has replaced my DevOps income) multiple AWS certs and I'd still much prefer Zapier over this. Especially when you can run custom code on Zapier…
Re: Amazon AppFlow
#88We 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 t…
Re: Amazon AppFlow
#89I 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…
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.
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.
Re: Amazon AppFlow
#90Earlier 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.
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.