This post demonstrates how to implement publish-subscribe functionality in the Azure cloud. This pattern is widely used in numerous applications and can prove to be highly beneficial. Github repository with solution: click here
Prerequisites post: https://www.skycloudnest.com/post/azure-use-cases-prerequisites
Architecture
Our case will involve one sender resource and two receivers. The following is a basic concept of what it will look like.
Sender Logic app
There is nothing noteworthy about this resource; it could be anything else. The decision to use Logic App was made to facilitate the implementation of ready-to-use architectures due to its simplicity - logic-ps-model-sender-{env}
Azure Service Bus
The service bus is the most popular service created for archiving the publish-subscribe pattern. Topics are created for this purpose: a publisher sends a message to the topic, and one or more subscribers can receive a copy of the message. In the sample that we are about to review, we will have two subscriptions:
One designed for a logic app and the other for a function app.
The section concerning service bus topics and subscriptions can be found here
Receivers
We utilized a logic app and a function app for the receivers.
Logic app
The implementation of the logic app in my solution follows a standard pattern, starting with defining the Terraform module implementation with appropriate parameterization. Let's begin by concentrating on the structure of the logic app. In order to successfully deploy the logic app, we require logic app module and its code. Resource implementation can be found in the receiver_logic_app.tf file
To create the logic app, two modules are required: the first one is for establishing a secure connection using managed identities to be able for fetching messages from a subscription - receiver_service_bus_connection.
The second one is for deploying the logic app resource along with its logic - receiver_logic_app. The logic app code is located in the directory specified as the value in the module_dir property.
Logic of the resource it is located as shown in the image below:
In this location there are two files present: workflow.bicep, which dynamically generates our final workflow with correct connections and parameters, and workflow_definition.json, which is the code that can be copied from the Azure portal when our logic app is ready to be redeployed following the IaC standards.
Simply copy the definition block after making any modifications in logic app designer, and parameterize the bicep file.
Back to the receiver_logic_app.tf file, arm_parameters section containing parameters that are passed to the workflow.bicep. This ensures proper parameterization of our logic app.
Function app
Deploying a function app involves a two-step process: the initial step is to deploy the code, followed by creating the essential resources. For the first step, it is crucial to compile and upload the executable code as an artifact in the pipelines. Build pipeline is located in the IaC/templates/build_function.yaml.
Once the initial step is completed and our code is deployed, we can proceed to develop the code within Terraform - receiver_function_app.tf. In this file we have to deal with couple steps, so lets discuss them.
Establishment of a storage container where we can deploy our package containing the code - storage_container_deployments.
Deployment of that package - function_app_storage_blob
App service plan creation. In this case we will use consumption tier which is Y1 - func_service_plan
Function app deployment. In this step we need to combine all our resources, like
service plan - service_plan_id,
resource group - resource_group_name,
storage account details - storage_account_name, storage_account_access_key
identity - it will be discussed withing next paragraph
Service bus details - configured as appSettings, enabling the parameterization of the function app code. To set up a service bus trigger at the topic subscription level, the required information includes the TopicName, SubscriptionName, and Connection details. As our function app is using User-Assigned Identity we need to provide 3 values ServiceBusConnection__fullyQualifiedNamespace, ServiceBusConnection__credential and ServiceBusConnection__clientID - which is id of user assigned managed identity:
Security
For security purposes, we utilize managed identities, there are two approaches implemented to address the issue: system-assigned identities are linked to the creating resource's lifecycle, while user-assigned identities can be utilized across multiple resources.
For the Sender logic app we used System-assigned option, and assigned Azure Service Bus Data Sender role on a topic level. For the receivers there was only one managed identity created and Azure Service Bus Data Receiver was assigned also on a topic level.
When dealing with user-assigned identities, it's important to keep in mind that when creating new resources, we must explicitly include the identity's ID.
Summary
Publish-Subscribe patter can be your friend for the whole career, either you use it with resources as provided in the article or any different way, there are many possibilities to with that. The core of that is of course topics and subscriptions, but it is always good to work on real world samples.
If you like the article share it! Ill be very glad
Comments