Comments on: Technology is not Scalable

By: Randall

Randall — Thu, 01 May 2008 04:07:05 +0000

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.

By: Kendall Miller

Kendall Miller — Tue, 25 Mar 2008 14:37:50 +0000

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.

By: Paul

Paul — Tue, 25 Mar 2008 05:35:03 +0000

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.