Channel Viewpoint: A scale-up, scale-out, scale-in discussion 11 March, 2007 By Joe Clabby

PromoPipeline Exclusive Channel Promotions Find Out How You Can Make Money Today! ENROLL FREE! >> Factory Direct Should Not be Cheaper William Vanderbilt - Innovative Learning Channels Cloud Ecosystem II: A Candid Conversation with Oracle Beth Vanni - Amazon Consulting Cloud Ecosystem: A Candid Conversation with Rackspace Hosting Beth Vanni - Amazon Consulting Channel Manager Compensation William Vanderbilt - Innovative Learning Channels Financial Expertise William Vanderbilt - Innovative Learning Channels

From an application perspective, some applications (SAP or SAS, for instance) were written for mainframe systems and performed a lot better in monolithic environments than in distributed environments. But over the years these applications have become more compartmentalized -- easier to break-up and run on multiple distributed servers -- so that rule-of-thumb no longer applies. There are, however, some applications in the scientific, life sciences, and financial communities that need direct control of large processor complexes to produce a certain kind of result. Examples include Monte Carlo financial simulations, deep computing visualization applications, certain materials science applications (that often apply to national defense) and more.

On the scale-out, distributed computing side-of-the-house, some applications ran better and were easier to manage when given their own server environment (Microsoft Exchange is a good example of this type). Many IT advisors used to recommend that these servers be under-provisioned (not fully utilized) so they would have enough headroom to process additional workloads when peak periods occurred. But with the advent of better virtualized resource control, when peak demand occurs additional resources can be found and accessed elsewhere -- with the result that these applications no longer need to draw only on local resources. And, in fact, consolidating, virtualizing, and provisioning these resources onto a scale-up design is often a more cost effective solution for many or even most enterprises.

The arrival of "scale-in" environments (individual servers that share common, integrated components within the same enclosure such as racks and blades), the lines have become even more blurred. Some applications still deserve their own servers (video-on-demand and Internet protocol (IP) television, for example), but supporting these types of applications on a traditional, self-contained servers would be too costly to deploy and to manage. Deploying these types of applications within a blade environment, however, enables IT buyers to reduce deployment costs by not having to purchase multiple, individual servers, and by not having to spend as much money on physical plant and cabling, while also lowering management costs.

Obscuring Architectural Lines

But even with these new rules-of-thumb, the recommendation on which architecture to buy can still be "obscure." Mainframes can run thousands of individual Java instances -- but so can blades. Distributed, self-contained, scale-out environments still make a lot of sense when an organization is geographically distributed, such as in branch banking and retail markets( where having to rely on centralized resources for support can result in slow customer service or even lost sales). Scale-in environments can now run super-computing workloads. Sorting out which applications belong where is no longer as cut and dry as it used to be...

The amount of processing power that can be delivered by a given system is also adding to the confusion. It used to be that if you wanted maximum processing power for large, transaction workloads, you'd choose a mainframe. But with the growing availability of multi-core, multi-threaded microprocessor architectures, these sorts of workloads can be run across distributed scaled-out servers, on tightly-coupled clusters, on mainframes, and even on blades. Except for certain high-performance computing (HPC) and supercomputing, and deep computing applications, processing power is simply no longer a major determinant of which architecture to choose.

Organizational structure and organizational dynamics still play a role in choosing the right architectural computing design for a given enterprise. On a macro level, I found in Eastern Europe that there is a predilection toward scale-up computing designs in former Soviet-block countries. Think about it for a minute -- for decades these societies were structured on centralized control; and the type of computer systems environment that they tend to prefer are structured on centralized control. Similarly, enterprises that operate with strong central management often find that scale-up environments fit their corporate and technological mold better than distributed computing environments.

However, in the Middle East, where I spend a fair amount of time each year, distributed systems dominate. Although Middle Eastern banking and oil/gas exploration systems rely heavily on centralized control, it seems that in governments (which often operate as groups of autonomous departments) and in business everybody wants to do their own thing. As a result, scaled-out towers and occasional rack-system dominate the Middle Eastern IT landscape. In both of these models, it is likely that IT will continue to be run within IT departments within enterprises. But both of these examples are ripe for externalized IT service offerings provided by utility computing providers (including traditional systems such as IBM and HP, and emerging Web-based offerings from Google, Salesforce.com, and Microsoft).

Two New Approaches

So, given this complex mixture of heterogeneous influences -- application types, systems characteristics, processing power, and organizational dynamics -- what advice am I now offering IT buyers looking for the best architectural solution to their computing needs? I use two approaches: the top-down solutions approach where I look at a business problem and solve it with a group of technologies (business continuity, security, collaboration, and compliance are but a few examples of problems in search of technologies); or the bottom-up approach where I look at the application that needs to be deployed and figure out which system (I build-up from the microprocessor level) makes the most sense for that application .

If I take the latter approach (which I do most often), here's a rough approximation of what I'm telling prospective IT buyers:

" Look at the applications mix first. The workload will dictate the type of processor you'll need. For instance, a specialized, predictable workload might run best in an Itanium environment  a generalized workload may run best in a reduced instruction set computing (RISC), or on complex instruction set computing (CISC) environment (x86 processors), and on mainframes.

" Look at the operating system. Ascertain if the application runs on an operating environment that you can support (usually UNIX, Windows, or Linux) -- and that you are comfortable with the manageability, reliability, availability and security of that environment. (For instance, if high security is the utmost priority and the workload is generalized, I steer the buyer toward a mainframe or scaled-up server. But if the application runs at the departmental level and requires less security, I might recommend a distributed server environment).

" Look at the systems in their entirety. Discrete, distributed systems run multiple power supplies, have fans that need to be powered, and may require less cooling (if geographically distributed). But in total they may burn more energy because they each are driving more components while delivering fewer computing results (due to underutilization). Investing in a large, scaled-up mainframe can be too expensive for many computing environments if those environments consist of highly-variable workloads. But a mainframe offers substantial savings in energy consumption  particularly when it is utilized at greater than 80 per cent -- when compared to large, distributed computing environments, so total-cost-of-ownership needs to be considered carefully when evaluating a mainframe versus other approaches). Scale-in blades offer low upfront investment costs, decent virtualization and provisioning -- and most of all, opportunities to innovate due to their large and vibrant ecosystems (hardware and software suppliers). As a result, if an organization is being driven by acquisition cost -- and wants a system that allows for scalable innovation -- blade architecture makes an excellent choice.

If I take a top down approach, the first thing I look for is whether the applications and databases the enterprise needs actually run on the target architecture (and if so, how well do they run). I then look at the organization's structure and biases (central control or distributed). These two attributes generally help me figure out what type of architecture is best.

What this all comes down to is that choosing the right information systems environment for a given enterprise is more of an art than a science. On occasion, the application itself will dictate a certain system solution. But for the most part, the combination of application mix, required processing power, and organizational dynamics are the ultimate determining factors of which systems architecture to choose.

Joe Clabby is President, Clabby Analytics (www.clabbyanalytics.com), which specializes in teaching our readers how to build information systems that can ultimately support the transparent flow of business processes.