We use Azure API Management quite extensively at our clients, where we use this service whenever our services (APIs) go across application boundaries. Basically, API Management implements a facade in front of all our services. Any consumer, whether they are internal or external, uses this gateway to communicate with our services.
When we look at the messaging space on Azure, we have a wide variety of options, each with it’s own strengths and weaknesses. For example, we have Event Hubs, which provides capabilities for processing large amounts of data streams, Service Bus for enterprise messaging, and Event Grid for reactive eventing.
In this blog post, we will look into the the Publish – Subscribe pattern, and how we could implement this using Azure services. For this scenario, we receive messages from one or multiple sources, which we need to route to one or more subscribers, based on properties or content. Of the different messaging offerings, two of these jump out for this scenario, Service Bus and Event Grid. Let’s have a look at when to use which, and the reasons behind these decisions.
Continue readingWhen working with Azure, we should always put our secrets into a secure store, such as Key Vault. This ensures that we can limit who can see the values of our secrets, while still being able to work with them. How we work with these secrets is different over the various services, and in this article we will focus on Logic Apps, while other services will be explained in their own posts later on.
In Logic Apps we often will need some sort of secret, for example a subscription key for API Management, or a SAS key for Event Grid. In the scenario for this blog post we are going to send our secret to a RequestBin endpoint, so we can see that we indeed get the correct value.
We use Key Vault extensively in our solutions, to store any secrets we might need. For example in an API through code, in Azure Functions via the application settings, or in a Logic App through a REST call. If you go to your secrets in Key Vault, you will notice that the link to the secret includes a version number, in the format of https://kv-we-retrieve-kv-secret.vault.azure.net/secrets/MySecretValue/80df3e46ffcd4f1cb187f79905e9a1e8.
Of course, this is great if we want to reference a specific version of a secret. However, often we will just want to reference the latest version, so we stay up to date even when the secret has been changed, for example because it is a rotating password.
It turns out, this is very easy, without the need to update the version number in all our applications whenever a new version is created. This is done by just omitting the version number from our link! So the will instead look like https://kv-we-retrieve-kv-secret.vault.azure.net/secrets/MySecretValue/.
Important to notice is the trailing slash ( / ), which needs to be included, otherwise you will just get a 404 error.
Being a big fan of the Infrastructure as Code (IaC) paradigm, I create all my Azure resources as Azure Resource Manager (ARM) templates. Using an IaC approach, our Azure environments are described as code, allowing us to deploy services in an automated and consistent manner. Often different resources reference other resources, which can introduce the need for authentication. Sometimes we can use Azure Active Directory identities for this (explained more detailed in a later post), however at other times this may require some other form of secrets to set up communication.
Of course, we could create a resource, get the secrets out manually, and then pass them into the referencing resource’s template. However, the idea of Infrastructure as Code, especially when combined with a CI/CD strategy, is to have a minimal amount of manual steps. So instead, let’s have a look at how we can retrieve these secrets from our ARM templates. Consequently, this allows us to set these secrets at deployment time, without any manual interference needed. This article is the first in a series of blog posts, each focusing on a different service, starting with Azure Storage access keys in this post.
This is the fifth and final post in my series around setting up CI/CD for Azure API Management using Azure Resource Manager templates. We already created our API Management instance, added products, users and groups to the instance, and created unversioned and versioned APIs. In this final post, we will see how we can use linked ARM templates in combination with VSTS to deploy our solution all at once, and how this allows us to re-use existing templates to build up our API Management.
The posts in this series are the following, this list will be updated as the posts are being published.
This is the fourth post in my series around setting up CI/CD for Azure API Management using Azure Resource Manager templates. So far we have created our API Management instance, added the products, users and groups for Contoso, and created an unversioned API. In this post we will create an versioned API, allowing us to run multiple versions of an API side by side.
The posts in this series are the following, this list will be updated as the posts are being published.
This is the thirth post in my series around setting up CI/CD for Azure API Management using Azure Resource Manager templates. In the first post we created our API Management instance, and have set up our build and release pipelines, while in the second post we added the products, users and groups for Contoso. In this post we will create an unversioned API , and expose it through the product from the previous post.
The posts in this series are the following, this list will be updated as the posts are being published.
Last week Microsoft announced during Build that they are now supporting the Kafka protocol 1.0 and onward on Azure Event Hubs. This allows us to connect our Kafka clients, which can be either producers or consumers, to Event Hubs and take advantage of all features which Event Hubs gives us, like easy integration to Azure services including Stream Analytics, Functions and Logic Apps, use Capture and auto-inflate, and tie into Azure core features like MSI, RBAC and Virtual Networks.
This is the second post in my series around setting up CI/CD for Azure API Management using Azure Resource Manager templates. In the previous post we created our API Management instance, and have set up our build and release pipelines. In this post we will add custom products, users and groups to our API Management instance, which will be used to set up our policies and access to our APIs.
The posts in this series are the following, this list will be updated as the posts are being published.
