Building Secure API Platforms with Azure API Management

APIs are the backbone of modern applications. Mobile apps, web applications, partners, and internal systems all rely on APIs to exchange data and perform business operations. As the number of APIs grows, organizations need a way to secure, monitor, and manage them from a central location.

This is where Azure API Management (APIM) helps.

What is Azure API Management?

Azure API Management is a service that sits between API consumers and backend services. It acts as a gateway that receives API requests, applies security and management policies, and then forwards the requests to the backend systems.

Instead of exposing backend services directly to the internet, organizations can expose APIs through Azure API Management and apply consistent controls across all APIs.

Typical API Flow

A request usually follows this path:

Client Application → Azure API Management → Backend Service

The client could be:

• Mobile applications
• Web applications
• Business partners
• Internal applications
• Third-party services

The backend could be:

• Azure App Services
• Azure Functions
• AKS (Azure Kubernetes Service)
• Azure SQL Database
• Cosmos DB
• On-premises applications
• Legacy systems

Key Features of Azure API Management

Authentication and Authorization

One of the first requirements for any API is controlling who can access it.

Azure API Management supports:

• OAuth 2.0
• JWT token validation
• API keys
• Client certificates (mTLS)

This allows organizations to verify users and applications before granting access to APIs.

Network Security

Many organizations prefer to keep backend systems private.

Azure API Management supports:

• Virtual Networks (VNet)
• Private Endpoints
• IP allowlisting

These features help reduce exposure to the public internet and improve overall security.

Traffic Protection

Sometimes APIs receive too many requests, either intentionally or accidentally. Azure API Management provides controls to protect backend services.

Examples include:

• Rate limiting
• Quotas
• Request validation

For example, you can limit a client to 100 requests per minute, preventing a single consumer from overwhelming your systems.

Policy Management

Policies are one of the most useful features of Azure API Management.

Without changing application code, administrators can:

• Add or remove headers
• Rewrite URLs
• Validate tokens
• Transform responses
• Block requests from specific locations

This makes API management easier and more consistent.

Monitoring and Analytics

Understanding API usage is important for troubleshooting and planning.

Azure API Management integrates with:

• Azure Monitor
• Application Insights
• Log Analytics

These tools help track:

• Request volume
• Response times
• Failures
• Usage patterns

Teams can quickly identify issues before they impact users.

Developer Portal

Azure API Management includes a developer portal where developers can:

• Browse APIs
• Read documentation
• Test APIs
• Request access

This improves the developer experience and makes API onboarding easier.

Why Organizations Use Azure API Management

Many organizations adopt Azure API Management because it provides:

Better Security

Security policies can be managed in one place instead of being implemented separately in every application.

Improved Governance

Standards such as authentication, rate limiting, and logging can be applied consistently across all APIs.

Easier Management

Operations teams can manage multiple APIs from a single platform.

Better Scalability

As API usage grows, Azure API Management helps handle traffic efficiently.

Faster Development

Developers can focus on building business functionality while common concerns such as authentication and throttling are handled by APIM.

Best Practices

When using Azure API Management, consider the following practices:

• Use Microsoft Entra ID for authentication whenever possible.
• Enable JWT validation for protected APIs.
• Keep backend services private using Private Endpoints.
• Configure rate limits and quotas.
• Store secrets in Azure Key Vault.
• Enable monitoring and alerting.
• Version APIs properly.
• Regularly review security policies.

Conclusion

Azure API Management provides a central platform for securing, managing, and monitoring APIs. It helps organizations protect backend services, control access, manage traffic, and gain visibility into API usage.

Whether APIs are hosted in Azure, on-premises, or across multiple environments, Azure API Management makes it easier to build a secure and well-governed API platform that can scale with business needs.

A simple rule to remember: Keep backend services private, expose APIs through Azure API Management, and apply security and governance policies at the gateway. This approach creates a more secure and manageable API ecosystem.

Lessons Learned Migrating Legacy .NET Applications to Azure

Many organizations are under pressure to modernize aging .NET applications while minimizing business disruption. After leading and supporting several modernization initiatives, I've learned that cloud migration is rarely just a technology challenge. Success depends on architecture, security, governance, processes, and people.

Why Modernization Matters

Legacy applications often become difficult to maintain, expensive to scale, and slow to adapt to changing business needs. Azure offers opportunities to improve scalability, reliability, security, and deployment speed, but simply moving workloads to the cloud does not automatically deliver these benefits.

The goal should be modernization, not just migration.

Lesson 1: Avoid a "Lift and Shift" Mindset

One of the most common mistakes is treating Azure as another datacenter.

Moving applications to Azure Virtual Machines may reduce migration risk, but it often carries existing technical debt into the cloud.

Instead, consider:

• Azure App Services for web applications
• Azure SQL Managed Instance or Azure SQL Database
• Containerizing suitable workloads
• Azure Functions for background processing

Modernization should improve architecture, not just change where applications run.

Lesson 2: Start with Business Priorities

Not every application requires the same level of modernization.

Before selecting Azure services, ask:

• Which applications deliver the most business value?
• Which systems struggle with scalability?
• Which applications generate the highest operational costs?
• Which systems are most important to customers?

Prioritizing business outcomes often delivers greater value than focusing only on technical complexity.

Lesson 3: Design Security from the Beginning

Security should be part of the architecture from day one.

Key areas to consider include:

• Microsoft Entra ID integration
• Managed Identities
• Azure Key Vault
• Role-Based Access Control (RBAC)
• Network segmentation
• Private Endpoints

