The Integration Account is a service that is part of the Logic Apps Enterprise Integration Pack (EIP) to facilitate more complex integration scenarios, particularly those involving business-to-business (B2B) transactions. In resume, the key features of the Integration Account are:
- B2B Communications: It supports B2B solutions by handling Electronic Data Interchange (EDI) standards like EDIFACT, X12, and AS2 protocols. This allows businesses to automate and standardize transactions with partners.
- XML Processing: The Integration Account provides advanced XML capabilities, such as XML validation, XML transformation using XSLT (Extensible Stylesheet Language Transformations), and XML-based workflows.
- Schema Management: It stores and manages schemas (XSDs) that define the structure of XML messages used in your integrations.
- Maps Management: It manages maps (XSLTs), which are used to transform XML message formats from one schema to another, which is essential in integrating systems that use different message formats.
- Certificates and Partners Management: For secure transactions, the Integration Account can store and manage certificates. It also allows you to manage trading partners’ profiles and agreements for EDI communications.
- Integration with Logic Apps: It’s part of the Logic App services, so it seamlessly integrates with Azure Logic Apps, enabling the design and deployment of complex workflows that can automate business processes across different applications and services.
If you were an earlier adopter of Logic Apps to implement more advanced XML integration solutions, an Integration Account was almost a requirement. Even nowadays, if you use the out-of-the-box capabilities the Integration Account is a requirement for Logic App Consumption.
No matter if you invoke many XML transformations or validations or none, the cost of having an Integration account per month is ~277.56€ with the basic tier and ~913.11€ with the Standard tier.
If you indeed need to implement B2B scenarios with EDI or RosettaNet, the Integration Account is a must-have, but to implement advanced XML capabilities it seems a little bit too much to pay for it. Of course, during these years, we tend to see two types of Azure “clients”:
- Clients that start small and get bigger. This type of Azure client typically begins with a modest setup, often a startup or a small business venturing into cloud computing. Their initial cloud infrastructure is minimal, focusing on essential services like basic Azure Functions, a couple of VMs, or entry-level database services. Cost efficiency is key, so they opt for pay-as-you-go or low-tier plans. Most of the time, the solution design is based on cost savings or cost control. As the business expands, so does their cloud usage. They gradually scale up their resources, moving from smaller to more robust services. This might include transitioning from Azure B-series VMs to D or E series, scaling up SQL Database tiers, or increasing the capacity and capabilities of their storage solutions. They utilize Azure’s scalability features to accommodate growing traffic and data, adapting their architecture to a more complex setup like microservices or serverless architectures to handle increased demands.
- Clients that start Big from day zero. This client type is typically a large enterprise or a well-funded startup that requires a substantial cloud infrastructure from the outset. Their needs include high computing power, extensive data storage, advanced networking setups, and often global distribution. They know the roadmap they want to archive, so they prefer to invest in premium Azure services from the beginning, like Service Bus, Azure Kubernetes Service (AKS), high-tier VMs, and Cosmos DB, anticipating high traffic and data processing needs. For these clients, growth doesn’t necessarily mean a significant increase in resources but rather an optimization and diversification of existing services. They might focus on enhancing performance, implementing sophisticated AI and machine learning capabilities, or expanding their geographic presence through Azure’s global data centers. Their infrastructure is already robust, so scaling is more about refinement and expanding capabilities rather than increasing size.
No matter which type of client you are, there will come a point in time when the topic of Azure cost will be at the top of the table inside your organization, and the requirement will be: Can we reduce our Azure costs? How and where can we optimize and reduce Azure costs? Along with several other questions.
At that point, tools like Turbo360 help you analyze and optimize the Azure costs.
Turbo360 is a tool designed to assist with the management and monitoring of Azure services, particularly those related to serverless architectures like Azure Functions, Logic Apps, Service Bus, and more. It can be particularly helpful in monitoring and optimizing your Azure costs in several ways:
1. Comprehensive Monitoring
- Resource Utilization: Turbo360 provides detailed insights into the utilization of your Azure resources. By monitoring metrics like execution counts, execution times, and resource usage, you can identify inefficiencies or underutilized resources.
- Alerts and Notifications: Set up alerts for resource usage thresholds. This can help in taking proactive measures to prevent overuse and unexpected costs.
2. Cost Analysis and Optimization
- Cost Tracking: It offers tools to track the costs associated with your Azure services. By understanding where your budget is being spent, you can make informed decisions about where to cut costs.
- Identify Underutilized Resources: Turbo360 can help identify resources that are underutilized or unnecessary, which can then be scaled down or removed to save costs.
3. Automated Actions
- Auto-Scaling: Implement auto-scaling policies based on the actual load. This ensures that you only pay for the resources you need when you need them.
- Scheduled Enabling/Disabling: For resources that are not required to run 24/7, Turbo360 can automate the process of enabling or disabling them based on a schedule, reducing costs.
4. Reporting and Analytics
- Custom Reports: Create custom reports to have a clearer understanding of your spending patterns. This can help in budgeting and forecasting future costs.
- Usage Analytics: Detailed analytics on the usage of each service can uncover areas for cost optimization.
5. Governance and Compliance
- Policy Enforcement: Ensure compliance with organizational policies regarding resource usage and costs, helping to avoid unnecessary expenditures.
6. Integration with Azure
- Seamless Integration: Turbo360 integrates with Azure, providing a centralized platform to manage and monitor all your serverless components.
By providing these features, Turbo360 can be an effective tool in helping manage and optimize Azure costs. It allows for more efficient use of resources, better budgeting, and cost-effective decision-making. Keep in mind to fully leverage Turbo360, a good understanding of your Azure architecture and cost model is essential. Regularly reviewing and adjusting your Turbo360 configurations based on changing usage patterns and business needs can help maximize its benefits in terms of cost optimization.
How and when can we apply Integration Account cost savings?
For some customers, Integration Account pricing can be a deal for others not, but in all cases, if you only need to implement advanced XML scenarios inside Logic Apps like XML validations and transformations, you have here an opportunity to apply some cost savings. Once again, no matter if you use artifacts frequently or not, the cost of an Integration Account is the same: ~277.56€ with the basic tier and ~913.11€ with the Standard tier. That means an average of 3.3K or 10.9K savings per year!
So, what are the alternatives?
Logic App Standard
If you are using Logic App Standard, then you are lucky! Logic Apps Standard already supports out-of-the-box XML capabilities without the need for an Integration Account. Standard will enable developers to upload maps and schemas to their respective folders within the artifacts folder of their project, which now also includes a folder – lib > Custom > net472 – where they can place compiled assemblies that are called from XSLT maps.
Since Logic Apps Standard does not depend on the integration account service, the transformations can be moved quickly into the artifacts folder. The XSLT + .NET Framework addresses a couple of core scenarios, especially for BizTalk Server customers looking to move integration workloads from BizTalk Server to Azure Integration Services. Now, they can take advantage of this capability and move their data transformations into the cloud without having to re-map nodes and elements.
Logic App Consumption
If you are using Logic App Consumption that fits your scenario – pay-per-use – and you don’t want the additional or the fixed cost of the Logic App Standard, then you need to look for an alternative to store and use these artifacts because at the end on those scenarios the Integration Account is just an artifact storage and the out-of-the-box actions need that type of storage to perform their actions.
Luckily for you, we can replicate these capabilities in a more cost-efficient way by using a:
- Storage Account that can have a cost of €0.00410 per GB per month. With 1 GB, I think we can have more than 1000 maps, which is the maximum number of maps we can have in an Integration Account in the Standard tier.
- An Azure Function that, in the consumption plan, has -1 million executions free (400,000 GB-s Execution time) and a total average cost of €0.183 per million executions (€0.000015/GB-s).
Almost free capabilities that you can implement with a little bit of development.
Taking the transformation as a sample. You can accomplish the same by:
- Create a storage account or use and existing one, and inside your container, add a new container called maps and upload all your maps to that container.
- Now, we need to create an Azure Function to read that map from the storage account and apply the transformation. To do that, you can use, as an example, my Azure Function to Apply XSLT Transformations. This function allows you to dynamically convert an XML payload into another XML, JSON, or any other format using XLST. To use this function, you must set up an Azure Storage Account and a container to store the XSLT files. To trigger this function, you need to:
- In the Body, send an XML payload
- You should specify the following mandatory headers:
- Content-Type as text/xml, or application/xml.
- XsltFileName with the name of the xslt file present in the storage account.
- Optionally, you can set the following header:
- Output-Content-Type: this will specify the outcome (response) content-type. The default value is text/xml.
- Finally, on your Logic App, we need to replace the XML Transformation action with a call to the previous Azure Function or by using the HTTP connector or the Azure Function Connector. Alternatively, if you are using API Management, we can expose this function on the APIM and call them using the APIM Connector.
The same can be easily applied with XML validations using the same approach.
In some scenarios or resources, enabling/disabling the services will help you save on cost. A good example of this is when we use non-production VMs or non-production resources like Logic App Standard. However, in some scenarios, to implement cost savings, we need to redesign our solutions.