Earlier this week Laure showed me an awesome SDK that provides context aware, pluggable and customizable data protection and anonymization for text and images. Which is called ; Presidio! Where this has proven to be very useful for a use case we were working on. In today’s post, we’ll take a look how you can leverage both App Service and Logic Apps to build your own demo with Presidio. Though if you want to test things straight away, do check the demo website as maintained by the Presidio team themselves ; https://presidio-demo.azurewebsites.net/.
What does it do?
In essence, there are two steps involved ;
Analyzing ; Where an NLP trained model will go look for sensitive data and provide a list of locations where it found those.
Anonymization ; Where the list of locations is then used to filter out / mask sensitive information.
To get to a result where you can ensure that sensitive data like credit card numbers, locations, names, SSN numbers, bitcoin wallets, phone numbers, financial data, etc can be kept confidential. Which you can see on the following example.
Earlier this week I published the following repository ; https://github.com/beluxappdev/demo-arc-appservice. Which basically contains all the needed steps (via Azure CLI) to create an environment that showcases how Azure AppService and Azure Arc work together. For today’s blog post, I would like to take you on the journey from a “consumer” of this App Service Environment (running on any Kubernetes distribution, managed via Arc) to deploy a Webapp onto it. Where we can then see how the it is currently looking in the preview!
The project needs to increase velocity and a new developer arrives in the team. Now is typically the time where all chaos begins, as this person needs to be onboarded with the full toolchain linked to the project. Sound familiar? It does to me at least. Which is one of the reasons why I love CodeSpaces! Here you can have a development environment for VS Code full configured, which can then be leveraged in a cloud hosted manner. Even with having a secure connection to your locally installed VS Code. Sounds too good to be true? Let us take a look at the step-by-step experience of onboarding a new developer!
In today’s post, we’ll be using some resources to get us started…
A very common discussion to have with enterprises around Azure API Management (“APIM”) is the aspect of network integration. At the end of the day, the response to that is very simple… Only the developer & premium SKU allow VNET integration. The integration is achieved by doing “injection”, which means that the service is “dedicated” to you and “the machines” are placed directly in your VNET. Azure APIM does not leverage private link (yet?)… Which then opens the next discussion, as the premium SKU is about 3,42 Euro per hour, where the basic SKU floats at about 20 Eurocent per hour. At this point, for most organizations, the cost impact will take priority over the most optimal design. Where today’s post will take a look at the various options at hand.
Update (March 2022)
Since the initial post, the ability to leverage private endpoints have been made available ; https://docs.microsoft.com/en-us/azure/api-management/private-endpoint. This concept will probably be more interesting to you than the approaches mentioned in this post!
Flavors / Tiers
When taking a look at the pricing info, you will notice there are multiple flavors you can choose from ;
The consumption tier is the one where you are charged for the amount of calls you make. It is an awesome model in terms of linking your business outcome to the cost model at hand. The downside is, that is does not offer a developer portal or any typical enterprise features (like VNET integration or a self-hosted gateway).
The basic and standard tiers are economic tiers at both about 45 and 130 Euros per month. They do include a developer portal.
The developer and premium tiers are the ones typically picked by enterprises due to their VNET integration, HA/DR options (for Premium) and the self-hosted gateway.
The objective behind today’s post, is to serve as an overview for all those who want to learn more on Visual Studio Licensing. In my role as a Specialist in the field, I have gotten a wide range of questions on the subject. These range from license specific exceptions, towards benefits and ending up in full range license optimization exercises.
Visual Studio Editions
In terms of Visual Studio, there are currently four editions used ;
Visual Studio Code
Visual Studio Community
Visual Studio Professional
Visual Studio Enterprise
Where Visual Studio Code and Visual Studio Community are free, they do differ quite from the others. Where we will go into the detail of those in more detail individually. To get a full feature comparison between Community, Professional & Enterprise, do check out this page ; https://visualstudio.microsoft.com/vs/compare/
A common discussion I have had in my role is around the “billing structure” of Azure DevOps. Though the discussion typically spreads out to other topics like identity and service connections for deployment. In today’s post, we’ll go over the general governance structure behind Azure DevOps.
High Level Structure
For this, let us start with a complex drawing! 😉
As a bit of an introduction ;
Azure Active Directory is a component used for identity on both the Azure DevOps side (organization level), Azure Subscription and on the contract level for Role Based Access Control (RBAC).
Azure DevOps has the concept of an organization, which can hold multiple projects. The billing & identity part reside on organizational level (marked in red). Where the service connections for deployment (pipelines) resides on project level (marked in green).
There can only be one AAD linked to an Azure DevOps subscription. Though you can invite users from another AAD tenant via a typical B2B invite. Thus granting access to users outside of the AAD tenant linked to that organization.
There can only be one Azure subscription linked for billing. Though you can have multiple Azure subscriptions linked as service connections for deployment.
Multiple Azure DevOps organizations can use the same Azure subscription for billing. This will even allow the scenario of multi org billing.
So far for the basics… Let us now delve deeper into various topics.
Long story short… I have a heat pump that I can control via an app. At the end of the day, there is no official documentation on how I can directly (without the app) communicate to my heat pump. So I embarked on a journey to reverse engineer the API connectivity and see how I could tweak this. For those curious, my end goal I have in mind is to align the heat pump to the production of my solar installation. Or just call me a technical nutcase, that also works. 😉
For today’s post, I will show you how you can combine the native proxy function of your iOS device to route to Postman. Where you can then start tracing the API calls made by a native mobile application. Makes sense so far? Cool! Let’s get to it!
If we go several years back, I already leveraged the instant scaling of CosmosDB… Recently a new plan has been introduced to cover this behavior, being the Consumption Based / Serverless option! For a new project I immediately started using this one, and I am very happy about it. Where I came to a point where I said to myself, let us migrate the other databases (where fit) to this option too. For today’s post, I will go into the differences I noticed… and hopefully save you some time looking up things. 😉 Though be aware that I have been leveraging the MongoDB API/endpoint.
A while back Mike was telling me he discovered “Clarity” existed and that I should REALLY take a look at it. I remember in initially was a it sceptic also thinking about where the potential overlap was with “Application Insights“.
As I have been working on a new project, I decided to take it for a test spin, and I must say I am impressed! Clarity is a simple and free service that allows you to see what your users are seeing. Plain “simple”… nothing more, nothing less. It will provide you insights on the usage, heatmaps of your web app and session recordings of users going through your web app. Which will help like a lot when you want to refine your user experience!
Quick skim through the service
Once signed up you are prompted to create a new project ;
For today’s post we’ll go through a simple (yet powerful!) example that shows you how to securely communicate between two LogicApps. For this we will leverage the concept of managed system identity on the sender and access token validation on the receiver.
To get a bit of an idea of the flow, let us take a look at the drawing below…
The sender (LogicApp on the top left) is foreseen of a Managed System Identity in AAD. It will leverage this capability to get an access token from AAD. In addition, we will include a specific audience in the scope. This refers to an application object inside of the AAD tenant. This token will then be included in the authorization header (as a JWT token) towards the receiver (LogicApp on the top right). The receiver will validate the JWT token by checking the public keys of the issues (AAD). Next up, it will check if the Issuer and Audience provided match the defined policy. If all is okay, then it will accept the request.