Introduction
In the recent Consumption vs Dedicated Billing Models, which One is for me article, we discussed an upcoming capability within Azure Logic Apps called Integration Service Environment, or ISE for short. In this article, we are going to dive deeper into ISE and identify some of the opportunities for organizations who may be considering this implementation of Azure Logic Apps.
What is Azure Integration Service Environment
In the Azure Logic Apps documentation, it defines an Integration Service Environment (ISE) as a private and isolated Logic Apps instance within your Azure virtual network. The private instance uses dedicated resources such as storage and runs separately from the public global Logic Apps service. This approach differs from the existing consumption-based plan that takes advantage of pooling customer demand across a shared infrastructure. The benefit for customers is that they only pay for what they use.
An Integration Service Environment (ISE) requires a monetary commitment from customers. But in return provides dedicated resources which will result in a more predictable performance. While Azure Logic Apps does provide a reliable platform for businesses to build on top. It does leave room for ‘noisy neighbor’ situations where a spike in one customer’s demand can have an impact on others. By having dedicated resources you isolate yourself from other customers by having your own resource pool.
Virtual Network Connectivity
One of the benefits of using an Integration Service Environment is the ability to select a Virtual Network (VNET) for your Azure Logic Apps deployment. This allows you to run Azure Logic Apps within an isolated network that is not exposed to the public internet. The Azure documentation refers to this behavior as: “Azure deploys a private instance of the Logic Apps service into your virtual network, resulting in an isolated environment where you can create and run your logic apps on dedicated resources. When you create a logic app, you can select this environment as your app’s location. Which also gives your logic app direct access to the resources in your virtual network.”
What makes this capability interesting is that for organizations who have created a site to site VPN or Express Route connections between their data center and the cloud, these connections occur over a VNET. So the VNET capability that is now introduced, in Integration Service Environment (ISE), allows Azure Logic Apps to communicate with on-premises assets without the use of an on-premises data gateway, by using these VNETs.
Connector Connectivity
Now that we have discussed the ability to connect to your corporate network using a VNET, a question you may be asking yourself is how will these connectors know to use public network paths or private network paths? The answer is a new set of connectors that support ISE. More specifically, here is a list of connectors that will allow you to connect to VNETs through the ISE:
- Blob Storage, File Storage, and Table Storage
- Azure Queues
- Azure Service Bus
- FTP
- SSH FTP (SFTP)
- SQL Server
- AS2, X12, and EDIFACT
The way you discover these ISE connectors is the same as you discover any other connector. By simply searching for a connector within the Search connectors and triggers text box you will discover an ISE label below the name of the connector. In the image below, we can see the FTP and FTP ISE connectors. The ISE version of the FTP connector will allow you to poll internal FTP sites by using your private network path which is now possible as your network traffic will move through your VNET.
Image Source: https://docs.microsoft.com/en-us/azure/logic-apps/connect-virtual-network-vnet-isolated-environment-overview
VNET Configuration
The timing of when you connect Azure Logic Apps to a VNET is really important as you really only have one opportunity to configure this VNET connectivity. The Azure documentation states: “When you create an integration service environment (ISE), you can select an Azure virtual network as a peer for your environment. However, you can only create this relationship, or peering, when you create your ISE. This relationship gives your ISE access to resources in your virtual network, which then lets logic apps in that ISE connect directly to resources in your virtual network.”
With your VNET established, you can access resources within your on-premises network through three different modes:
- ISE connector for that system, such as FTP which we just discussed
- HTTP Action
- Custom connector
Beyond the ISE connectors, the HTTP action will open many opportunities for customers who have existing RESTful APIs within their network. Previously, accessing these resources was difficult as a custom connector needed to be provided. So unless you were connecting to BizTalk Server 2016, PostgreSQL, DB2, SAP, File System, SharePoint Server, Informix, SQL Server, MQ, Teradata, Oracle Database you had to deploy a custom connector. Creating a custom connector just to connect to an HTTP endpoint feels rather heavy. But now, by just providing an HTTP endpoint and having the network location automatically resolved through your VNET provides a lot of conveniences and increases the value proposition of using Azure Logic Apps in an ISE configuration.
For systems that do not have an ISE connector, such as SAP, these systems can still be accessed by using the on-premises data gateway. The on-premises data gateway can help bridge these hybrid connectivity requirements until more ISE connectors are made available.
Integration Accounts
If you want to use Integration Accounts within your Azure Logic Apps ISE environment, the Integration Account needs to be designated as an ISE Integration Account. You can specify that an Integration Account belongs to a particular ISE at creation time.
Pricing
While pricing for ISE has not been published yet, the Logic Apps team has indicated that “Logic Apps, built-in actions, and connectors that run in your ISE use a different pricing plan, not the consumption-based pricing plan.” This is understandable since ISE environments will be based upon a fixed monthly price for built-in actions.
For Enterprise connectors, ISE customers will have some entitlement. On the Azure Logic Apps pricing page, it indicates “your ISE includes one Enterprise connector at no charge”. Additional Enterprise connectors will be charged based upon the Enterprise consumption price, which currently metered at $0.001 as per the Azure Pricing Calculator.
Why should I consider ISE?
Customers now have an additional deployment model they can consider by using a fixed price ISE. There are many factors that a customer should consider when choosing whether the traditional consumption-based approach is more advantageous over the fixed ISE model.
A big consideration should be where you, or the customer, are in their integration journey. For example, if you are new to using an Integration Platform as a Service (iPaaS), it may make sense to use a consumption-based approach where you can start slow and build your competency. This way you can pay for exactly what you use and realize benefits along the way. This also allows you to avoid some of the challenging return on investment (ROI) problems that emerge in traditional middleware capital investments.
Another situation that has emerged recently is for organizations who have a mature integration practice. They may not want to have to have fixed costs on two different integration platforms. For example, let’s imagine a customer adopted an iPaaS tool in 2015. They are likely paying a fixed yearly price for this service based upon some sort of resource constraint including CPU or cores. The customer may be in a situation where they find this yearly subscription is too costly.
But due to subscription renewals, they want to be careful about how they transition to a more consumption-based offering. Knowing that migrating, or re-building, an entire eco-system does not occur overnight, a customer may put together a transition plan that sees them transitioning these assets incrementally over the course of the year prior to their renewal. This allows them to incrementally pay and allows them to avoid paying for 2 fixed price integration platforms.
For customers who want more cost certainty, using a dedicated or fixed model may be a more appealing option. It may be more appealing due to factors including budgeting. For many organizations, they forecast to spend in the previous year and sometimes for multiple years in advance. Being able to dynamically pull from an unused funding pool, to cover unexpected consumption costs, may not be the desired approach by the organization’s finance department.
Naturally, another benefit of a dedicated model is you have more control over the resource pool where your integrations are running. So if you have strict service level agreements (SLAs), then having a dedicated model will ensure the delivery of your service is consistent. For some customers, providing a consistent capability is worth making that up-front commitment to Microsoft.
While these previous considerations really focused on price, another important consideration is VNET connectivity. For many organizations, Hybrid computing is a requirement and not an option. Having a cloud-only integration platform creates some friction and limits their ability to address all of their non-functional requirements. Using a VNET reduces some of this friction since your Azure Logic Apps instance is now directly connected to your on-premises network.
This VNET can be extended over a site to site VPN connection which is not expensive to set up. Alternatively, an Express Route can be set up which ensures of Quality of Service (QoS). Ultimately, using a VNET makes your Azure Logic Apps instance look like a local service to your existing systems that live on-premises. But, while it may look local to these different services, you still take advantage of all the connectivity that is available in the cloud. In addition, you also take advantage of other iPaaS benefits like not worrying about patching and the underlying infrastructure.
Conclusion
Customers are the real winners when it comes to considering Azure Logic Apps ISE. They now have some additional options when choosing which route to take. Having options between consumption and dedicated plans allows customers to allocate their capital in the most advantageous way for them. This is ultimately a good thing, regardless of which route they decide to take.
Once Microsoft publishes ISE prices, customers will have an opportunity to build a more accurate business case for ISE based on existing Logic Apps usage. Until then, it is important to understand the opportunities and limitations of the technology, to make an informed decision.
