Reducing Complexity, Increasing Velocity through Azure Integration Platform as a Service (iPaaS)

Kent Weare, Senior Enterprise Architect & Integration Lead, TransAlta [NYSE:TAC]
397
695
131
Kent Weare, Senior Enterprise Architect & Integration Lead, TransAlta [NYSE:TAC]

Kent Weare, Senior Enterprise Architect & Integration Lead, TransAlta [NYSE:TAC]

Organizations have been integrating their systems for decades. It may be as simple as a point-to-point file drop or as complex as a real-time, multi-system trade floor solution running on-top of a proprietary message queuing protocol. Regardless of the skills of your current staff, integration continues to be a pain-point for a lot of CIOs. Integration is often times considered to be complex, because, by nature, it is. You are typically wiring up multiple systems that were never intended to be partnered together.

On-premises middleware has been mainstream for more than two decades. Often times, it can get the job done, but with a herculean effort. You are typically relying on specialized vendors or experts with several years of experience to build the right solution. Or, even worse, relying on people with less experience who may leave you with more challenges than you started with.

Another challenge with traditional middleware platforms is they may not have the modern connectivity capabilities to support a lot of the current generation SaaS applications or progressive machine learning and cognitive service APIs that today’s cloud leaders are making available.

A key staple for iPaaS platforms is addressing this connectivity challenge that has plagued on-premises incumbents. Connecting to Salesforce or Dynamics 365 should be a matter of a few mouse clicks. Another key feature of an iPaaS platform is the tooling. Most iPaaS platforms allow you to configure interfaces within a modern web browser as opposed to Gigabytes (GBs) of tools that need to be installed locally for traditional middleware.

  ​By reducing the challenges related to connectivity, tooling and infrastructure, the barrier of entry for organizations adopting iPaaS is extremely low   

Traditional middleware is typically dependent upon a large infrastructure footprint supporting these interfaces. These environments are often very complex and involve multiple application, web, database and message queuing servers. On top of this, you need to replicate these components across your Dev, Test, QA, UAT and Production landscapes. To make matters worse, after all of the effort and cost of provisioning these systems, you still haven’t worked on solving the original business problem!

In an iPaaS world, we are no longer concerned with specifics of the underlying infrastructure. A popular term these days to describe this phenomenon is called “serverless”. In this context, I am not concerned with how many servers my iPaaS vendor has, I am not concerned about the name of the server and whether it has 10 or 100 GB of memory. Those implementation details become the responsibility of the vendor. I am still concerned about the performance of my interfaces and an expectation is these performance KPIs are easily exposed by my iPaaS vendor in a dashboard.

Another benefit of this serverless architecture is upgrades. On-premises upgrades are typically very painful. In-part because your landscape is so vast and the business problems that you are trying to solve, via integration, are complex. Because of the complexity and cost of on-premises upgrades, most organizations are stuck in a 3-5 year refresh cycle. But, think back to 5 years ago and how this industry has changed. Do you really want your integration developers using technology from 5 years ago to solve modern day problems? Using an iPaaS platform places the upgrade and innovation cycles on the vendor. In the case of Microsoft and their iPaaS platform, Azure Logic Apps, innovation is released monthly, if not weekly. This now arms my integration developers with cutting edge tools to solve modern day problems.

By using a serverless architecture, we also get out of long-term subscription contracts and avoid the risk of building for peak consumption. Instead, Microsoft has introduced a graduated consumption model that allows customers to pay for exactly what they use. Use a little, pay a little. Use a lot, pay more, but at lower cost per unit. This is completely game changing for organizations that want to avoid large up-front capital investments to get initial interfaces in production. It also allows for simple charge back to projects as they work through the implementation stages. If you are paying a yearly subscription for your iPaaS platform, you are missing out on consumption-based billing.

By reducing the challenges related to connectivity, tooling and infrastructure, the barrier of entry for organizations adopting iPaaS is extremely low. Not only does it require less expertise in this domain, but even your experts benefit by the productivity gains that exist in iPaaS platforms like Microsoft’s Azure Logic Apps.

At TransAlta, we are currently in a hybrid mode where we continue to have On-premises middleware, but opportunistically use Azure Logic Apps as our connectivity and innovation layer. Microsoft has done a great job of harmonizing these cloud investments with existing on-premises investments which make wiring-up hybrid integration scenarios frictionless. Whenever new project requirement emerges, we look at Azure Logic Apps first and evaluate its use based upon some of the criteria discussed in this article. Ultimately speed and velocity are really important for us these days, but so is a consumption-based billing model. Due to these advantages, we will continue to invest in Logic Apps and, over time, migrate existing interfaces over to Logic Apps to take advantage of all these underlying serverless benefits. The overall benefit for our business is we reduce our operational and project costs, increase velocity while providing them access to the latest innovations available in the cloud to solve their business problems.

Read Also

Reinventing Race Tracks

Reinventing Race Tracks

Stephen Byrd, Director, Technology Development, NASCAR
Building Software Solutions in the Cloud at Scale: Learnings from Milliman

Building Software Solutions in the Cloud at Scale: Learnings from Milliman

Paul Maher, Principal & CTO, Milliman - Life Technology Solutions
Designing a Comprehensive Strategy

Designing a Comprehensive Strategy

Don Franklin, Assit. VP-IS, Intermountain Healthcare