« 17 Distributed Systems and Web Scalability Resources | Main

January 22, 2009



You point about heterogeneity is well taken. At the end of the day, having well-defined interfaces and protocols matters more than the implementation. But why did you choose the .NET stack for the bulk of your systems? Was it a constraint of your 'parent' company? of the available developer skill pool?

I ask because the common wisdom for startups is LAMP, LAMP, LAMP. For obvious reasons, the costs of getting going with free software are minimal and many dorm room developers cut their teeth on those systems. On the flip side, if you're coming out of an enterprise IT environment, there's a good chance you've been on Microsoft.

So, as a startup, if you're building enterprise-oriented software, .NET has a compelling appeal. But if you're a startup building a highly scalable, available internet service (think Facebook, Twitter, Digg), and you are starting from scratch, then what do you think of the LAMP vs. .NET choice?

If you had to do it over without constraints, which would you choose and how would you calculate the cost basis of each choice?

Max Indelicato

Hi pfries,

You hit the nail right on the head. Parent company constraints were the driving force behind working with .NET. In fact, when I came on board, our start-up was already using .NET and it wasn't financially viable, nor was there time available at that point, to move to a LAMP architecture. Don't get me wrong, .NET has a long list of merits, and it has served us well with the exception of the costs involved.

This is one of the reasons why I'm excited that we have more multiple platform options open to us. We now have the opportunity to make gradual changes, or none at all even, if that is what we choose. And it's exciting for me personally in that I'm a LAMP nerd by preference, but a Microsoft developer in practice - I may be walking into the rare opportunity to combine both within the workplace.

To answer your last question, if I had been leading the founding team, I would have gone with a LAMP architecture based purely on our internal business requirements (which unfortunately I can't share). There's a time and place for both .NET and LAMP, and you really can't go wrong with either over the long-term, especially if money is no issue for you (i.e. you're heavily VC'd). Many .NET developers would even argue that the benefits of the .NET/Microsoft environment ends up paying for itself over the long-term. Anyways, I digress, it's really a judgment call based on preference and cash availability.


I'd been much more inclined towards a homogeneous set up for a while. It'd always been in my mind that you could employ a smaller, more skilled set of developers and admins that way.

I've slowly been adjusting my attitude recently on that front following observations at my previous employer. It was a bit more of an unusual environment there with the kinds of services we were offering to customers, but I really started to become conscious of the pros and cons of different solutions available under Windows and Linux. e.g. Exchange, for all it's Microsoft 'not quite standards compliant' quirkiness, is a very good and easy to set up office productivity tool.
It wasn't capable of doing what a smaller subset of staff required, however, so we ended up running Linux front end MX servers, based on exim, that were feeding e-mails on to the Exchange server after initial processing. Those Linux front ends allowed us to leverage some free anti-virus and anti-spam solutions too. Setting up a Linux based exim MX is a quick and easy task for your average sysadmin.
Re-creating all the required functionality of the Exchange server under Linux would have taken a stupid amount of resources away from money earning projects.
Being able to do a significant amount of spam and virus filtering on a Linux box also drastically reduced the number of Exchange servers we needed. In our experience exim is significantly more efficient at handling e-mail and due to the nature of business we received a significantly large amount of spam.

Raoul Duke

interesting thoughts, thank you for posting them. i would guess there are trade offs, of course. for example, how easy is it to debug your system end to end if/when a bad bug appears, vs. a system that is so homogeneous that you can just use the same debugger the whole way through? :-)

Max Indelicato

Hi Twirrim,

Interesting take on a heterogeneous system from an operations standpoint, thanks for sharing!

Max Indelicato

Hi Raoul,

Great question! I've found that traditional debuggers are near useless for debugging most distributed system issues. Having Visual Studio debug across our system is near impossible given the types of components that make up our system (databases, web apps, server apps, 3rd party apps and SDK's) and the reality that Visual Studio or some similar debugger can't effectively debug all programs equally. In addition, many of the problems we face are more logic based which makes code debuggers less useful than you might at first think. It isn't until we've tracked down a bug, across the system, that we break out the debuggers and tweak the problematic component(s)(server app, web app, etc).

Since our architecture is disparate in nature, and very loosely coupled, there is little advantage to being able to debug with Visual Studio for everything versus Visual Studio for some things and Eclipse/Java for others. Just to be clear, this isn't on purpose so much as it is just the nature of a shared-nothing architecture.

The comments to this entry are closed.


  • Max Indelicato. Chief Software Architect and technology enthusiast.

Other Services I Use

January 2009

Sun Mon Tue Wed Thu Fri Sat
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31