Azure

Problem While working with Azure cloud platform, often there will be instances where resources needs moving across resource groups for maintenance reasons or because of re-organising of products. There might even cases where the resource may need to be moved across subscriptions. Solution In Azure resources can be moved across resource groups from the portal UI or Azure CLI or powershell or from the rest APIs. Moving the resource using the portal UI is as easy as going through a wizard like steps and clicking finish at the end of it. The process also validates if the resource can be moved or not, for example an Azure SQL Database cannot be moved without moving the SQL Server instance, and when a SQL Server instance is moved across, all the databases gets moved automatically. ...

Problem The project has a bunch of ARM templates as part of IAC scripts and more often only couple, if not few templates get modified. But when deploying using Azure pipeline all the templates gets deployed. Even though ARM template deployment support incremental mode, if a templates is deployed with exact same properties, the resource gets recreated. The project does not want to recreate all the templates when only a few are changed. Currently there is no out-of-the-box tasks that support this behavior (or I could not find any). Deployment Mode Reference ...

Introduction Continuing from the previous post, the new generation of authentication mechanism was created to satisfy the new generation of application, starting from apps that run just in the browser to apps that run on micro-controllers. This new generation of authentication mechanism called as the modern authentication protocols are built on top of the OAuth protocol and taking inspiration from SAML. In the below article the term IDP refers to the Identity provider, the external service that is responsible for authenticating a user and issuing authorization tokens. This service is both trusted by the client app as well as the resource api. ...

Introduction Authentication has been an important component in the world of IT from the time companies required their employees to prove their identity to use the company’s computing resources whether it was to execute its business processes or accessing email or file. During the earlier days employees used to login to their computers using a username and password, which was stored in a central server like an active directory (in case of Microsoft tech stack). With the active directory credentials employees where able to use to login to both their windows computers as well as the email application both of which were in the same network. This approach worked well for many years until the softwares and services that the companies used where no longer within their network. While active directory protocols like NTLM or Kerberos could work across external networks via technologies like VPN it was complex to setup and maintain such an infrastructure while keeping all the connection secure and stable. Also with growing number of users/services and the pace at which the growth occurred, these technologies were not designed to scale at that pace. Hence new Authentication mechanisms were needed. ...

I recently came across the site https://cloudresumechallenge.dev/ and decided to give it a try using Azure services. To start simple I decided to ignore the DB, CDN part etc and just have the the UI and the middler layer of the app. Below is the high level architecture. The front end of the app will be hosted a static web site in Azure Blob storage. Backend will be an Azure function that will feed the resume data to the frontend over HTTP, the azure function will be a HTTP triggered function. Currently the resume data in JSON format hardcoded in the Azure Function code. As an upgrade to the app, the JSON data can be moved to a CosmosDB instance and put an Azure CDN in front of the UI to deliver content fast to users. ...

This is a continuation from the previous article on feature flags implemented using Azure App configuration service to maintain the flags. Just to reiterate, feature management can be implemented using config files but this article is trying to implement feature flags connecting to Azure App configuration service. Introduction The previous article described about implementing a boolean feature flag to turn on/off a feature. In this article I am trying to implement a custom feature flag. Microsoft provides few predefined custom feature flags or feature filters (as they are called) Targeting, TimeWindow, and Percentage (more about it here), which covers most usecases, however, there might be situations where you find the predefined ones falling short. In this article I am building a filter ground up with a made up custom logic. ...

Feature flag is a very popular practice in modern application development, which is used to specifically hide features implemented that are not yet ready to be used by wider audience, and when ready can be enabled by a flip of a switch. The flags can also be used as a kill switch for application feature when it not working as expected. With feature flags implemented, it would be effective to have the features enabled or disabled from a location outside of the application infrastructure or configuration, this way we can have features spanning across applications be controlled via a centralized flag. Azure has feature management as part of the Azure App configuration service which can manage feature flags and maintain it separate from your hosting model and will act as a centralized repository for feature flags. Microsoft also provides libraries for different programing languages to consume Azure App Configuration service. More about it can be found here ...