“IMO a reasonable definition of scalability for a given platform P and application A is
S(A,P) = R(A,P) / C(A,P)
where
R = Maximum number of requests processed per second by application A on platform P,
C = Cost of hardware and software to develop and support application A on platform P.

I’ve assumed 100% availability for the purposes of this discussion. Availability could be added as an input to the definition if desired. This term displays the expected behavior shown by common usage of the term “scalability”:
1. As throughput R increases, scalability increases,
2. As cost C increases, scalability decreases,
3. Different platforms and different software may be compared using this definition,
4. You can use this definition to estimate costs of a proposed system, given an anticipated user load.
5. Both R and C can be estimated using known techniques.

So using this definition, scalability’s dimensions would be “requests processed per second per dollar”. Given the following known values for a single application Z:

running on platform X:
R(Z) = 1000 requests/second,
C(Z) = $40,000
S(Z) = 1000 requests/second / $40,000 = 0.025

running on not-so-fast but less expensive platform Y:
R(Z) = 500 requests/second,
C(Z) = $10,000
S(Z) = 500 requests/second / $10,000 = 0.05

While platform Y’s throughput (performance) is much less than that of platform Y, Y is much more scalable than (in fact is twice as scalable as) platform X when running application Z.

This definition can also be used to estimate the utility of using various software methodologies. For example, heavy use of components or object technology may or may not change each factor in the definition: the degree to which each is changed determines whether the resultant system is more or less scalable.”

You may have noticed that pretty much everyone in the Ruby camp are insultants with many of them being book authors attempting to capitalize on hype. I of course, will remain open minded that Ruby may be better than say Java at some tasks but for the…

This is not a fact. Mass producing items with statistically negligible defects happens every day with many extraordinarily complex products: cars (particularly japanese cars), household appliances, consumer electronics, etc. When was the last time you purchased a hand-crafted refrigerator because would have higher quality?

If, however, someone asked me to prepare that exact same meal for a party of 400 people, or 4,000 (or 4 million people), I can guarantee you that the quality of the food I’d prepare would get progressively crappier the more people I try to make it for.

That would be a case of you not being “scalable”. High-end restaurants regularly serve stunning meals to hundreds of people an evening; they’ve worked out a process for doing so where the food doesn’t get crappier.

If you’re not able to see the level of utmost crappiness built into these products, you’re probably heavily biased towards Microsoft.

And you’re heavily biased against them.

I’ve posted here because I find your attitude does not support your arguments. You make very bald faced claims, use very vague analogies to back things up, arrogantly suggest that if a reader “doesn’t get it” that’s their problem, and then make obnoxious blanket statements like this one. You seriously damage your credibility by taking such stances.

That said, you may get people who genuinely want to know and have the experience to understand. I guess they want to know where using Rails can be problematic for scaling (e.g. ActiveRecord generating significant DB overhead) and how to work round it (e.g. knowing when to insert some hand-crafted queries). And otherwise hearing other peoples experiences, tips on how to profile, monitor Rails applications etc.

You may also get people who lack the understanding but have experienced the impact of a platform that didn’t scale. They’re also asking a valid question but how to answer?

Anyway - best rant on scalability I’ve ever read: (http://www.schlossnagle.org/~george/blog/index.php?/archives/29-Why-PHP-Scales-A-Cranky,-Snarky-Answer.html)

“That’s why we advise groups to ignore issues like scalability, internationalization, and heavy-duty security at first. [1] I can imagine an advocate of “best practices” saying these ought to be considered from the start. And he’d be right, except that they interfere with the primary function of software in a startup: to be a vehicle for experimenting with its own design. Having to retrofit internationalization or scalability is a pain, certainly. The only bigger pain is not needing to, because your initial version was too big and rigid to evolve into something users wanted.

I suspect this is another reason startups beat big companies. Startups can be irresponsible and release version 1s that are light enough to evolve. In big companies, all the pressure is in the direction of over-engineering.”

And yes, some issues do boil down to lesscode –> more design. But that’s not the whole story. I’m planning to write more about the other side very soon.

I like Alex B’s restaurant scalability analogy, but more on that in a moment.

I think the issue of scalability is all about the design and has less to do with any particular programming language, application server, framework, or infrastructure. If the design (via the requirements) calls for the application to scale to x, y or z, with meaningful metrics, then it is up to the Architect to “design” an application, system, or whatever, to ensure the design meets the requirements. And btw, we are in the software world, we can make anything scale – nothing that time and money can’t solve in our virtual world.

When I first came to lesscode.org, I thought it was going to be about more design and lesscode. However, it seems that the site is about people that really care about handcrafting excellent code. I can respect that, just different to what I though it was going to be about.

Back to Alex’s restaurant example. In fact, Alex B. has described an analogy that MSFT uses for its software factory vision. Check this out:

“A software factory is a product line that configures extensible development tools like Microsoft Visual Studio Team System (VSTS) with packaged content and guidance, carefully designed for building specific kinds of applications. A software factory contains three key ideas: a software factory schema, a software factory template and an extensible development environment:

•Think of the software factory schema as a recipe. It lists ingredients, like projects, source code directories, SQL files and configuration files, and explains how they should be combined to create the product. It specifies which DSLs should be used and describes how models based on these DSLs can be transformed into code and other artifacts, or into other models. It describes the product line architecture, and key relationships between components and frameworks of which it is comprised.

•The software factory template is like a bag of groceries containing the ingredients listed in the recipe. It provides the patterns, guidance, templates, frameworks, samples, custom tools such as DSL visual editing tools, scripts, XSDs, style sheets, and other ingredients used to build the product.

•An extensible development environment such as VSTS is like the kitchen where the meal is cooked. When configured with the software factory template, VSTS becomes a software factory for the product family.

To press this analogy further, the products are like meals served by a restaurant. Software factory stakeholders are like customers who order meals from the menu. A product specification is like a specific meal order. The product developers are like cooks who prepare the meals described by the orders, and who may modify meal definitions, or prepare meals outside the menu. The product line developers are like chefs who decide what will appear on the menu, and what ingredients, processes, and kitchen equipment will be used to prepare them.”

How about that? In fact, if you look at any “industrialized process” it has been designed to scale. The key word being “designed”. So if the restaurant needs to scale to millions, then design it to scale! While I respect my fellow codecrafters, I am waiting for the industrialization of software to take place so I don’t have to keep writing the same base code over and over again for each job that comes my way. After serving a million (of the same) burgers, you would think the codecrafter’s would get tired of this too?