Hands-on Experience with Azure Logic Apps Integration Service Environment

Introduction

In this post, we are going to go through an initial experience with Azure Logic Apps Integration Service Environment (ISE). Previously on the Turbo360 blog, there have been articles written that describe what Azure Logic Apps ISE is and whether or not organizations should consider consumption or dedicated billing models. However, this post gives the difference between Azure Logic Apps ISE and the existing consumption-based service.

Note: This blog post will cover Azure Logic Apps ISE, based upon the private preview bits. I have also received permission to blog about these capabilities from the product group (PG) team. Since the bits are in private preview, mileage may vary as the PG makes changes prior to General Availability (GA).

Deployment

Provided your subscription has been whitelisted and you have a URL that contains a feature flag, you can provision an ISE from the Azure Portal by searching for Integration Service Environment.

In order to create an ISE, we need to provide the following:

• Subscription
• Resource Group
• ISE Name
• Location
• Additional Capacity [0 (default), 1, 2,3]
• Virtual Network (VNet)
  • Once we provide a Virtual Network, we need to create 4 blank subnets

Once we provide all of these details and review our selections, we can click Create and our ISE will be provisioned. In my experience, it took approximately 1 hour, 20 minutes to provision.

Creating a Logic App – Hello World

Creating a Logic App is not all that different than from the consumption-based approach. However, there is a subtle difference. When we create a logic app, we have the parameters to populate including Name, Subscription, and Resource Group. But, when it comes to Location this is where things are a bit different. Instead of choosing a specific Azure Region, we will see our ISE appear as an option. Naturally, our ISE map to an Azure Region for us, but it comes up as a distinct option.

Managing our Integration Service Environment

Since our ISE is a resource type, we have management experience for it. We can search for our ISE from the search bar and once we find it, we can pin it to a dashboard. When we access the management experience, we have a series of settings that we can explore.

Some of the information we are interested in the first page includes performance widgets that display our current consumption. The meters that are being tracked include Logic Apps Engine Processor Usage, Logic Apps Engine Memory Usage, Connectors Processor Usage, and Connectors Memory Usage.

Using these performance metrics will allow us to determine whether or not we need additional capacity. If we do need additional capacity, we can enable from the Scale-out experience. Within this experience, we can enable autoscale.

Autoscale events take place based on metrics or specific instance counts.

There are a lot of options when it comes to scaling based upon a metric. We are able to choose our criteria, which will be based upon one of the following metric thresholds being met.

We also need to indicate the operation we want to perform such as increase our scale units. In addition, we have the ability to provide a Cool down period which will wait for that duration before trying to scale again.

Upon further exploration, it looks like we can also use autoscale to reduce scale units as the Action drop-down supports as a decrease in consumption cycles.

In addition, we can add multiple scale conditions so we can account for more advanced scenarios when we may have different load characteristics that trigger an increase or decrease, in resources.

Managing IP Addresses

A common scenario that comes up, is organizations looking to permit, or block, IP addresses with their firewalls. The Logic Apps team has called out all of the public IP addresses that the service uses in their documentation.

Since our ISE is using dedicated infrastructure and we needed to provide four empty subnets, we can expect to have different IP addresses than what is in the public space. From within the ISE management experience, if we click on Properties we will discover the various IP addresses that our connectors are using.

Managing our Hello World Logic App

We can access our logic app, much like we would any other logic app. For instance, I like to pin Logic Apps to my left navigation menu. If I click on this link, I will see all of my logic apps appear including my ISE logic apps.

When we click on the Hello World Logic App and enter the Overview experience we won’t find many differences, with the exception, we now have a label that indicates this logic app belongs to an Integration Service Environment.

If we take a closer look at our left navigation options, we will find all of the entries that exist in a consumption-based logic app, appear in our ISE logic app. But if we dive into Workflow settings, we will discover a subtle difference in the Runtime options. More specifically, we will notice the absence of the High throughput option which allows a developer to override the upper limit of actions that can execute within a single logic app over a 5 minute period. When you think about this, it makes sense that it doesn’t exist. As ISE uses its own capacity, Microsoft will soften limits as we can control our consumption/demand.

This got me thinking, are there other concurrency control changes that exist within our logic app? If we check out our settings for our trigger, the settings remain the same.

If we check out the Concurrency Control for an Apply to each action we will also discover the same settings as in a consumption-based logic app.

Connectors

Connectors in Azure Logic Apps are very different than adapters in BizTalk. In part due to the distributed runtime that exists in the cloud. In the consumption-based service, connectors are hosted in a multi-tenant environment. As a result, throttling is imposed to protect the underlying services.

With Azure Logic Apps ISE running within a dedicated computer, a set of new ISE ‘flavored’ connectors appear for the following scenarios:

