Gopakumar gopkumr

Introduction Azure Application Gateway provides a powerful solution for load balancing, SSL termination, and URL-based routing. In this blog post, we will discuss a common scenario where we need to forward traffic to two different Azure API Management instances based on the incoming URL, distinguishing between non-production and production environments. Problem Statement Consider a scenario where you have two separate instances of Azure API Management (Sku: any non consumption tier): one for non-production/testing (nonprod) and the other for production (prod).

Context While most of the application integration patterns are moving towards real-time, near-real-time and stream based solutions, there are still requirement to have batch file based data movement. These requirements are often for reporting or data warehousing scenario or while integrating with a legacy system. While there are many products that help setup SFTP server, Azure was missing a SaaS offering for hosted SFTP server, like Amazon’s AWS Transfer on top of S3.

Introduction APIs have become so popular that almost all websites and applications rely on APIs to get data from server. Often user impersonation is used to authenticate as well as authorize access to the resource exposed by an API, but there are also use cases where application itself needs data from an API for functioning. Currently the most used authentication mechanism is OAuth, where identity management is performed by a third provider and both the client and resource server trusts this identity provider.

Recently I had a requirement to make a copy of a Function App from the production version to support a POC implementation of an solution upgrade. One option was to deploy the Release branch which had the version same as in PROD (we already made updates to that function app post release, so DEV was already a lot of commits ahead). The challenge with this approach was, since we did not had a hotfix release, there were no Pipelines setup for Release branch.

What are APIM Policies? APIM policies are statements executed by Azure APIM to modify the behavior of API request, response and exception flows. The logic/conditions written as part of the policies are executed at various stages of API execution like, request received (inbound), before request sent to backend service/API (backend), before sending response to requester (outbound) and in case of any exceptions during the request processing (on-error). Policies are defined as an XML format with different tag to define the execution stage and the actual policy.

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.

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.

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.

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).

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.