Question

platform: ASP.NET 4.5, MVC 4, C#

I’m currently designing a website that’s available on the public domain. However, there is a meaningful % of my target market that would be uncomfortable putting some information on a public site, even if it’s https etc.

What I’d like to be able to do is allow corporate users use my site, and one way to do that is to allow them to host my website on their intranet. The usual disadvantages are, of course, that they don’t get their site updated as fast as the public one would, and it’s also a headache for me in terms of support.

My questions are

1. What are some strategies to make “corporate friendly” deployments easy and hassle-free?

2. Are there ways I could keep the site public with just the database inside the intranet (can’t see how… but then I’m no techno-know-all)

3. If I have no choice but to make it locally hosted – then what’s the best way to do it to keep my development/support overheads at a minimum?

I hope the mods don’t lock this. I’m asking for specific methods and technical approaches to a very real problem.

Thank you,

Answer 1

For #1, there’s a many facets to the question. A couple thoughts that might help you think it out:

1. Deploying your app: Make it simple to deploy, and to upgrade, between versions of your application. Try to make it happen as a single operation, not upgrading different parts by hand manually. As Darin Dimitrov mentioned, you could look into a technology like Web Deployment Packages, especially with Visual Studio 2012 which will have incremental database publishing (in VS2010, the database was non-incremental so there wasn’t really an “update” story). Keep the cost of deployment down so that they can afford to upgrade more frequently (not the cost of your product, but the overhead of who’s getting paid to keep the system updated and running).
2. Consider differences between running on the Internet and on an Intranet: For example, authentication on the Internet is usually done with forms based authentication. On an intranet, you may want to consider supporting Windows authentication for a seamless login experience for corporate users. This should impact your designs to allow authentication to be modular between your deployments.
3. Corporate adoption of newer technologies might be slower than you want: You’re using the latest and greatest (ASP.NET 4.5/MVC4). Some companies might not be prepared to deploy this now, or for a couple years. Consider if you could use an older, established technology, such as .NET 4 – having been out for a few years, it’s already somewhat proven and has adoption.

For your 2nd question, it comes down to what their IT is willing to accommodate. Many corporate sites have the database within a secured LAN, but the web server is accessible from the public Internet. It’s certainly a well-understood network design, but depending on the assets involved in your application, your customers may or may not agree to it. This one’s a business decision.

For #3 the answer is common to any long term software project. It has to be high quality and maintainable if you want to minimize the hassle.

• If you’re only going to support the last N versions, make that very clear. Avoid supporting code that you’re already fixed long in the past. Consider providing extra support or affordable upgrades to keep your customers on newer (and hopefully better) releases.
• Keep in mind what components need to be upgraded between versions. Your web app (obviously), but also your database schema and any dependencies or libraries you’re using. This is mostly the same considerations as #1. Make sure you have a good plan for upgrades and rollbacks.
• Most importantly, test, test, test. Have functional regression tests and install/upgrade tests, and try out as many possibilities as you can think of.