Ask HS: Is Microsoft the Right Technology for a Scalable Web-based System?
Monday, October 7, 2013 at 7:03AM 
This question was asked over email and I thought a larger audience might want to take a whack at it.
I have a problem I’d like to have your view on. I’ve looked around a lot, and I haven’t found a definite answer. The question is this:
Is it true that for a scalable web-based system targeting millions of users (hopefully), using Microsoft technology(.Net/SQL Server) over open source technologies like python/ruby/php and mysql (mariadb) / postgresql will cost you more? Is there any justification for paying up for Microsoft licenses(OS, SQL Server, …)?
I am in charge of selecting the technology toolbox for a startup which is going to build a scalable public web platform. I’ve worked as a developer and database developer/admin (mainly as a DBA) using different platforms and technologies, but my main focus is on Microsoft technology. I’ve considered all other important factors for this decision, and at the end, I always come back to the question of money. When I finish developing the first stage of the system, and present it to possible investors to raise money and expand it, will it be a negative point(or even a deal breaker) to have a system developed on top of Microsoft technology stack?
Every time I decide to go with Microsoft, I ask myself “why no other major web-based system (other than stackoverflow) is built on Microsoft technology?”, and I’m back to square one.
Thanks for your time.
Reader Comments (23)
Depending on the nature of your application, you could use a .Net / MSSQL core, and then scale it out with a farm of linux-based caches. If your application is primarily read-only (news site or blog), and architected right, most of the traffic will never get past the linux front end, even though the majority of the page generation is done in .Net.
From the information I have learned on just this site alone is that most companies that end up with high user bases usually to not end with the same technology that they started with. Most start with a language or technology they are really comfortable with at time of launch and then as the product grows that technology changes with it.
A few examples:
Stack Overflow was 100% microsoft but now uses a mix of microsoft and open source.
Facebook was 100% php, and now php java c++.... the list for them can go on.
Twitter was 100% ruby and now are using a lot of java.
Reddit was lisp and now Python.
1. Use other people's experience as a guide, but in the end the responsibility is yours so go with your gut. Other people can be wrong.
2. Use what you and your team are familiar with. If you are productive and can hire the right team using Microsoft technology then you are a step ahead.
3. Lots of Open Source software is available on Microsoft so it's not an either/or decision. Look at the software you'll need to make your system. If it's not available on your chosen platform then you'll have to write it from scratch.
4. StackExchange is using a lot more Linux and Open Source so they might have gone a different direction if they had it to do all over again.
5. If you are going to deploy in Azure then a Microsoft stack makes a lot of sense.
I had the same question as yours regarding IBM technologies I know quite well and I found these reasons why nobody else around wanted to use them.
There are three reasons to why startups do not use <BIG BRAND NAME> software tools.
1/ "I am a startup and I prefer spending my little money on something more visible than <BIG BRAND NAME> licenses."
I feel that solid underlying architecture will ultimately show up, so I blend open source and licensed products based on my particular priorities when I can avoid to reinvent what I know exist and work well.
2/ "I am a startup so I take startup tools not incumbent tools."
I let you judge this one on a strategy point of view. My belief if that there will never be an ERP in my company but at the same time I pay for software when it allows me to keep focused on my own product.
3/ "I am a startuper and I don't know these corporate tools."
I believe this is the dirty little secret behind it : fear. If you had a previous life, obviously use your skills!
I don't use MS technologies because I don't know them. I don't use IBM technologies because I cannot afford them. Then people make a lot of rationalisations around the real reasons listed here, like "I prefer to go lightweight" or "I prefer to go straight forward" but honestly, I could afford (knowledge + money) to go for an easier platform than the one I use. I would pay for it.
Hope it helps.
I'm in the same position and to get things moving stuck with what I knew/know - the MS stack. Yes, it seems to cost more but as mentioned above, that can change in the future. It's important to remain open-minded.
I think you're forgetting about a few tiny sites such as microsoft.com, hotmail.com, outlook.com, Windows Azure, Office365, etc. All of these are based on the .NET/SQL Server/Win2012 stack.
Using the Microsoft stack makes at least as much sense as using anything else with commercial dependencies, and actually much more than something like Oracle, force.com, Heroku, or exclusive Amazon technologies like DynamoDB. You're far less "locked in" with Microsoft technologies than you are with PaaS stacks or SaaS components.
The major reason most web startups use exclusively open source components is cost and familiarity. If you're a mostly-MSFT shop, and have BizSpark or other favorable licensing terms, the total cost including support and managability of MSFT products might be better for you. Especially when you consider how "supportable" and "manageable" something like SQL Server is compared with any open source database.
Just as a side note: If it is a startup you can apply here for MS specifically: http://www.microsoft.com/bizspark/
I have developed for a customer that got access there and thus we have been able to develop in .NET (which i have a good background with) and not had the burdon of high licence costs either. If the startup still exists after the three years it is one of the 20% of startups that was not dead in that time anyways. So it either went very well (then you should have the money to pay for the licenses) and/or look at other open source software (like already mentioned) if the licenses are (still) too expensive/the startup was no success.
I too am a long term MS developer. However I wouldn't choose MS tools for a startup, simply because of the licence costs and the attendant high costs of Windows server instances. There are also better tools for cloud management of Linux based infrastructure vs windows. An interesting middle way might be to look at Mono, that way you'd would combine the familiarity of the MS toolset (Visual Studio, C# etc) with an open source platform.
I'm planning to use the Microsoft stack (MS SQL Server, .NET, C#, IIS, etc) as that is the platform that I am most familiar with. Also, as mentioned by others, the BizSpark program pretty much negates the license cost issue, so it becomes a no-brainer if the MS stack is what you're familiar with.
I personally would never look at MS tech over anything open source for the licensing issues as well as vendor lock in. Besides your knowledge of MS products what other benefit is using their stack giving you? When I start doing scaling ops and the proverbial excrement hits the fan the last thing I want to deal with is some proprietary, closed source framework. My $0.02.
I've built multi million user sites on both the Windows platform (at Microsoft) and currently on linux and open source. My, well educated, but now totally biased, opinion is that starting with Windows people and Windows tech is going to cause a great deal of damage when you need to scale out quickly, which is always the way you need to scale out. There are two core challenges with building a high scale system that are not inherently related to the technology.
First, it is difficult to innovate at scale. In order to innovate at scale, your people need to be productive and familiar with the technology that you're using. They need to have tricks up their sleeves that are second nature. The tools need to be low friction. Microsoft and Windows meet many of these needs well, until they don't, and when they don't, you run into problem number two.
The second major challenge is that your system needs to be easy to operate. If you spend all of your time operating your service, then you won't be able to innovate, even if it's easy to innovate. Mixed environments, running both POSIX compatible operating sytems and WIndows are inherently difficult to operate. You need experts in both fields, and they need to agree with each other. This problem is something that you'll run into quite early. When you find that nginx will give you a better system for capacity and load management, or that a varnish server will save you a bunch of time deploying and fixing flat file servers. When you realize that you need your data to be distributed across the network, or when you find that configuration management in PowerShell is dramatically more complicated than tools like Chef and SSH.
I find that this second challenge is often overlooked. Operational challenges can easily destroy your teams productivity, they can make your service un-reliable and make your customers go elsewhere, and they can cause your employees to look for new jobs. You don't really want to screw around with adding operational complexity to your service. In my experience, Windows will eventually lead to this type of complexity.
I think the easiest way to answer this question is with a few simple questions:
How many developers want to work at a startup using the microsoft stack?
How many developers who would typically be candidates for the startup environment know the micorsoft stack?
Go ask 10 developers you know if they would work with the microsoft stack, at an approximation of what you will pay on your given problem domain. That will tell you a lot.
The type of people drawn to .NET and corporate jobs (typical environment for this dev stack) want certain things from a job. Startups likely do not meet many of those criteria.
Or post an ad for your job with .NET descriptions for qualification. Observe the response.
Now do the same thing with: Nodejs, Golang, Clojure, Haskell, Scala, Ruby, [any open source platform] and see the response.
The UNIX world was network centric all the way back in the 1970s. Windows started off as an application on top of DOS and to this day still feels like a one user per machine OS. Then there is the security model consisting of anti virus software which uses more CPU cycles than the computer uses for doing actual work. Blue screen of death: any questions? The registry. GUIDs. COM. Gigantic frequent updates requiring multiple reboots. The incredible decline of Microsoft documentation in recent years. Windows 8: turning desktop machines into cell phones.
I still use Microsoft products for personal computing. Windows does a much better job with fonts, printing, games, mounting thumb drives and other PC kinds of tasks. But the thought of using Windows machines to serve web pages confuses and frightens me. Microsoft would have to pay me to use their products to develop an online service.
Pay me a LOT.
Very well said Carl.
Since you use StackOverflow as a benchmark, keep in mind Jeff Atwood is using Ruby for his new project, and explains his rationale very eloquently:
http://www.codinghorror.com/blog/2013/03/why-ruby.html
Personally I don't think it makes any sense to bake in dependencies on expensive licensed software into your business model, whether from Microsoft, Oracle, IBM, Tibco or other enterprise vendors who have turned lock-in and price-gouging into an art form. If you don't have any compelling reason to go MS, such as having to deal with specialized hardware that does not have non-Windows drivers, or having to work in an industry where Windows interoperability using MS proprietary protocols is required, there is no reason to consider them (and even in those cases, you should contain your Windows dependencies by isolating them behind a REST API). Their discounted startup pricing is irrelevant - as with drug dealers the first hit is always free.
If you want to go MS consider using ServiceStack. It's open source and can run on Iis or mono on Linux. Has everything you need for web service or web pages and some cool integrations like protocol buffers, redis etc
The comment about mixing ms and open source was spot on. We find we have to rewrite the . net clients for open source technologies because nobody gives them any attention.
Cost is definitely an important factor and not one to be taken lightly when you get to massive scale, but some other important factors.
- When you get to massive scale, you're in a rather small field of players. You're going to have needs outside of the mainstream users of any technology. Having access to the source code to fix things yourself if needed could prove to be invaluable. Vendors make fixes and changes where it brings them the most money. If you're a small fish (with respect to revenue they make off you), you're not going to get the fix. You have to be a bigger revenue stream to get their attention and this goes back to your cost issue.
- As much as I hate to say it, but "everyone else is doing it" might be important. At massive scale, you're be in a small club and it'd be nice to be able to leverage work done by others and open sourced. The community is valuable.
- Probably the biggest thing, though, is to not be stuck on a specific technology stack or design. Be flexible with whatever you do. Know that you'll need to adapt and change constantly. Make a choice and plan to revisit everything periodically and change as needed. You hope your choice is good for now, but know it won't be the right fit later on. Change is constant and inevitable -- embrace it early on. You won't know your pain points until you get something out the door and experience real usage of your application.
Good luck!
Agree with Carl.
A while ago I worked at a company which chose to go with Microsoft technology because some backend developers where familiar with .Net. The idea was that the frontend developer would write templates in Razor.
Problem was, half of the frontend developers used MacBooks and running Visual Studio in an virtual machine was a nightmare. Eventually, the solution was to go with single page applications where the backend was reduced to a very thin layer on top of the database, spitting out JSON data.
Moral: first look what your developers and system administrators want.
Twitter does use the JVM, but they are one of the main proponents of Scala. To say they are using Java is too vague.
http://twitter.github.io/effectivescala/
John's comment largely summarizes why .NET is not more prevalent. The .NET vs. OSS conversation has reached religious proportions with a significant portion of the development community favoring OSS as a matter of preference rather than object evaluation of best tools for the job. In this new polyglot world familiarity is not the right metric for selection of tools and environment.
There is a reason that .NET and the Microsoft toolset have such a prevalent position in the enterprise world. They are hands down the most productive environment in which to develop large projects. Using Visual Studio is like getting hooked on crystal meth. Once you do you lose interest in anything else. (And no, I have no personal experience with that particular analogy.) Sure, like any Microsoft application VS is somewhat heavy just due to the sheer number of features that are included that are intended to add value for the broadest possible user base.
Linux vs. Windows is a conversation that needs to be retired. When Microsoft made the GUI optional they pretty much wiped out the 'heaviness' argument. And the tools available to manage it are on par or better than anything else available. Even PowerShell is a boon for DevOps. It let's us leverage our object oriented mindset at the command prompt rather than forcing everything to be a stream of bytes. It only seems complex because it is different. And again, familiarity is not the correct metric for technology selection.
Getting to the core of the original question, which environment is best for building scalable web apps? There is no best. Scalable web apps are about architecture not specific implementation technologies. Individual compute instances or database implementations are no longer the performance bottleneck when proper horizontal scaling is applied. The need for squeezing the last bit of performance out of an instance via tweaking the stack using hard earned arcane skills is becoming a thing of the past.
In the end the choice of which technology to use in a startup should be made objectively by the CEO and investors as to which best meets the business needs of the company. Sure, availability of talent is a factor, but not the factor. There is a perception that only OSS talent is available today which might be true in Silicon Valley and Boston, but much less so in Seattle or New York City. Developer productivity is also a key metric and Microsoft shows well there. Which cloud to use and whether to use IaaS or PaaS factor in and are largely independent of the .NET vs. OSS conversation. There are many other aspects of the technology strategy decision and startups are well served by considering them all within their specific context rather than based on preconceived notions and conventional wisdom.
Finally, this decision process is particularly difficult because Microsoft itself is largely absent from the .NET conversation. There are several reasons for this, but the two big ones are their own inferiority complex and an internal religious war that erupted when Steve Sinofsky was calling the shots as he was widely reported to have "hated .NET" and was driving everything to HTML5/JS. Enough said about that as they are making efforts to balance that story out which will take some time. But the inferiority complex is the interesting one. The last time I was directly engaged with their developer evangelism group on this topic they were literally afraid to have a conversation with startups about .NET. They rely too much on osmosis rather than explanation. Which leaves all of us to figure this out on our own based on whatever experiences and biases we bring to the table.
"will it be a negative point(or even a deal breaker) to have a system developed on top of Microsoft technology stack?" No idea, you probably want to ask on a VCs rather than nerds. However, for a counter-case you can look at ASOS.com - see their Stack Overflow ad for a feel for what tech they use: http://careers.stackoverflow.com/uk/company/asos
If your business is as successful and as large as that then I suspect your investors won't care whether it's built with unicorn tears or Open Source or MS.
Hi,
Technological feasibility studies should always try to match the requirement analysis and produce a technological stack which can be used to fill those requirements. There's probably no technical reason to choose one technology over another, so what's left is to find those pesky submerged requirements, which are not visible at the moment. You've already touched this subject while contemplating investors reaction to proprietary software and I'd like to suggest that you stay on this path, regardless of whether some technology is in on out at them moment.
Things I try to keep in mind, when doing such analysis are for example:
- open source vs proprietary software. Is the open source solution going to be around for the duration of an application/system lifespan? How well the contributors are committed to the project? How large the developer base is?
Nothing sucks more than getting some open source application up-and-running in a production environment and then realize that the whole thing was just a faint blip in the IT-history :) On the other end of the spectrum, I usually try to find out how the licensing fees and such are going to change in the future. Microsoft just bumped-up their SQL Server (EE) licensing fees, which has led to a major refactoring in many project.
- Second thing I try to keep in mind is how well the technology fits the problem. This contemplation revolves around the concepts of specialized/generalized solutions. How sure you are, that you need, say, schemaless document store? Can you get by with a simple kv-store? Do you need a general purpose OLTP database? Remember that one size never fits all and try to select your stack in a way that you are able to introduce other datastores into it. While SQL Server is a great database, there's really no justification of building web-cache layer on top of it.
- Third, and last thing to keep in mind is the fact that the maturity of the technology is quite often the fact of how well they implement industry standards. Standards are great! if you demand strict compliance of the standards, more easier it becomes to get rid of layers of your stack or replace them.
What comes to investors, they value both sides of the spectrum. If your organization, product and process are all about agile development and fast reaction to market, then the they might value open source stack. If they need to see stability and longevity, then proprietary apps might be the way to go
Teemu