An Overview of Azure Integration Services

Azure Integration Services is a Microsoft cloud offering of services for mission-critical integrations. It provides a serverless compute experience that drives consistency and efficiency when connecting applications.

A subcategory of PaaS — Platform as a Service — the iPaaS is the term that refers to the integration platforms offered as a service.

API Management, Logic Apps, and Service Bus, and Event Grid are the products provided by Azure for integration solutions that make easier the life of the developers.

Understanding your tool and applying it to the right scenario is fundamental. For example, you don’t use a screwdriver when you need to put a nail on the wall — you use a hammer.

The same applies to the integration tools. You must plan and use the most suitable component according to the needs of your scenario.

The key components need to be put together on a robust and reusable platform, so we don’t need to design the integration all the time.

The components that are part of it are APIs, Workflows and Orchestration, Enterprise Messaging, and Events.

The mapping of these component types and the Azure Integration Services solutions to attend them are:

• Azure API Management → APIs
• Azure Logic Apps → Workflows and Orchestration
• Azure Service Bus → Enterprise Messaging
• Azure Event Grid → Event-Driven Applications

Azure API Management

Azure API Management offers a centralized way to manage and control the catalog of APIs to access the backend systems for driven integration, enabling internal systems, partners, and businesses to connect.

It provides security with selective expose of data and services, applying authentication, authorization, cache responses, and fine-grain quotas and limits.

Other features include filter, pagination, partial response for large binary files, versioning, and policies. Such policies allow the creation of data conversions(XML to JSON), request transformations (SOAP to REST), cache, and IP blocking, for instance.

Existing services, such as Web Services, can also be integrated and exposed as modern RESTful APIs.

Besides, it also offers a customizable developer portal, where the APIs can be discoverable by internal development teams, partners, and customers.

It supports the Swagger framework, a standard framework that helps on the schema import on the applications that will consume the RESTful API.

Apart from that, it also provides analytics for usage tracking and health check of the operations.

Azure Logic Apps

Azure Logic Apps is a serverless orchestration and workflow tool that allows the creation of a business logic application without the need to create an essential infrastructure to get started.

By using business connectors and logic objects, it is possible to create business processes, seamlessly visually, and automatize workflows without the need to write a single line of code.

For example, it can connect to Azure Services, on-premises applications such as Oracle, SQL Server, and SAP, and SaaS solutions, such as SalesForce, ServiceNow, and Office 365. Those are just examples of more than 200 connectors currently available besides the standard protocols like HTTP, FTP, and SMTP.

It offers flow control objects such as conditional statements, looping, variables, and actions to call external systems using business connectors.

You can create your logic app with a visual designer, but under the hood, it saves it as a JSON format, with the identification of each step, type of action, connector, and any parameter used. This format is convenient to automatize the creation and deployment process and adapt it to a DevOps pipeline.

Azure Service Bus

Azure Service Bus allows the creation of integrations asynchronously, when the sender doesn’t need to wait for a response right on the action of calling the integration — or doesn’t need a response at all, also know as “fire-and-forget” call.

This is a great scenario when considering microservices and decoupling components. By doing this it is possible to mitigate the dependency from other systems that can impact the performance of the application.

Azure Service Bus offers queues where applications write and read messages, taking the necessary actions to process the message.

Azure Storage Account indeed offers the option to create queues, but this should be used for simple integrations and specific scenarios.

The storage queues, feature a simple REST-based GET/PUT/PEEK interface, providing reliable, persistent messaging within and between services.

On the other hand, the service bus goes further, supporting publish and subscribe, as well as advanced integration patterns, with the option of multiple communication protocols, data contracts, trust domains, and network environments.

Check this documentation from Microsoft on the full comparison between Azure Storage Queues and Azure Service Bus:

The usage of topics is handy for systems that process messages from several sources and must provide a feedback response.

Imagine a scenario where a Document Management System wants to save a document on the Sharepoint library. Several consumer systems can call this integration, putting a message on an inbound queue. After processing the record, the Document Management System can put a message on an outbound queue on a specific topic. The consumer system they subscribe to its particular topic to read the response from the Document Management System.

Azure Event Grid

Azure Event Grid is used to notify when a specific event happens. In the previous scenario where we described the Document Management System, the consumer must have a service that pools the outbound queue on a particular interval of time, checking whether or not there is a new message to process.

Instead, the solution could add an event trigger to an Event Grid that invokes an action. This action can be the execution of a specific Azure Function, for example, or even a Logic App.

In this way, the development gets simplified, and this approach can also save money because the service will only run when needed, triggered by the Event Grid.

Putting it All Together

I mentioned before that you need the right tool for the right task, using a hammer when you need to put the nail on the wall.

But sometimes your whole solution will need nails, screws, pipes, and installing a faucet.

For such cases, you will often combine the products to attend a more robust architecture requirement.

"The scenario begins when a customer submits an order through a web application (step 1). This application sends a message to Service Bus describing the new order (step 2). This message might contain a JSON document identifying the customer, the item, and the quantity ordered. When this message arrives in a Service Bus queue, an event is generated for Event Grid (step 3). This event then triggers execution of a logic app (step 4), which immediately reads the message waiting in Service Bus (step 5). The logic app extracts the information in this message, then executes a business process by accessing the necessary applications (step 6)."

Governance

The services provided for integration are excellent, easy to use, and implement. But with the easiness comes the importance of having a good governance plan in place to keep the things under control.

Some time ago, when we used to manage on-premises software for integration, such as BizTalk, it was clear to have one group — or sometimes one person — responsible for maintaining it, centralizing the integration needs.

But with different components and the agility required by the enterprises to deliver faster and faster, reliable, and consistent, it is crucial that the Dev and Ops team responsible for the application have the autonomy to create and maintain it’s components.

It leads to having multiple teams working on the same type of products with different objectives, so that’s why it is crucial to have a governance plan.

Other questions, such as whether or not consolidate and centralize an API management solution must be in place and clear to the whole organization.

And remember that integration is about moving data from one point to another. And with data comes policies that must be followed to make sure that the right application has the proper access to the information, not being able to access data outside its boundaries.

But keep in mind that governance shouldn't delay your development process with manual validations and checklists, quite the opposite. Take advantage of Azure Policies to create the rules and make sure that the components deployed in your environment are compliant to the defined and required rules.

Conclusion

Azure Integration Services offers vital components that work together on a reliable and reusable platform, so we don’t need to design integration all the time from scratch, reducing the risk of implementation taking advantage of a widely used platform.

Using these four pieces — API Management, Logic Apps, Service Bus, and Event Grid — will help you to achieve reliable solutions to build all the integration needed as part of the Enterprise Architect.

Each one of this product has it’s own value, but when combined as shown on the integrated scenario, is when it becomes dominant with the real value.

For more information, visit the Azure Integration Services whitepaper, where the screenshot images were taken, at:

I hope you learned something new today. And as usual, don’t forget to follow, comment, like, and check the other articles of DevOps, Cloud & IT Career Publication!