Slashdot Mirror
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.'"
and learned not a damned thing. Classic marketecture speak.
scale!
It says ad right there so there isn't any question.
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?
I've abandoned my search for truth; now I'm just looking for some useful delusions.
can someone scale that article down a bit?
a botnet !
Yours In Perm,
Kilgore T.
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.
You can't handle the truth.
That ash cloud from Eyjafjallajokull seems to be scaling pretty good.
Once I was a four stone apology. Now I am two separate gorillas.
Reading the TFA, the author kept making references to scaling using the "cloud" without mentioning any particular vendor. I'm thinking Microsoft's Sharepoint was alluded to, but as for as FlightCaster - what are they using? How would they use Sharepoint for that? Or is there a Hardware as Service company they're using?
RIP America
July 4, 1776 - September 11, 2001
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.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
Wow, they discovered the order of functions. (See http://en.wikipedia.org/wiki/Big_O_notation)
All ideas^H^H^H^H^Hprocesses in this post are Patent Pending. (as well as the process of patenting all postings)
"Cloud computing is a shitty lie."
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."
I judt got a nre Kinesis keybiartf so please excusr ant egregiou typos.
Well, expecting to get more output from the same input is of course illogical and impossible, but if a company puts up the planning, development and engineering resources to make it happen up front than the scalability claims in the marketing copy can be done to some extent.
But the way some (most?) deployments seem to go make it cost prohibitive to put the distributed database / distributed applications and fault tolerant components in in the first place.
By the time you need to expand a complete and less expensive system has already supersceded what iron you were originally running it on.
In many cases it is cheaper to replace the hardware than adding more "modules" for your scalable hardware.
Tsukasa: All I really want, is to be left alone...
You may now all skip even pretending to read the article and do what you do best: use a car analogy to explain why duplicating kiddie porn isn't theft, unless the Government does it.
If you were blocking sigs, you wouldn't have to read this.
Eyjafjalla is the volcano
Yes, indeed! I can run copies on as many desktops as I care to. Just add monkeys and ta dah - Shakespeare!
Very often, people confuse simple with simplistic. The nuance is lost on most. - Clement Mok
I agree completely. I should have spoken more clearly.
My co-worker's personal small business has 1 employee: him. He is a skilled tech guy who can handle most of the work himself. He had 3 options:
1) Move to the cloud for ~$150/month. supreme uptime, no hassle scaling, everything is managed for him
2) Move to a more robust dedicated virtual machine for ~$150/month. solid up time, scaling available, all network stuff is managed for him
3) Buy a server and business cable line to his residence for ~$750 one time purchase, but $20 less a month than he is currently spending on residential cable. He has to manage everything himself.
If he keeps the server/cable running for 3 years, it pays for itself, assuming he pays himself $150 a month for his own work. But really, his own work is volunteer, so against the opportune cost, he's in the green after 5 months. Even against his current costs he's in the green in under a year.
If his small business grows to the point that his cable line can't handle the bandwidth, or his cheap server needs more umph, or if his time becomes more valuable, the advantage will quickly switch back to the cloud.
-Rick
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
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
davecb@spamcop.net