Building security in early is much easier than adding it later.

Lesson 4: Modernize Data Carefully

Applications are usually easier to migrate than data.

Common challenges include:

• Data quality issues
• Hidden dependencies
• Performance bottlenecks
• Limited migration windows

Successful teams invest in:

• Data profiling
• Performance testing
• Migration rehearsals
• Rollback planning

In many migrations, the database strategy determines overall success.

Lesson 5: Establish CI/CD Early

Cloud modernization and manual deployments do not work well together.

Before migrating critical workloads:

• Implement source control standards
• Build automated pipelines
• Automate infrastructure provisioning
• Define deployment approval processes

Azure DevOps and GitHub Actions can reduce deployment risk while improving delivery speed.

Lesson 6: Monitor Everything

Many organizations realize after migration that they lack visibility into application health and performance.

A strong Azure monitoring strategy should include:

• Application Insights
• Azure Monitor
• Log Analytics
• Distributed tracing
• Performance dashboards
• Proactive alerting

Observability should be treated as a core requirement, not an afterthought.

Lesson 7: Design for Failure

Cloud platforms are highly reliable, but failures still happen.

Applications should assume that:

• Services may become unavailable
• Network latency may increase
• Dependencies may fail unexpectedly

Design patterns such as:

• Retry policies
• Circuit breakers
• Queue-based processing
• Graceful degradation

help improve resiliency and user experience.

Lesson 8: Manage Costs from Day One

A common misconception is that cloud automatically lowers costs.

Without proper governance, costs can increase quickly.

Recommended practices include:

• Resource tagging standards
• Budget alerts
• Reserved Instances where appropriate
• Autoscaling strategies
• Regular cost reviews

Cost optimization should be an ongoing discipline.

Lesson 9: Organizational Change Matters

Technology alone does not guarantee success.

Successful modernization requires:

• Executive sponsorship
• Cross-functional collaboration
• Training and upskilling
• Updated operational processes
• Clear ownership and accountability

The most successful programs evolve people and processes alongside technology.

Lesson 10: Think Platform, Not Projects

Organizations gain the most value when they build reusable cloud foundations.

These foundations often include:

• Landing zones
• Security standards
• CI/CD templates
• Monitoring frameworks
• Governance policies

Investing in these capabilities once helps future migrations move faster and more consistently.

Final Thoughts

Migrating legacy .NET applications to Azure is more than a hosting decision. It is an opportunity to improve scalability, security, operational efficiency, and business agility.

The most successful modernization efforts balance technology, process, and people while staying focused on business outcomes.

Moving to Azure is just the beginning. The real value comes from improving architecture, security, operations, and the way teams work together.

SQL Server - Identify unused indexes

 In this blog, we learn about the index usage information (SYS.DM_DB_INDEX_USAGE_STATS) and analyze the index usage data (USER_SEEKS, USER_SCANS, USER_LOOKUPS, USER_UPDATES) and will identify the unused index.

Indexes help us in covering and enhancing the performance of a large number of queries that try to retrieve data from the database table and SQL Server allows us to create up to 999 Non-clustered indexes and one Clustered indexes per each table and there is a Meta data table SYS.INDEXESwhich contains one row per each index in table or view.

 

SQL server stores the index usage information in the system table and it provides SYS.DM_DB_INDEX_USAGE_STATSview to access the index usage statistics information so with help of index usage information we can identify the un-used index and will remove them easily.

 

there are few important columns (USER_SEEKS, USER_SCANS, USER_LOOKUPS, USER_UPDATES) in SYS.DM_DB_INDEX_USAGE_STATSthat help us to identify the bad or un-used index in table which are not being used in any query but in each update /insert operations , index data is getting updated.

 

·        USER_SEEKS - it stores the number of times the index is used to find a specific row.

·        USER_SCANS - it stores the number of times the leaf pages of the index are scanned.

·        USER_LOOKUPS - it stores the number of times a Clustered index is used by the Non-clustered index to fetch the full row .

·        USER_UPDATES - it stores the number of times the index data is modified

 

Here is a SQL query to pull the above information about the index.

 

SELECT OBJECT_NAME(S.[OBJECT_ID]) AS [OBJECT NAME],

       I.[NAME] AS [INDEX NAME],

       USER_SEEKS,

       USER_SCANS,

       USER_LOOKUPS,

       USER_UPDATES         

FROM  SYS.DM_DB_INDEX_USAGE_STATS AS S

       INNER JOIN SYS.INDEXES AS I ON I.[OBJECT_ID]= S.[OBJECT_ID] AND I.INDEX_ID = S.INDEX_ID

WHERE OBJECTPROPERTY(S.[OBJECT_ID],'IsUserTable')=1

      AND S.database_id=DB_ID()

      AND I.name='OrderOrderStatusDate_IDX'

 

Output:

 

As per output, the sql index “OrderOrderStatusDate_IDX” is not being used but index data is modified by 28046 times. 

SSRS : How to bold a row in RDLC report by conditionally

In this blog, we will learn how to change a row font to Bold in rdlc report on specific condition.

In daily summary leads report, I want to change total row font to Bold.

 

·        Select Data Row in RDLC report

·        In Property window,  expend the font property and select the FontWeight field, and select the Expression from list.

 

·        In Edit Expression window, use the data set field to create a conditional statement to change row font.

 

=IIf(Fields!Date.Value="Total","Bold","Default")

 

 

After changes, Total row in report is bold