---
title: "Building Cloud-Agnostic C# Applications - George Rios"
description: "Vendor lock-in is a business risk, not a technical inevitability. Here's how to build C# applications that run anywhere."
url: https://georgerios.com/articles/cloud-agnostic-csharp
author: George Rios
---

[ All articles](https://georgerios.com/articles)

Architecture

# Building Cloud-Agnostic C# Applications

Vendor lock-in is a business risk, not a technical inevitability. Here's how to build C# applications that run anywhere.

Published

2025-09-15

Reading time

3 min

Topic

Architecture

Author

George Rios

I've watched too many companies paint themselves into a corner with cloud-specific dependencies. What starts as "we'll just use Azure Functions" ends with a six-figure migration bill when the business decides to go multi-cloud or the CFO sees next quarter's Azure invoice.

The good news? Building cloud-agnostic C# applications isn't hard. It just requires thinking about abstractions upfront instead of after you're already locked in.

## The Myth of "We'll Never Leave \[Cloud Provider\]"

Every company thinks they'll stay with their initial cloud choice forever. Until:

- A merger forces consolidation onto a different cloud platform
- A major customer requires deployment in their preferred environment
- Pricing negotiations go south and leadership wants options
- Regulatory requirements demand on-premise or specific geographic hosting

I've seen all of these scenarios. The companies that built cloud-agnostic from day one handled them with minimal disruption. The others? Rewrites, scrambles, and budget overruns.

## Three Principles for Cloud-Agnostic C# Architecture

### 1\. Abstract Storage and Messaging

Never call Azure Storage, AWS S3, or GCP Cloud Storage APIs directly from your business logic. Instead, define interfaces:

```
public interface IBlobStorage
{
    Task<string> UploadAsync(string key, Stream content);
    Task<Stream> DownloadAsync(string key);
    Task DeleteAsync(string key);
}

public interface IMessageQueue
{
    Task PublishAsync<T>(T message);
    Task<IEnumerable<T>> ReceiveAsync<T>(int maxMessages);
}
```

Then implement these interfaces for each cloud provider. Your business logic stays clean and portable. Switching clouds becomes a configuration change, not a code rewrite.

### 2\. Use Standard Protocols, Not Proprietary Services

Where possible, prefer standardized technologies over cloud-specific services:

- **Instead of:** Azure Service Bus → **Use:** RabbitMQ or Kafka
- **Instead of:** AWS Lambda → **Use:** Containerized services with standard HTTP endpoints
- **Instead of:** Azure Cosmos DB proprietary APIs → **Use:** MongoDB protocol or SQL

Yes, you might give up some cloud-native bells and whistles. But you gain portability and negotiating leverage.

### 3\. Containerize Everything

Docker containers run everywhere. Once your application is containerized, it can run on:

- Azure Container Apps
- AWS ECS or EKS
- Google Cloud Run or GKE
- Your own Kubernetes cluster
- An on-premise server

This is the single most important decision for cloud agnosticism. If your app runs in a container with environment-based configuration, you can deploy it anywhere.

## The Noundry Approach

This is exactly why I built Noundry with cloud agnosticism as a core principle. The platform includes:

- Pre-built abstractions for storage, messaging, caching, and secrets management
- Provider implementations for Azure, AWS, GCP, and on-premise
- Configuration-driven provider selection (change one line, deploy to a different cloud)
- Container-first architecture with Docker and Kubernetes support out of the box

Teams using Noundry can build once and deploy anywhere, without thinking about it.

## When to Accept Cloud-Specific Dependencies

I'm pragmatic, not dogmatic. Sometimes using a cloud-specific service makes sense:

- Your company has a long-term strategic commitment to one cloud provider
- The cloud-specific service provides unique value you can't replicate elsewhere (rare, but it happens)
- The cost of abstraction exceeds the risk of lock-in (more common in early-stage startups)

But make these decisions consciously, not by accident. And even then, isolate cloud-specific code behind interfaces so you can swap implementations if needed.

## The Bottom Line

Building cloud-agnostic C# applications isn't about avoiding the cloud. It's about maintaining optionality. The companies that do this well:

- Negotiate better pricing (vendors know you can leave)
- Handle M&A scenarios smoothly
- Meet customer requirements for specific deployment environments
- Avoid expensive migration projects

The upfront investment in abstraction is minimal. The long-term payoff is significant.

_Want help building cloud-agnostic C# applications? I offer [consulting services](https://georgerios.com/cto) for architecture design and cloud migration. Or check out the [Noundry platform](https://georgerios.com/about#noundry) for a ready-made solution._

## References

[ Back to articles](https://georgerios.com/articles) [Book a call ](https://cal.com/georgerios/30min)

---

Contact: george@georgerios.com · Book a call: https://cal.com/georgerios/30min · Services summary for agents: https://georgerios.com/llms.txt