Anti-patterns in iPaaS

Here are a couple of anti-patterns which have surfaces recently in my interactions supporting customers of Azure Logic Apps:

1.  IP white-listing
   1. With on-premises integration solution, it used to be that the elements of the integration system were residing on specific static servers, such as their IP(s) as client of other services were static and well-known. Thus for the other services it was possible to add a layer of security by white-listing only these well-known client IP addresses.
   2. With iPaaS multi-tenant offering, the hosting service dynamically scales with the demand, spreading the load of all users on virtual machines which are allocated and de-allocated on-demand. The IP addresses of these VMs are thus changing overtime. You can no longer do white-listing of just a single or a handful of well-known client IP addresses. You may do a white-listing of the IP addresses of the entire Azure region, although its benefit is less clear as for a bad actor to get one such client IP address they would only need to create a resource in the given region.
2.  Calling services from within custom code of transform
   1.  With on-premises integration solution, a common sloppy pattern was to get reference data just-in-time as part of a XML transform operation, using custom code assembly reference within the XSLT to make the client call to the reference data service (say a SQL database). It wasn't pretty but just worked.
   2. With iPaaS multi-tenant offering, we have offered support for running custom code within transform (which address a number of scenarios including non-trivial transformation logic for the fields value). However when you use that to make calls over the network you start interfering with the resources of the dynamically allocated security container (sandbox) for your custom code. These sandbox are allocated with limited resources, sufficient to run transform and custom compute code. However reaching out over the network will risk to exhaust limited networking resources of the sandbox, and, authentication of the client calls becomes challenging as the code is run in low-privileged process which doesn't have access to secrets to authenticate itself.
   3. The recommended pattern for iPaaS (also applicable for on-premises) is to retrieve the reference data prior to the transform call, in a dedicated action (such as using the SQL connector 'Get Row'), then pass the complete input parameters to the transform action such that no external dependency remains during the transform execution. This further opens the opportunity of caching said reference data such that the load on the reference service is reduced.