They're great to embed logic and code in a medium-small, cloud-native application, but they can become quite limiting for complex, enterprise applications.
As I mentioned earlier SQL Server Integration Services is suitable if you want to manage data from different applications. It really helps in fetching the data and generating reports. Its automation make it very easy and time efficient. It works well with large database as well. But it doesn't work well with real time data, it will take some time to gather the real time data. I would not recommend using it in a real time/fast-paced environment.
They natively integrate with many triggers from other Azure services, like Blob Storage or Event Grid, which is super handy when creating cloud-native applications on Azure (data wrangling pipelines, business process automation, data ingestion for IoT, ...)
They natively support many common languages and frameworks, which makes them easily approachable by teams with a diverse background
They are cheap solutions for low-usage or "seasonal" applications that exhibits a recurring usage/non-usage pattern (batch processing, montly reports, ...)
My biggest complaint is that they promote a development model that tightly couples the infrastructure with the app logic. This can be fine in many scenarios, but it can take some time to build the right abstractions if you want to decouple you application from this deployment model. This is true at least using .NET functions.
In some points, they "leak" their abstraction and - from what I understood - they're actually based on the App Service/Web App "WebJob SDK" infrastructure. This makes sense, since they also share some legacy behavior from their ancestor.
For larger projects, their mixing of logic, code and infrastructure can become difficult to manage. In these situations, good App Services or brand new Container Apps could be a better fit.
Connection managers for online data sources can be tricky to configure.
Performance tuning is an art form and trialing different data flow task options can be cumbersome. SSIS can do a better job of providing performance data including historical for monitoring.
Mapping destination using OLE DB command is difficult as destination columns are unnamed.
Excel or flat file connections are limited by version and type.
Some features should be revised or improved, some tools (using it with Visual Studio) of the toolbox should be less schematic and somewhat more flexible. Using for example, the CSV data import is still very old-fashioned and if the data format changes it requires a bit of manual labor to accept the new data structure
SSIS is a great tool for most ETL needs. It has the 90% (or more) use cases covered and even in many of the use cases where it is not ideal SSIS can be extended via a .NET language to do the job well in a supportable way for almost any performance workload.
SQL Server Integration Services performance is dependent directly upon the resources provided to the system. In our environment, we allocated 6 nodes of 4 CPUs, 64GB each, running in parallel. Unfortunately, we had to ramp-up to such a robust environment to get the performance to where we needed it. Most of the reports are completed in a reasonable timeframe. However, in the case of slow running reports, it is often difficult if not impossible to cancel the report without killing the report instance or stopping the service.
The support, when necessary, is excellent. But beyond that, it is very rarely necessary because the user community is so large, vibrant and knowledgable, a simple Google query or forum question can answer almost everything you want to know. You can also get prewritten script tasks with a variety of functionality that saves a lot of time.
The implementation may be different in each case, it is important to properly analyze all the existing infrastructure to understand the kind of work needed, the type of software used and the compatibility between these, the features that you want to exploit, to understand what is possible and which ones require integration with third-party tools
This is the most straightforward and easy-to-implement server less solution. App Service is great, but it's designed for websites, and it cannot scale automatically as easily as Azure Functions. Container Apps is a robust and scalable choice, but they need much more planning, development and general work to implement. Container Instances are the same as Container Apps, but they are extremely more limited in termos of capacity. Kubernetes Service si the classic pod container on Azure, but it requires highly skilled professional, and there are not many scenario where it should be used, especially in smaller teams.
I think SQL Server Integration Services is better suited for on-premises data movement and ADF is more suited for the cloud. Though ADF has more connectors, SQL Server Integration Services is more robust and has better functionality just because it has been around much longer
They allowed me to create solutions with low TCO for the customer, which loves the result and the low price, that helped me create solutions for more clients in less time.
You can save up to 100% of your compute bill, if you stay under a certain tenant conditions.
Without this, we would have to manually update a spreadsheet of our SQL Server inventory
We would also have poor alerting; if an instance was down we wouldn't know until it was reported by a user
We only have one other person who uses SQL Server Integration Services , he's the expert. It would fall to me without him and I would not enjoy being responsible for it.
