When looking at hybrid integration and integration just within the Azure cloud environment, it can be difficult to know what to use and when. To provide some guidance, the following table aims to highlight the key strengths of each technology with an idea of when to use them.
|
Technology |
Strengths |
Weaknesses |
|
Logic Apps |
Provides a simple-to-use connector semantic that allows quick connection to a large variety of sources
Contains the most common control flow options
Has a simple-to-use JSON-based language accessible via a code view, which allows customization of the flow and any connectors
|
Lacks connectors to key on-premises line of business solutions, such as JD Edwards and PeopleSoft
More complex control flows are difficult to model, and they can lead to the need to create many Logics Apps that need tying together
|
|
API Management |
Provides a simple-to-use API governance tool providing policy-driven solutions |
Cannot be used to create complex integration flows and flow rules |
|
Functions |
Simple-to-use serverless technology that is pay as you go and can provide HTTP API access to simple business rules processing
Does not maintain state and so is very scalable
Executes key business processing quickly
|
Lacks the expression language required by business users to articulate key rules
Should only be used for short pieces of code that can execute quickly and not require state
|
|
Event Hub |
Hyperscale ingestion of telemetry data from connected devices
Partitioning and archiving provide additional functionality than simple ingestion
Supported by many other Azure services
|
One-way communication only
No device governance limits their use in true Internet of Things scenarios that require device life cycle
No device management limits use in Internet of Things scenarios that require over-the-air updates
|
|
IoT Hub |
Bidirectional communication providing full command and control
Device registry and identity provides governance
Security built in from device to cloud
|
More complex than Event Hub for telemetry ingestion scenarios |
|
BizTalk Server |
On-premises integration platform
Many connectors to key business data sources
Full orchestration engine
Full business rules engine
Supports complex messaging patterns
|
Not a platform service, so requires key skills
Steep learning curve means that it is hard to get productive quickly
|
|
Microsoft Flow (discussed in detail later) |
A lightweight version of Logic Apps that is similar in use to IFTTT (http://www.ifttt.com) and Zapier (http://www.zapier.com) |
Basic flows only
The limited number of connectors available
Part of Office 365 or priced based on usage, including a free tier
|
A key aspect of any integration project is understanding not only how the technology has changed but also what mistakes have been made in the past and how to move forward.
A good example of this is service-oriented architecture, or SOA. This was supposed to become the ubiquitous approach to service and data provision for an enterprise and make the application architecture agile and easy to change. It never fully delivered on this vision for many reasons, including over-complexity and expectations that were simply too high. SOA services typically spanned many tiers in a multi-tier architecture and became monoliths themselves that sat in front of the large monolithic applications they were trying to mediate. Although solutions such as enterprise service buses introduced the ability to coordinate the interaction of these services, they added additional complexity, and the enterprise was often left with a tangled mess that was at least as bad as the application they were trying to replace.
Microservices are a new approach to service orientation and deliver smaller and more discrete solutions that are easier to change, easier to version, and much easier to manage. Only time will tell if they succeed where SOA failed, but for now, they offer a lightweight approach to service provision and an opportunity to use the best tools for the job for each service delivered. Typically, these services are going to be delivered as HTTP services via RESTful APIs and require stitching together to create a solution. By being agile, compact, and having a single responsibility, which are all important requirements for a microservice, it is possible to construct a solution that is itself agile and open to change, thereby removing the specter of monolithic applications that SOA solutions never eliminated.
However, when building solutions that communicate over HTTP and often over the public Internet, it is important to consider factors beyond just the creation of the solution. In these applications, the role of nonfunctional requirements becomes more important than ever.
Nonfunctional requirements, such as performance, latency, security, and reliability, need to move to the next level when the infrastructure on which they are built is no longer in the control of the organization. This infrastructure can be both at the network level, with modern workloads communicating over volatile Internet connections, and the machine level, with workloads constructed from platform services where the management of availability is controlled by a service-level agreements and service credits in the event of a problem.
This leads to several considerations that must be taken into account when building modern applications:
- A design for connectivity failure: Internet connections leverage network infrastructure that typically belongs to, and is maintained by, telecommunications companies. Although these companies do their best to keep service interruptions to a minimum, they do still occur. Any application or integration solution needs to take this connectivity issue into account to ensure some form of continuity. This could take the form of retry policies that may cope with transient outages or the use of the circuit breaker pattern (https://msdn.microsoft.com/en-us/library/dn589784.aspx) to account for longer term issues or through the use of Entity Framework Connection Resiliency (https://msdn.microsoft.com/en-us/library/dn456835(v=vs.113).aspx).
- A design for hardware failure: One of the strengths of cloud computing is cost and the use of platform services to build a solution; for cloud providers to keep these costs at a minimum, they typically use cheaper commodity hardware. To overcome the issues of hardware failures, platform services often have some form of redundancy built in. For example, Azure Storage makes three copies of files across different storage resources. However, depending on the service and the provision for failover of the service, any application or integration solution should still consider what action to take in the event of hardware failure. If the hardware in question is a virtual machine, the solution can be made more resilient using availability sets and balancing load between the instances of the application (https://docs.microsoft.com/en-us/azure/virtual-machines/virtual-machines-windows-manage-availability). If the hardware is providing platform services that you are not responsible for, then good application design, again perhaps using the circuit breaker pattern, can help relieve issues.
- Design for geographically distributed services: Azure data centers are globally distributed and provide most platform services across these data centers. For large-scale applications and integration solutions that need global reach, a solution needs to take in to account latency and experience of the end user by providing timely access to resources such as websites. This can be achieved using Azure Traffic Manager to ensure that local resources are accessed over those more geographically displaced (https://azure.microsoft.com/en-us/services/traffic-manager/), but the backend services also need to understand how to provide services using data replication, messaging, and eventual consistency.