The sweet spot for the Microsoft stack is one beefy server. While you can rent that from a cloud provider, you're just plain always going to get a better deal by building your own box and dropping it in a datacenter.
It's not anywhere near as daunting as it seems to do so, and it will run you about $400/month all in, amortized out over a 3 year box lifetime even including licenses.
That'll get you the firepower of a medium sized cluster of Linux gear running your open source stack of choice, without having to deal with a dozen virtual machines spinning up and down to deal with load. It'll just handle as much traffic as you can throw at it, up to the point where you're big enough to simply pull a half dozen of your hundred devs off what they're doing to help scale you up.
That's probably the reason you don't see many .net paas companies around. For the most part, they're not the right tool for the job.
With something like EC2, you just spin up a similar box with newer patches applied, redeploy your application, load-balance between your versions and just delete the old one when you are happy.
I cannot imagine going back to colo. Or even physical boxes. If I were forced to have a physical box, the first thing I'd do would be to deploy everything on virtual machines or containers inside it.
It would have been nice if it was compiled in to a larger comparison table so I could see it all on my widescreen display, but an interesting read nonetheless.
You can even experiment with the new OWIN/Katana stuff if you like: http://friism.com/running-owin-katana-apps-on-heroku
What surprises me more as an appharbor customer though, is that you've moved to Heroku! I must have missed that news...
Personally I run everything on a VPS, because I'm not worried about scale. If I was running something larger I'd probably go with Azure.
Very nice list, i was not aware of many of these solutions. I have used Azure for my private sites before, and it is a really nice solution.
Scott Hanselman wrote an interesting article, comparing Azure Web Sites to your $5/Month Host. Read it here: http://www.hanselman.com/blog/PennyPinchingInTheCloudWhenDoA...
I know TFS offers a lot of the benefits we were looking for, but we were committed to git. (This was before they added git support in TFS) We were also burned by a lot of bad MS versions of things in the past, so were weren't eager to dip our toes into TFS.
Our Git/TeamCity/MSBuild-based build server rebuilds/upgrades the database (SQL Server), builds a web app, and a ClickOnce desktop app installer package. Everything is then copied to the target web site. At the end of each build we have a fully functional web app + downloadable desktop app (the desktop app also auto-updates if it's already running somewhere).
We use NUnit to develop unit tests, but TeamCity has it's own NUnit runner that nicely reports unit test stats and any failures.
Production deployment is slightly different - the build box pushes everything to git, and production boxes pull the latest version from git.
I did have to copy a couple of directories from Visual Studio to the build box. I guess that's the dependency everyone is talking about. I ended up with just copying a couple of things (and documenting them somewhere) rather than installing the entire Visual Studio.
One thing I didn't get to is automating C++ builds on the build box. We have some C++ dependencies. Fortunately, those almost never change, so we build them manually, commit binaries to git, and the build process picks them up from there.
All in all, it was a pretty good experience. I didn't even have to use PowerShell that much. Ordinary cmd-scripts were sufficient for most tasks. The git command line interface is quite rich, even though it can be confusing at times (but stackoverflow typically has the answers).
If you're interested in any specific items, feel free to email me.
I'm a huge believer in this kind of automation. We make extensive use of TeamCity to drive it. In addition to builds, automated tests, and deployments, we also use it for release promotion and doing other housekeeping tasks like cleaning up data from QA environments, restoring testing databases, etc.
We did have to take an outage for breaking schema changes. Publish to Staging slot stopped, stop the Prod slot, upgrade the database, start Staging, swap the VIP. Total outage was as long as it took to start the VM, a minute or two. We used code-first database with NHibernate.
TortoiseHg, in especially the latter versions where the interface is unified into one big dialog, the workflow is exceptional. Everything I needed was at my fingertips at all times.
I've since drank the git koolaid after being forced to at work but after the introduction of git-flow I'll find it very hard to switch again. I know hg-flow exists but again due to Hg's awkward command-line or specifically how it is in the TortoiseHg window I would likely need a significant workflow boost to switch. Though it would be a good exercise to try to take a lot of how I work now and see how much I can bend TortoiseHg to that.
TortoiseGit specifically has a few holes where no UI exists and you have to use the command line but those are very infrequent. TortoiseHg and Hg in general seems way more user friendly to me but Git is definitely more powerful as you have access to all the knobs to completely trash a repository easily.
MS does a lot of things right - C# is a fantastic language. Imho, the biggest problem with MS is the lack of the normal darwinean processes that you see out in the bazaar of open-source. MS products survive because they're tied to other MS products, so complete turds live on in spite of constant user frustration because the entire MS universe, as a whole, is good enough to keep using. But the pain points never go away, or get completely re-written by the same people with the same flaws but a whole new two-day process of learning how this new version works.
It is not needed to build web apps. My current company (a .NET web shop) has a strict rule of "no VS on the build server". I know that it's needed to build some things, like unit tests that use MSTest, the built-in Visual Studio Setup Projects, but not plain ASP.NET or ASP.NET MVC websites.
VS and build servers is generally considered to be a licensing issue. But if you don't have a web app, well, you still need to build it.
We have a C++ application that uses MFC. VS is required, but not anything more than VS Express (the free edition).
"But VS Express doesn't have MFC!"
Behold: License Extensions for Visual Studio 2012 and Visual Studio 2012 SDK !
> If you have a validly licensed copy of such software, you may copy and distribute the unmodified object code form of the files listed below, subject to the software's License Terms and to the additional terms or conditions (if any) that are indicated. ...
> BuildServer Files for Visual Studio 2012 Ultimate, Premium and Professional editions: ...
> All files from the following folders (and all files and folders contained within these folders, recursively) ...
> Program Files\Microsoft Visual Studio 11.0\VC\
The atlmfc folder is contained within VC. So you can install VS Express on your build server and build virtually anything with it, just copy the appropriate files.
> I know that it's needed to build some things, like unit tests that use MSTest
I am fairly sure you can do all things MSTest once you've installed the client test bits .
It can be a pain to set up large, existing projects, and I'm yet to get my SQL changes working correctly using it, but it's definitely the right way to go about it.
This has changed my life.
We now run the free version of Team City on our QA-server, so it builds our ClickOnce Deployments and uploads them and it also builds our MVC4 projects and deploys them. I'm quite happy with how it works.
My main job is at a MS/.NET shop, so for my personal projects I'm mostly using MVC 3 and PostgreSQL deploying to Mono.
Probably not good for large installations who want vendor support, but it works.
VPS: AppliedI (http://www.appliedi.net) or UltimaSystems (http://www.ultimasystems.net)
Cloud: Azure or AWS (or even DigitalOcean or Linode if possible to run under Mono)
Dedicated: ReliableSite (http://www.reliablesite.net) or OVH Canada (http://www.ovh.com/us/) or Hivelocity (https://hivelocity.net)