6 ms·

There's also plenty of Server Frameworks with First class support for Mono: I'm apart of the core team that delivers http://www.servicestack.net http://www.ser

• meaty 14y ago
  I'm going to throw a possibly unpopular view on the table here: sticking all this on Linux is purely about cutting costs but saves nothing. The administrative overhead of deploying all this stuff is incredible as are the disparate infrastructure and software models. You might be saving 11x on an Azure instance, but your ops time and staffing requirements will cost more than that. Throwing something on Azure is really cheap with respect to time and effort. If you need to scale past that or cost becomes a limitation, you might as well fish out for a Rackspace or other dedicated package. We're at the £50k hosting budget a month mark now (1x production DC, 1x hot spare DC, 2x packed 42U racks in each) and 2 meat based products to manage it all. Not much of that cost is software licenses. Note: I have nothing against servicestack - in fact it's rather good (we use servicestack.text) For ref, I turned down a position at 7digital a couple of years ago as I though they were smoking crack when stuff like this was mentioned.
  • mythz 14y ago
    Unless you're new to the web, you'll be surprised to learn that most of the Internet runs on Linux. It runs because it's a commodity server, because it has first-class support for most NoSQL data stores, caches, proxies, etc. because its highly configurable, because it's much more automatable where everything is scriptable with simple unix commands. Going to call BS on Azure being cheaper. All of ServiceStack's live demos are deployed using simple bash scripts. There's none of these admin overhead costs, I check-in on my dev box and run a remote script to deploy straight from the Git repo. The projects are also un-touched ASP.NET or stand-alone Console hosts (which I host behind an nginx reverse proxy). I've no doubt that it would be at least 11x more expensive if I decided to host servicestack.net on Azure, even more if I decided to use SQL Server (PostgreSQL/MySQL is free to use on Linux). And I'll also miss out on cool linux utils like rsync which is how we migrated GB's of content onto the new vServer.
    • meaty 14y ago
      The indexable "world wide web" of startups, big tech brands, VC, video sites, porn and blogs about cats falling out of windows, yes. When it comes to the deep web i.e. corporate applications, business tools etc, it's just not seen at all. These are the things that produce a lot of value and solve a lot of problems. I'd argue they are cumulatively more valuable than the above. EsEnt, AppFabric, IIS7 ARR, PowerShell cover your concerns above all of which are scriptable and automatable. When you consolidate your time across the year spent on developing a backup methodology for your server, managing updates etc, monitoring, testing, where does that leave you? I know Linux inside out (I've been a professional user on and off since 1998) and I know you hit the same number of roadblocks as windows along the way. Also your deployment model sounds odd. Do you check in your production artifacts/dlls and configuration? Do you build on your production boxes? Also your demonstration applications are tiny. A single deployment we throw out has 95Mb of release compiled DLLs across 48 assemblies... We use NHibernate and have a test harness for MySQL already so we're not bothered about SQL pricing (anyway it's still plenty affordable as our product is valuable and pays for the licensing). I was using rsync on Windows 2000 back in 2002 to sync press image libraries so that's a moot point really. Azure cuts it for the ramp up phase of your product if you factor in the above. We did a proper cost analysis.
• tzs 14y ago
  > We've gotten great up-time with Linux where our last server reached 480+ days up-time before we switched hosts I'd worry about reliability and security of any service with that kind of uptime. Security if the uptime was achieved by not applying kernel updates, or reliability if some kind of hack to update a running kernel without a reboot was used. The latter is a reliability problem because rebooting after a major update serves a purpose other than just loading the new kernel. It also serves the purpose of showing that the update has not broken configurations or dependencies required to boot. It's a heck of a lot better to discover that an update has left your system non-bootable right after the update, rather than finding out months later when some hardware failure takes down the server and then you find it doesn't boot and you've got to go back through months of changes trying to figure it out.
  • nnq 14y ago
    ...I imagine that "showing that the update has not broken configurations or dependencies required to boot" would be addressed by having testing the configuration on an exact mirror of the production server, including rebooting, right? (of course, after a reboot the testing server is technically no longer a mirror of the production one...) ...of course, the OP should enlighten us about whether this is how they did things
  • buster 14y ago
    Well, i don't agree here. You have the exact same system to test updates first, before rolling out on production! Just rebooting "because there may be something, let's see if it still works".. nahh, we're not running Windows here ;) By the way, I have had servers running several years on the internet, without problems, one FreeBSD which topped all until some hardware maintenance was necessary.
• xanadohnt 14y ago
  I love Miguel et al. but I tried for a long time to make a public ASP.Net (MVC2) site work. It would run fine for a few days but inevitably would become unstable where the Mono Apache process would runaway and put the CPU beyond 100% usage (how is that even possible?). After a year of doing weekly restarts I couldn't take it anymore and moved back to Windows. The extra $30 / month in Windows licensing on Racksapce more than paid for itself in the IT headaches (and expenses) it saved. Things may have since changed - this was back in v2.12 days - and / or other stacks (like service stack) may be more stable, but it's just easier for me to stick with Windows. With all this said, however, I have had fun trying the MonoTouch toolkit demos. I hope to find some time to build a real iOS app (one that works with the aforementioned website, in fact). Fingers crossed things will work out better this time for me and Mono.
  • mythz 14y ago
    You're going to always have a better experience from Web Frameworks that officially support and have tested their stuff on Mono. We've added special normalizing support to match the behaviour of IIS/ASP.NET where we can, e.g. imitate redirects + case-insensitive file paths, etc. This reduces the differences when porting your ASP.NET app across to run on Linux. Now that it's open source and MVC is accepting patches, MVC3 might be more stable on Mono.
    • itsboring 14y ago
      I think the problem here specifically is mod-mono and the fastcgi server (basically the xsp-derived glue). I've seen a number of people complain about memory leaks and instability and having to restart apache. It's not readily reproducible but it's enough to make people too nervous to deploy. Those sub-projects appear to be unmaintained and queries about their status on the mailing list go unanswered. Without some solid info there, it unfortunately makes the open source MVC stuff rather moot. I concluded (perhaps wrongly?) that web wasn't a priority for mono and chose another technology for that part. On the other hand, mono makes a great socket server stack, and I still use it extensively there.