• Azure Blob Storage, File Storage, and Table Storage
• Azure Queues, Azure Service Bus, Azure Event Hubs, and IBM MQ
• FTP and SFTP-SSH
• SQL Server, SQL Data Warehouse, Azure Cosmos DB
• AS2, X12, and EDIFACT

Advantage of ISE

The advantage these ISE enabled connectors to provide is they can connect to these resources through your VNet. So, if you have a SQL Server installed in IaaS or on-premises, you can connect to this resource through your VNet instead of using the on-premises data gateway or public internet.

Difference between ISE and Non-ISE

In addition, there are some differences between ISE and non-ISE connectors including where the triggers and actions run. The documentation states: Built-in triggers and actions, including HTTP, run within your ISE computer. For systems that are connected to a virtual network, you can inject an ISE into that virtual network. Now, your logic apps can directly access those systems by using any of these items:

• ISE connector for that system, for example, SQL Server
• HTTP action
• Custom connector

Now there is a distinction to be made here between where something runs and how it is accessed. For example, if we create an HTTP Request trigger, the documentation implies that it runs within our ISE, but, by default, the trigger is still accessible externally, unless you prevent access through networking controls on your VNet.

Let’s now take a closer look at how we can use these ISE connectors. I have created a Blob storage container and the only network access that I have provided to this container, is through the subnets that were created when we provisioned our ISE. This will demonstrate the only way for Logic Apps ISE to access this storage is through our VNet. External access is not permitted.

If we try to access our Azure Storage Account from the public internet, we are unable to access.

Create a connection to Azure Blob Storage, it is important to use actions that have the ISE badge added to them.

Our scenario will be very simple, we will retrieve an image from the internet using HTTP and then create the image inside of blob storage.

If I now add my current IP address to the Firewall permit list, we are able to browse our Blob container and view our file contents.

Integration Accounts

Integration Accounts are available to be used in conjunction with Logic Apps ISE. However, if we have a logic app that is deployed to our ISE, it can only reference Integration accounts that have also been deployed in our ISE. When provisioning an Integration account, we need to ensure deploying it to our ISE available from our Location drop-down.

Do I need an ISE?

This decision really comes down to organizational requirements as mileage does vary. Here are some factors worth considering:

• Consumption vs Dedicated Billing – For some organizations, having a consumption-based model provides cost advantages as it allows them to pay for just what they need. For other organizations, the budgeting process occurs months, or years, in advance so the predictability of having a fixed monthly cost that can be accurately forecasted, may be important.
• Network Security – Now this doesn’t imply that the consumption-based version is insecure, but for some organizations, they may prefer to have all network traffic traveling within their own Virtual Network (VNet). As demonstrated in connector’s walk-through, we can connect to Azure services using our VNet, instead of the public internet.
• Hybrid Connectivity – The VNet connects to our on-premises or local computing services. Yes, the on-premises data gateway traverse the corporate firewalls from the consumption-based Logic Apps service. But, there are limitations of the gateway including through-put and message payload size. Leveraging VNet connectivity over an Express Route connection provides dedicated bandwidth with Quality of Service (QoS).
• Dedicated Capacity – If an organization has business requirements where strict SLAs need to be met, having more predictability over the performance of your interfaces may be an important consideration.

For additional considerations when choosing the right version of Azure Logic Apps is for you, please refer to this previous blog post.

Future Considerations

Azure Logic Apps ISE is in private preview right now. Here are some of the areas that I came up with:

• Dev/Test Workloads – Pricing is still to be determined. One of the areas that organizations are going to have questions about is where do I place my Dev/Test workloads? Do I place them in the same ISE as my production services? Do I create additional ISEs and dedicate them to these non-production workloads? Certainly, load and cost will play a role in determining which solution is best for your organization.
• Business Continuity/Disaster Recover – If organizations are paying for a dedicated offering, where a ‘bubble’ has been placed around all of the resources, it is natural to expect if there ever was a region-wide availability event, how would we transition the ISE, and its resources, over to another region? I am certainly not trying to trivialize the effort in solving this, but for organizations who are serious about integration and make a significant investment in ISE, expectations are higher than a pay-as-you-go service.
• Azure Integration Services Bundling – Azure Integration Services includes complementary integration services including Azure API Management, Service Bus, and Logic Apps. Through the addition of ISE, all three of these services now have a premium model that supports dedicated capacity and VNET connectivity. There is a high probability that if dedicated capacity and/or VNET connectivity is important to you for one of these services. So, now the question is, are there financial incentives available to bundle these different premium services and is there a unified deployment experience available?

Conclusion

In this post, we took a hands-on approach on the features that are available in Azure Logic Apps ISE. I would not consider a significant learning curve if you are familiar with the Azure Logic Apps. There are a few subtle differences which are easily overcome. This is obviously great as we can take our existing investments and port them over to ISE.

Obviously, organizations have a decision to make when it comes to evaluating ISE. But, having options are good, especially when there is little impact on how you build your interfaces and the ISE.