Where to host .NET applications?(seroter.wordpress.com)
seroter.wordpress.com
Where to host .NET applications?
http://seroter.wordpress.com/2013/08/16/where-the-heck-do-i-host-my-net-app/
11 comments
Some people just don't want to deal with colo. I know I'm sick of it. I enjoy mucking around with the stuff and spending the company money of course but when shit hits the fan it's pretty annoying. Same could be said for cloud of course. Currently dealing with a random NIC lockup on a VCloud hosted SQL Server for a client. I feel hosting issues are inescapable regardless of where you go.
That's a good solution, until you need to do a major upgrade, or when you need to hire additional capacity for a temporary spike (say a campaign). It's only a solution if you are OK with occasional downtime - because you'll need to stop everything to apply service packs.
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.
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.
If you're willing to spend the cash, 3 servers can offer you a hot failover with a spare staging server. Of course with just 3 servers, you would have to accept failing over to a different version while you update the 2nd server.
Yeah, it's a cost vs. peace of mind equation. I've done both colo and managed, and in my case, having someone (e.g Rackspace) manage the ecosystem is worth the added cost.
Interesting list. Though I didn't see much consideration to Mono on Linux, which is my personal deployment strategy.
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.
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.
I've been trying for weeks to get a Mono environment that will host an MVC4 application (minus async/await). Any suggestions?
I've got a buildpack working for running ASP.NET apps (including MVC, and also straight-up .NET apps) on Heroku, running on Mono and Linux: http://friism.com/running-net-on-heroku
You can even experiment with the new OWIN/Katana stuff if you like: http://friism.com/running-owin-katana-apps-on-heroku
You can even experiment with the new OWIN/Katana stuff if you like: http://friism.com/running-owin-katana-apps-on-heroku
That's really cool.
What surprises me more as an appharbor customer though, is that you've moved to Heroku! I must have missed that news...
What surprises me more as an appharbor customer though, is that you've moved to Heroku! I must have missed that news...
I haven't tried MVC4 yet, I was waiting for async support in Mono.
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.
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.
Async support is available in Mono since Mono 3.0: http://www.mono-project.com/Release_Notes_Mono_3.0 (ctrl-f for "async")
Did you try with Digital Ocean ?
can't do Select Into in Azure.
So run SQL Server in a VM. Or MySQL. Or PostreSQL. Or whatever.
Even with the new dedicated Azure SQL Always-On instances?
i'll check.
After some googling and stackoverflowing and msdning, I think any version of SQL on azure does _not_ support "select into".
I also found a request to have that added, and in January of 2013, it was closed as "won't do". ( see https://connect.microsoft.com/SQLServer/feedback/details/776... )
Have you seen this? http://blog.erikd.org/2013/03/17/run-asp-dot-net-mvc4-on-ubu...
Happy to see some .NET posts on here! Also, comments that doesn't include bashing over the evil M$ and how they will rip your startup apart.
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...
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've been using appharbor for a long time and I've been very happy. The recent additions of spdy and web sockets is really great....they've been very active in integrating with other providers. It is pretty shocking how easy it is to spin up a $10/month 10GB sql server instance. And in general, it 'just works'.
Interesting, thanks for sharing. I would have just thought "Azure and done" but it's nice to see that there are other options in this ecosystem.
[deleted]
We host Cloud Cellar on Windows Azure and have had positive experience doing so. PS: The BizSpark program is really good for .NET developers - use it!
BizSpark has to be one of the most under promoted feature by Microsoft. I think its absolutely fantastic and it boggles me why they don't make more noise around it...
BizSpark is a great program and we were excited to take advantage of free Azure hosting included with it. However we learned from our customers that there is just too much latency between the web server and SQL Azure. We found much improved performance by moving to a Storm SSD server with the web server on the same box as the database server. Very happy with that decision.
The only downside is paying for those services after BizSpark ends :)
BizSpark is awesome! My company wouldn't be around without it.
The main problem with .NET is the higher price due to the Microsoft tax. That said, it has advantages over the free stacks.
At my previous company, despite being a .NET shop, our main problem was not the cost--even though SQL Server is outrageous. It was the difficulty in implementing continuous integration and deployment. RDP is not a scalable solution. Implementing Chef on Windows was a major pain. The insanity of having to install VS on the build servers just to get automated builds of web apps. MS, what were you thinking with making VS a dependency for building websites?!
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.
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.
We've built a complete continuous deployment system with TeamCity/MSBuild that worked quite well for us. It probably took about two-three weeks to work out all the details, and now it's been running for over a year with almost no modifications.
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.
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.
RDP isn't a scalable solution. I'd recommend PowerShell for all that. For the build server, you just needs msbuild which i think is available on the .net SDK. For CI, i've used TeamCity in the past which worked well. Staying away from TFS is a good a decision. On windows boxes i recommend mercurial because tortoiseHG is so nice, really miss it ever since i moved to developing full time on a mac.
Yes. PowerShell, PowerShell, PowerShell a thousand times. I think that every .NET developer should be functional in it. PowerShell can do everything they already know from the .NET BCL, AND run every command line tool they've ever used, AND every server administration task you can imagine. And it's extensible with .NET. I've personally witnessed some pretty awesome one-click deployments with PowerShell, including to Azure with zero-downtime using the MS-supported cmdlets.
The new PowerShell Desired State Configuration in PowerShell 4.0 (Windows 8.1) looks interesting... almost a bit Chef-like?
http://technet.microsoft.com/en-us/library/dn249912.aspx
http://technet.microsoft.com/en-us/library/dn249912.aspx
Can you share anything about that one click (nothing to do with one-click™ I'm sure) deployment?
It's a lot like what @smhinsey described. Team City was our CI platform (could be TFS), applied XML transformations using PowerShell for the target environment (I'd probably use the .config patching nowadays), built it using msbuild, which output a cloud deploy package, and using the Azure cmdlets deployed that package to the Staging slot, started it, waited for it to respond to a HTTP request, and then performed a VIP swap.
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.
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.
We have a number of one-click deployments running in TeamCity. It's honestly very straightforward. If you're deploying to Azure you can use either the Powershell or node.js libraries to talk to their API. We use powershell. Basically, we compile using msbuild, package the artifacts into an Azure package, and deploy it via the API. Doing zero-downtime deploys to Azure is a matter of how you use the API. You can substitute EC2, another cloud, or traditional hosting and while the tools and APIs get progressively less powerful, it's all doable. At the simplest level you may just use msdeploy as your "API."
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.
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.
You might be interested in a project that I have been building - https://github.com/manojlds/ydeliver
Whats so great about TortoiseHg?
I've tried a few times to use Mercurial from the command line and just can't get my head around it. TortoiseHG takes all that pain away by visually displaying what has changed / the different builds & branches. Merging is so much easier...
Hg's command-line tools are pretty awkward.
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.
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.
Have you tried SourceTree?
I have been really disappointed with MSBuild in general. I kept looking at steps in the build process and finding documents that said "you need to install Visual Studio and package XYZ onto your build server to get support for this feature".
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.
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.
Why did you need to install VS on the build servers?
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.
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.
> Why did you need to install VS on the build servers? ... It is not needed to build web apps
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 [1]!
> 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 [2].
[1] http://msdn.microsoft.com/en-us/vstudio/hh857605.aspx
[2] http://www.microsoft.com/en-au/download/details.aspx?id=3818...
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 [1]!
> 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 [2].
[1] http://msdn.microsoft.com/en-us/vstudio/hh857605.aspx
[2] http://www.microsoft.com/en-au/download/details.aspx?id=3818...
Same here. Absolutely no VS on the build server. There isn't a whole lot that VS can do that MSBuild can't do on its own.
Definitely look at OctopusDeploy.com for automated deployments. Amazing.
This is what I am currently using. We build changes using TeamCity on every default (live) branch commit, build the changes into a NuGet package, and use Octopus to pull in TeamCity's NuGet feed.
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.
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.
+ 100000
This has changed my life.
This has changed my life.
VS a prerequisite? In the .NET world I guess you can use TFS Server CI. You can use msbuild to take care of building websites can't you? There's always the self building IIS option but that's less rigorous of course.
I just finished my "Reengineer our CI system" sprint task!
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.
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.
What prices are you calculating? You can install and use Microsoft .NET without Visual Studio for free, so the Windows OS is the only price in the server in that case if you use a free database, etc.
You can even use VS for free, as long as it's the Express version, which is capable enough for a lot of use cases.
You can get quite a bit done on Mono these days.
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.
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.
While Mono is largely compatible with .NET, I'm still not convinced about its performance and scalability compared to .NET. I haven't come across any case-study or even an example of a high-traffic public Web app using Mono.
I'd be cautious about deploying a high traffic app to Mono as well. This is more for experiments and personal apps.
Here are some more suitable (reliable and inexpensive) options (based on first-hand experience and research/testimonials):
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)
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)
Few more, with SSD RAID (found from recent survey for an ASP.NET app): Dediserve (http://dediserve.com), RamNode (http://www.ramnode.com), DotBlock (http://www.dotblock.com)
Curious if anyone has experience running .NET applications under mono on Heroku?
You probably want to see this comment:
https://news.ycombinator.com/item?id=6241570
https://news.ycombinator.com/item?id=6241570
+1 for Azure or AWS
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.