Scalability In the Cloud Era Isn't What You Think

Esther Schindler writes "'Scalability' isn't a checkbox on a vendor's feature chart — though plenty of them speak of it that way. In this IT Expert Voice article, Scott Fulton examines how we define 'scalability,' why it's data that has to scale more than servers, and how old architectural models don't always apply. He writes, 'If you believe that a scalable architecture for an information system, by definition, gives you more output in proportion to the resources you throw at it, then you may be thinking a cloud-based deployment could give your existing system "infinite scalability." Companies that are trying out that theory for the first time are discovering not just that the theory is flawed, but that their systems are flawed and now they're calling out for help.'"

Comments

I read the article

[Saint Stephen]

and learned not a damned thing. Classic marketecture speak.

Re:I read the article

[Anonymous Coward]

Given "marketecture" speak is what got us into this cloud mess in the first place, perhaps fighting back with "marketecture" is appropriate.

Re:I read the article

[gstoddart]

and learned not a damned thing. Classic marketecture speak.

I don't think it's marketecture -- I think it' trying to point out some issues which most of us have never really thought about in terms of cloud computing.

Admittedly, I couldn't read through the entire article in one go, but I am going to go back and try to finish it.

The thesis seems to be something along the lines of: everyone thinks that with cloud computing if you keep throwing resources at the problem, scalability is something which sorts itself out.

The reality seems to be that as companies do that, they find themselves using proportionally more resources, and then they hit a wall where scalability tips over, and they get less additional benefit per additional resource. Which seems to be contrary to what everyone believes about cloud computing.

That seems to happen because the traditional apps everyone is trying to scale with cloud computing don't necessarily benefit from that kind of scaling. It looks like that for a while, and then it falls apart, and people need to figure out how to fix it -- you end up with a hot mess that doesn't even remotely do what you need it to.

At least, that' my best high-level grokking. But, I don't claim to grok with fullness. :-P

Re:I read the article

[c0d3g33k]

You must be out of good ideas to add to the discussion.

Re:I read the article

[c0d3g33k]

Both. (Marketecture and not grokking with fullness, that is.)

Marketecture part: The delusional fantasy that because one is able to talk about things in a new way, old problems affecting scalability no longer apply. Very true. The marketers believe it. The foolish customers believe it. Anyone who has a clue runs for the hills.

Not grokking with fullness part: You've accurately grokked the "every (idiot) thinks that if ..." part. What you haven't grokked is the details. In place of your speculation, just substitute that those who do not learn from history are doomed to repeat it.

The fantasy I see over and over again whenever a "new" paradigm changing technology comes along is that problems which were hard using the 'old' approach are suddenly eliminated merely by virtue of doing things in a "new" way. The fantasy is that having the 'insight' to recognize the awesome potential of the magical new approach is somehow superior to having the discipline to *fully* understand the problem and solving it decisively and intelligently. The latter is often viewed as not worth the effort or offering a "poor return on investment". The delusion is that effort is better spent on looking for a loophole that doesn't require any understanding because the new approach will magically make the hard problem go away so nobody has to expend any real effort. Doing things 'in the cloud' is one of those magic new approaches that substitutes for actually engineering a solution in an informed way.

Even if a new approach reduces the effort previously required for certain tasks, it invariably brings with it new problems that have to be understood in order to avoid being bogged down.

History shows that folks who solve the hard problem wipe the floor with those who are looking for shortcuts. FedEx (solved the logistics problems associated with rapid delivery to anywhere), Southwest Airlines (solved the logistics problems associated with low cost regional air travel), Walmart (developed a satellite network to track inventory and sales chain-wide). Google (a better algorithm for search). Etc.

Re:I read the article

[timeOday]

I'll bite, what's the "cloud mess"? In the olden days, we mocked slashdot story submitters who linked to videos because their ISP account, or university account, could never handle it. There wasn't really a way for an individual to share a video with thousands of people. Now we just upload to youtube, and viola, it works. Scalability issue solved. How many computers does it take to accomplish that? Where are they? Are they all in one place? It's a cloud, most of us don't know and don't care. It's good.

Nice URL

[Anonymous Coward]

It says ad right there so there isn't any question.

Infinite scalability?

[Locke2005]

Unlike stupidity, computing resources are inherently limited. Which is a good thing... imagine, if it were really unlimited, the huge bill you would get at the end of the month for a runaway task attempting to use every node?

Re:Infinite scalability?

[anomalous cohort]

Infinite scalability isn't the only snake oil in the cloud. Other cloud computing myths include "all you need is a credit card" and "cloud is cheaper."

Re:Infinite scalability?

[jd]

Sometimes an old thought can trigger a new line of thinking. For example, it would be difficult to make a 3-CCD camera that's as flat as a modern digital camera, because a decent-sized CCD placed sideways will widen the camera by that amount. The prism would normally be bulky, too. Far as I know, that's the main reason you see this sort of camera on high-end video equipment, not cheap digital cameras. However, I don't see anything there that can't be solved by using a few lenses and mirrors. Since CCDs can do 16bpp, this would not only let you triple the number of pixels but also produce high dynamic range. I've no doubt it's been done, it's too obvious not to have been, but I don't see anything like this in the regular marketplace although I can see no obvious objection. The only place I see anything like it is in the high-end with much larger - and much more expensive - gear.

