Technology is not Scalable
Written by Kendall Miller on March 24, 2008 – 11:22 pmI was watching Start-Up Junkies the other day which is following a group of people attempting to get Earth Class Mail off the ground. On one recent episode, the main focus was converting their system from being PHP-based to Microsoft .NET.
As you watch the episode, you hear two different reasons given for this transition. The CEO advances the issue that they started with PHP because they needed to get something done quick, but now they need to switch to ASP.NET to make it scale. They always knew they’d have to do it, but now they’re against the wall because they have been invited to demo at a Microsoft conference. The lead engineering staff and operations manager advance a different point: We are about to be demoing in Europe in Microsoft’s booth at a major convention that’s key to our growth, we need to be using Microsoft’s technology for this to happen.
Of these two reasons, which do you think is the better reason for their technology choice:
- Convert to ASP.NET to scale up because PHP can’t scale.
- Convert to ASP.NET because we’re getting marketing and sales assistance from Microsoft, which we’ll only get on their platform.
If you picked #1, two things are likely true: First, you haven’t worked with enough technology to know that the choice between PHP and ASP.NET for scalability is pretty far down on the list of “things that control how much we can scale”. Second, you’re probably not balancing business and technology interests effectively.
Go and check out the technology portfolio used at the most scalable web sites in the world - say the top ten super scalable systems, systems that are going to be at least two orders of magnitude greater than anything you’re likely to create (and this isn’t a negative thing; it’s a liberating thing). Notice anything in particular? You don’t tend to see either Microsoft ASP.NET or J2EE in the web infrastructure. In fact, you tend to see a lot of… PHP.
There are a few key reasons that the super scalable sites like these solutions:
- Open source means they have the source: You can bet that these sites aren’t able to use anything off the shelf. Their needs so outstrip the normal system that it isn’t reasonable that any off-the-shelf framework is going to fit their needs entirely. In fact, if it did that framework is likely seriously over-engineered for the majority of its user base.
- Licensing costs add up: If you’re a small shop, licensing costs are highly unlikely to be a significant percentage of your total cost of goods for a technology product; bandwidth, hosting, and above all people are the big numbers. If you’re Google, you don’t want to pay even $10 in licensing per server. This is similar to a large manufacturer worry about saving $.05 on a bolt; small incremental costs still add up.
- Scalability is their first concern: More important than ease of development, cool debuggers, third party component libraries, or anything else. If it can’t meet their scale, it isn’t even a potential solution. Perhaps more importantly, they have to have both the experience and human belief that it will scale. If you’re one of these sites, there is no way a vendor has tested their solution at your scale - you’ll be the first. If you’re going to be the first, you want to have a simple solution that you can adjust and correct.
If you’re honest, your decision matrix isn’t the same as this. It’s highly unlikely you’ll create the next MySpace, even if you are successful. While the principles of scalability are constant, the importance of scalability vs. other constraints changes. More likely, you need to base your technology choices on a mix of:
- What resources do you have? If you already have a staff of people experienced at technology X, they are likely to produce more results in any moderate interval of time (say one to three months) with this technology than any new one. If you have a large body of existing code in technology X, this is a big accelerator to your project.
- What resources can you get? When picking a technology, buy the community, not the product. If you can take a number of pieces off the shelf, particularly for things you aren’t attempting to innovate (such as security, content management, grid controls, reporting..) it will accelerate your product curve. Conversely, if you can’t get great people that want to work with a technology, it really doesn’t matter how great the technology is.
- What religion is your market? Many markets have a non-rational product selection bias. For example, if you want to sell your product primarily to Macintosh users, you probably shouldn’t use ASP.NET. It isn’t that it should make a difference to how the product works for them, but as a group Macintosh users tend to put “Not Microsoft” on their evaluation lists. Similarly Linux users. Conversely, there are several products that are defined as “just like X, but in ASP.NET!” If your market typically has a technology selection criteria that isn’t based on business or practical fundamentals, it’s best to respect it, otherwise you’ll have to focus additional energy during your sales and marketing efforts to overcome what your market will perceive as a natural disadvantage. The coolest technology, developed quickly and cheaply, is no good if your target customer won’t even invite you to the dance.
Back to Earth Class Mail. Could they scale using PHP? Absolutely, others have. Should they switch to ASP.NET? Probably - they wanted to leverage the marketing advantage of Microsoft. I suspect if IBM was the big animal in the space they wanted and a deal could have been made it would have been WebSphere instead of ASP.NET. Each of these technologies can scale, or not scale, depending on how they are used.
Tags: ASP.NET, PHP, Scalability, Technology Selection
Posted in Infrastructure, Software Development |
March 25th, 2008 at 12:35 am
Your notes on platform strategy are indeed good points. What perhaps didnt come over quite so clearly in the Startup Junkies series was the reasons for our selection. Our PHP solution was coded offshore, by some folks who didnt really know how to architect a scalable system. That was also compounded by a poor specification (in hindsight), and some requirements that were partailly right, partially wrong (again in hindsight). I personally have had great success with PHP/MySQL builds, J2EE builds, and Microsoft builds, some in the same shop.
Our problem was that the codebase we had was brittle, part was OO, part wasnt, part had transaction bounding, part was non-transaction bounded. It was a mess. Running parallel servers in any failover config was a non-starter with this codebase.
We knew it had a finite lifetime and needed rewriting. The choices were open source - either Java or PHP - or Microsoft. Given we had a short runway, even before the Barcelona/Microsoft partnership date, and I hadnt yet invested in building the engineering team, I had a total clean choice of what to do. We had no partnership with Microsoft at that time, so it really came down to a simple technology selection. Microsoft can scale every bit as well as the open source technologies (or vice versa depending on your viewpoint). We chose Microsoft because it reduced the amount of plumbing code we’d need to write for basic architecture of a service oriented, localization ready, multi-tier stack. Add to that, the backroom functions are easier as microsoft client based because we are interfacing to scanners, scales, high speed sorters, barcode guns, amongst others, all of which have a dominant Microsoft Windows API. Every way I looked at it, it made sense to build a core engineering team with expertise in Microsoft technologies.
We went with the leading edge MS .Net 3.5 alpha and beta at the time, and so far, its really delivered on the promise.
To your points, I had choice of community. In Portland, OR, we have a very healthy OS community, and a strong Microsoft community. So no decider there.
I didnt have a team to start with - I inherited a pile of outsourced baggage code that was brain-damaged to just get to market. So no decider there.
Our market is cross religion. No decider there. And I’ve done Websphere before… its only a small part of the mix, and is no longer relevant in a technology selection. App servers have become commodity.
Microsoft Empower program put us on near equal footing for developer licensing costs with Open Source. No decider there.
I hope this helps understand the real core choices. The TV show told part of the story, and as you and I know there are many roads to nirvana. Its never cut and dried.
Paul
VP Engineering
Earth Class Mail.
March 25th, 2008 at 9:37 am
Fantastic points, it’s always great to hear the real challenges of making the behind the scenes decision. What really stands out for me in your comments are that the scalability issues were rooted in the implementation (and the mindset of the original developers) not the base technology. Second, your points on why you selected Microsoft’s technology base points in many ways back to buying into a community, not of people but of a hardware ecosystem - your back end hardware provided easier (or at a minimum perceived easier, since you have to make a decision prior to proof in most cases) integration with the Microsoft stack.
It sounds like you had a great opportunity to make a business (instead of ideological) based technology selection and eliminate a great deal of technical debt early in your company growth curve, a gutsy choice that should pan out well now that you’re on the other side of it. Better a short period of high pain than prolonged death by a thousand cuts.
Thank you for taking the time to add your additional insight to the article, I appreciate the time pressure you’re under and value that you took time aside to review the article and post thoughtful comments.
May 1st, 2008 at 12:07 am
I have yet to see a macro problem that can’t be solved on any of the major platforms.
I disagree completely that “You don’t tend to see either Microsoft ASP.NET or J2EE in the web infrastructure.” Beyond the obvious Microsoft on Microsoft, there’s also MySpace, which appears to be ColdFusion (to preserve the old links), but is actually .NET. That’s enough to prove scalability.
There are also a great many corporate sites on Java that are massively scalable, but they are behind firewalls. A lot of banking sites and Fortune 100’s are on it. Sprint’s billing is on Java for example.
Of course if you look around at the Web 2.0 sites a lot of them are PHP. It’s new and trendy and easy for beginners. Java is losing to PHP in that space, because Java is harder, because it won’t let you be lazy.
Costs aren’t really an issue anymore, unless you’re buying your own servers and paying for the OS, but why would you want to do that? There isn’t a significant cost differential between hosting on a managed linux box vs a windows box. Not enough to be a deciding factor anyway. With the proliferation of clouds it’s even less of an issue.
The real issues are, in no particular order:
1) What do my customers like? Not a big deal if your site is only accessed through the web, but imagine Digg on Microsoft. They probably wouldn’t have the same community…
2) What do I know? Doesn’t make sense to go through the learning curve while trying to startup. Don’t compound your problems. If you get funding, rewrite it in another language if the one you know isn’t the best.
3) How quickly can you implement the idea with the technology? This is big. This is why Java is losing to PHP.
4) How long will it last? Will PHP fail? Startups don’t really care. Microsoft? Not anytime soon. Java? Not for a long time to come.