Question

Is there are an architecture versatile enough that it may be deployed to either a cloud server or to a dedicated (or VPS) server with minimal change? Obviously there would be config changes but I’d rather leave the rest of the app consistent, keeping one maintainable codebase.

The app would be ASP.NET &/or ASP.MVC. My dev environment is VS 2010. The cloud may, or may not be, Azure. Dedicated or VPS would be Win Server 2008. Probably.

It is not a public-facing web site. The web app I have in mind would be a separate deployment for each client. Some clients would be small-scale, some will prefer the app to run on a local intranet rather than on the web. Other clients may prefer the cloud approach for a black-box solution. The app may run for a few hours or it may run indefinitely, it depends on the client and the project. Other than deployment scenarios the apps would be more or less identical.

As you may see from the tags, I’m assuming a message-based architecture is probably the most versatile but I’m also used to being wrong about this stuff.

All suggestions and pointers welcome regarding general architectures and also specific solutions.

Answer 1

Yes, this is possible. The web app istelf (MVC or Webforms) will likely remain the same (with config changes).

If you are considering Windows Azure as the “cloud” deployment option then the major things to take into account are:

Web app:

• Session management: you will have to use a web farm friendly approach (e.g. cannot use in-memory server side session state)
• Bandwidth use: when you deploy to the cloud, latencies are higher than 100% on-premises, you also pay more for more bits you send back and forth. There’s an $ incentive for building more frugal apps.
• Authentication mechanism: if you want to offer SSO you probably need to move to claims based approach (using WIF). This is largely something you can isolate and change (e.g. Windows integrated security on-premises, claims based on the cloud)
• Use all standard providers (e.g. profile, membership, tracing, etc). There are Win Azure implementations of all, so you can just change them.

Data:

• The simplest approach for maximum portability is to use SQL Azure which is a (big) subset of SQL Server.
• If you use another storage system (e.g. Windows Azure tables, etc), then you need to abstract all data access in the app (much harder work)
• Besides some features not available in SQL Azure (like SQLCLR, SQL Broker) there are limits to the database size (max = 50GB currently). So, if your customer’s databases grown beyond that, you need to partition the db (which adds more complexity, but it is doable)

Management:

• If you use standard methods for logging and tracing (e.g. Systems.Diagnostics,etc) the app will remain largely the same. Your processes will have to be adapted (and your scripts, etc)

Much more details are available here.

I don’t know what you were trying to considering the message queues for, but that’s something you can also abstract (e.g. MSMQ for on-premises, Windows Azure Queue for the cloud). You will have to accomodate for some semantic differences, but it is doable.