tl:dr

[adeft]

can someone scale that article down a bit?

Of-course it is a checkbox

[roman_mir]

Scalability is a buzzword that equipment, databases and servers (hardware/software) are sold on. It is as if by adding more weblogic servers to a cluster really makes your application scalable, as if throwing more processors onto a RAID system gives you more parallel ways to read / write the same data etc.

It is all true to an extent and it is all false where it really matters. Applications need to be designed to be scalable and if I learned anything over the past 16 years is that people do not even begin to understand what it means.

The managers and even many 'architects' really think that by throwing some stupid app on a cluster will really solve the scalability issues and so on. But the problem is that it is a very specific problem that can be solved by simply adding cluster nodes without actually properly designing the app. I blame various silver bullets like EJBs, CORBA, RMI, JNDI, BEA, Oracle, IBM and such for promoting this view among the top brass and pulling attention away from working out correct architecture to solve the specific problems that appear in building truly scalable applications.

Application servers and databases are the worst at this, they certainly provide some specific type of scalability solution but because of that, it is almost expected that it does not matter how an app is designed to interact with these, and the design is really on the distant third, fourth, fifth or further place, way behind the deadlines, the politics, the hiring practices etc.

Scalability is like security, it is not a one specific thing it is a way to approach many different issues and problems and even when you think your app is secure in 5 different ways, there is a sixth way in which it is not. Same with scalability: it is not only about multi-threading requests, it is not only about multiple processors for a RAID system, it is about total understanding of how the application is and will be used and adjusting it for various types of usage. Proper design for scalability mixes various approaches, there could be intermediate steps added, back-ground processing added, intermediary storage, separate storage for reading than for saving, various caching mechanisms and synchronization between nodes in a cluster for different caching questions. This could be redefining an algorithm to be less dependent on reading data from slow media. Some things are not supposed to be done in parallel, so certain bottlenecks due to synchronization need to be looked at and solved early on, because these become the Achilles heel - synchronizing on anything at all can defeat a super-fast cluster and make it no better than as a single laptop.

It is a design issue.

Re:Of-course it is a checkbox

[lmckayjo]

But many types of video processing DO scale very nicely, as racks and racks of SGI machines proved years ago ("rendering farm" is a beautiful name for computers...). The "flow of time" argument against scaling, which is basically an argument against easy parallelization, works for some things but not others.

Even when the analysis or manipulation of one frame depends heavily on those before it, most video (or audio) work is broken nicely into scenes (or tracks/movements) which can be easily scaled - damn near linearly.

Financial markets work similarly. Yes, there is a very important interdependence, sequentially significant, but only between certain transactions. There may need to be "traffic cops" that don't scale linearly, but other parts of the transactions will scale nicely.

In the limit, nothing that we do will scale efficiently forever (to extremely large OR small), but video processing and financial systems are two examples which seem to scale quite well.

I dunno...

[thewils]

That ash cloud from Eyjafjallajokull seems to be scaling pretty good.

cloud computing only scales horizontally

[Lord Ender]

The Google App Engine cloud computing offering plans to (eventually) automatically scale your application as much as you need. But that scalability comes at a cost: only key-value stores may be used. Sorry, no relational databases available. JOINs just don't scale. You can distribute data across any number of nodes, but JOINing data which lives on separate computers is not gonna happen.

If you need JOIN-like behavior, your app has to request all the data, then compute the result itself. Trying to write an app for such a system means rearchitecting the data in ways to minimize the need for such operations, even if that means having duplicate data.

It's quite an exercise to unlearn what you have learned about SQL and relational databases, but the use of object mappers can help a lot.

Re:cloud computing only scales horizontally

[LWATCDR]

So one is going to have to learn a totally different way to do everything and then deal with a new set of problems.
Which is why IBM is still selling ZSystems running DB2 :)
That being said I have not used much in the way of key-value database in a complex application. Frankly it sounds like a real pain.

Hand wave

[Itninja]

I find that when I speak in my "IT Expert Voice" I get all kinds of things. Even if I am saying gibberish:

"Linda. The malware infecting you CRT is several beta tests behind the best practice of current IPv6 drives. I will need your password to defrag the driver and upload the taskbar to your certification path...Thank you Linda."

Sidebar tocloud computing only scales horizontally

[davecb]

A minor niggle to a correct thesis: clouds are indeed horizontal creatures, like lichens (:-)) Joins, however, can be decomposed into a horizontally scalable component that runs on many nodes to return a small candidate set and a vertical component that puts together the candidates and returns the valid ones as a join. This is what the Oracle Teradata (sp?) machine does, making TP substantially more scalable. The bottleneck in this scheme is the backplane: it requires Linux hyperchannel to achieve the expected performance boost. --dave