Pubsub+ with serverless cloud components (esp azure) in the data flow: which tech? How?
We are using pubsub+ in an event-carried-state-transfer pattern to integrate data between a number of enterprise applications. As of right now, the publishers can make use of a nuget package authored by me to simplify connectivity, which they can incorporate into their application if it can raise events natively. For applications which cannot, we generate events from the database level with a technology like SQL Server change data capture or SQL Server change tracking, with a windows service acting as the bridge between the polling of the database and the connection to pubsub+.
Similarly, on the subscriber side there is typically a windows service which is acting as the "listener" for the events, acting as the subscriber and receiver of messages which are ultimately pushed to some kind of repository on the subscriber side.
Keeping these components outside the native application code seems to make sense for a lot of reasons: the native application might be a vendor system whose code we cannot change, or it might be something like a typical web application with only a standard, slow, http "api" designed purely for the application UI to consume.
For these reasons, in my existing integration data flows these bridge components are implemented as windows services. It seems like a natural fit for something which runs constantly and is kept alive by the operating system. But as more applications move entirely into azure, and particularly as the company pushes development towards serverless components, the choice of bridging technology is less clear.
I am interested in hearing from people who are using pubsub+ in combination with serverless cloud components, especially azure. Which cloud product did you or would you choose to host this kind of bridging code? Azure functions seem like a poor choice if the idea would be to spin up an execution on the arrival of every event if there is a requirement to preserve event order, and also because it seems likely to end up being very expensive.