For a lot of services like this I think the value prop is not monetary cost but more "this is no longer your responsibility". Since you already have a custom-built solution that is stable & operating efficiently, switching doesn't sound worth it to you. For a team that's looking to add webhook functionality for the first time, not needing to go through the implementation work themselves or need to deal with any maintenance longer-term could sound very appealing. I think it's akin to the rise of interest in user-management-as-a-service products, etc.
I'm not, to be clear, expressing an opinion that the business will be successful with that strategy or that I think it's a good trend. On the contrary, this overall trend of feature-x-as-a-service products depresses me a bit. We've gone from the old days when you had to write pretty much everything yourself (which sucked), to the days when there were a ton of feature-x-as-library choices (which was way better but led to complaints of web programming becoming a chore of just bolting libraries together), to the current trend of feature-x-as-service products.
It's a logical evolution in some ways - similar to libraries over roll-your-own, it reduces your own set of responsibilities. But it also reduces your ability to learn (e.g. from reading source) or grow beyond the provided service (much harder to swap out providers or roll-your-own when the current solution is a third party black box). It also feels depressing in that we've gone from a thriving ecosystem of software based on open source to a much more capitalism-first ecosystem of "this could be a library but then how would I make money off of it". (I realize open source funding & maintainer compensation/sanity is its own set of problems. I just wish we could work on those issues without turning everything into a product.)
Yes, but there is no worth about any compliance regarding data protection that includes the webhooks. Also company is based in the US so that causes Privacy Shield issues.
Not easy to use this service when you need follow all kinds of regulation and the GDPR
Do you find that unnecessarily adds latency for webhook event ingestion from the US? Seems like that would add a point of failure that makes me even more nervous here -- instead of a quick request to us-east-2, I have to send data across the pond.
Yeah, this is less than optimal, and that's why we are working on adding zones. It just made sense to start with Europe while we are in just one (due to compliance). We also plan on having our API endpoints on many different zones so that for our customers API calls are immediate.
That's what I was thinking. Having ingress/egress processes in specific zones will definitely help here, while keeping your datastores in EU without any issues of data loss at the edge.
For example, ingress for receiving events in a US zone, those are asynchronously pushed to the EU datastore, and then egress for delivering the events are again in the US zone, transparently pulling data from the EU.
Not sure on your architecture, but just spit balling how you could keep data stored in the EU while temporarily "processing" that data in the US to keep latency low where it matters.
We are going to prioritize this task based on your feedback. It's definitely a concern. We don't even need to store the data in the EU if our users don't want/need it. We can even let them choose zones themselves for ingress - as in many (most?) cases, they would only be using one zone themselves.
Doesn't matter the terms suggest the company is based in Delaware:
This agreement will be governed by the laws of the Delaware, USA. The courts of Delaware have exclusive jurisdiction to settle any dispute arising out of or in connection with this agreement
IANAL, though this is for disputes. Not for compliance with international laws which we can do anyway. The question is: can a US company with servers solely in Europe can comply with the European legislations. Based on my understanding the answer is yes, though I'll double check with the experts. :)
I'm not, to be clear, expressing an opinion that the business will be successful with that strategy or that I think it's a good trend. On the contrary, this overall trend of feature-x-as-a-service products depresses me a bit. We've gone from the old days when you had to write pretty much everything yourself (which sucked), to the days when there were a ton of feature-x-as-library choices (which was way better but led to complaints of web programming becoming a chore of just bolting libraries together), to the current trend of feature-x-as-service products.
It's a logical evolution in some ways - similar to libraries over roll-your-own, it reduces your own set of responsibilities. But it also reduces your ability to learn (e.g. from reading source) or grow beyond the provided service (much harder to swap out providers or roll-your-own when the current solution is a third party black box). It also feels depressing in that we've gone from a thriving ecosystem of software based on open source to a much more capitalism-first ecosystem of "this could be a library but then how would I make money off of it". (I realize open source funding & maintainer compensation/sanity is its own set of problems. I just wish we could work on those issues without turning everything into a product.)