At the conceptual level, there isn't a huge amount of disagreement among technologists about the fundamentals of cloud computing--its forms, its characteristics, its potential benefits, and its limitations.
That said, individual vendors come at cloud computing from particular perspectives that often reflect the character and needs of an existing customer base. Nowhere is this truer than in the case of IBM. I attended an IBM event at their new Littleton, Mass., location a couple of weeks ago, and I was struck by the degree to which its latest cloud computing announcements and the strategy of its cloud computing organization mirror the focus and strategy of IBM in other areas.
Several related threads collectively define IBM's primary approach to cloud computing.
The first is "private clouds."
By "private," IBM means one of three things: 1) infrastructure within a customer's data center, 2) infrastructure operated by IBM for a customer within an IBM data center, or 3) IBM infrastructure dedicated to the use of a single customer.
In other words, private pretty much covers the gamut of everything that is not a shared, multi-tenant public cloud.
However, that shouldn't be read as IBM just using the term "cloud" here as a marketing buzzword to cover just about all computing. It's easy to draw that conclusion given IBM's focus on dedicated infrastructure. But while IBM uses the term broadly and very pragmatically, it does associate it with certain specific characteristics.
For example, one IBM exec at the event spoke of an existing virtual desktop infrastructure (VDI) deployment and noted that it was not, yet, a cloud because it is the operations analysis, the service orchestration, and self-service that make a cloud. (In this context, operations analysis refers to identifying and modifying workflows and interactions between people--such as eliminating "ad hoc chatter" that duplicates effort or adds latency.)
A second thread is IBM's main target for this phase of its cloud rollout. That would be development and test--mostly for the reason that IBM sees this as the low-hanging fruit. It's an area of enterprise IT where change happens all the time and resources are often not easily reclaimed even when they're no longer being used.
If this sounds like a familiar storyline, it should. This is where virtualization got its start and for many of the same reasons. At the same time, what IBM is doing here goes beyond test/dev virtualization.
And this brings us to the third thread, the precise nature of the audience for these products.
What's different here from just loading up VMware on a blade server and even adding a VMware product like Lab Manager is the other IBM tooling in place. Rational development toolsets and Tivoli service management are integral parts of these integrated packages. (Tivoli plays a central role in IBM's approach to cloud in general.)
You might think that this is a heavyweight and heavy-duty enterprise-centric approach to cloud computing. You would be right. I made this observation to one of their senior cloud executives and he didn't disagree.
The exec's response: "Our natural constituencies are the enterprise developers and we have to cater to the enterprise developer and enterprise developer teams. Within them, we have the subset who write enterprise transactional software. These are the apps who decide over life or death of a CIO and we have to cater to them. They are also the majority still of the central development organization."
This is not to say that IBM isn't also doing things related to lighter-weight, such as RESTful, development approaches. There's an IBM Mashup Center, for example, and cloud resources on IBM developerWorks. However, this style of cloud computing is not at the forefront of Erich Clementi's cloud computing organization.
But IBM is putting the wood of the arrow behind cloud computing for the core mission-critical applications in an enterprise, its primary target outside of the cloud as well.
There's a bit of an anti-Netbooks meme making the rounds in blogs and on Twitter and the expected push-back from their fans. From where I sit, this is fueled partially by the conflating of product and product category, partially by competitive sniping, and partially by genuine consumer confusion. Let me try to tease those threads apart.
I've been skeptical from pretty much the beginning that there was a bright line distinction between Netbooks and other inexpensive, small form-factor notebooks. And it's this lack of a truly standalone category that analyst Michael Gartenberg is writing about in his provocatively titled "Netbooks R.I.P."
"What's in a name?" Shakespeare asked, adding "a rose by any other name would smell as sweet." While some perceive the netbook as a new product category -- a class of device that's never existed -- I would have to beg to differ. A netbook is merely a laptop with the pivotal axis based on price first and foremost... Sure, my price-oriented definition might sound heretical to those who view the netbook as an ode to cloud computing, ubiquitous usage scenarios, and freedom from Microsoft OS tyranny, but that's not how the market has shaped out.
The current generation of Netbooks tends to have certain defining characteristics--specifically Intel Atom processors and the Windows XP (or Linux). But, as Gartenberg notes, a 7-inch screen also used to be a defining characteristic. Now many Netbooks come with 10-inch screens. Come Windows 7 and future processor generations from Intel (and AMD), I expect any clear distinctions that exist today to rapidly blur.
That's not to say that analysts and product managers won't create a bucket for small, price-focused notebooks. They may call that bucket "Netbooks." They may call it "Value Ultraportables." They may call it "Fred."
IT industry people like to chop markets into named categories for reasons of their own, even if as a fellow analyst said at a recent meeting: "the average consumer calls everything a laptop anyway."
One reason that the nomenclature fight around Netbooks is more intense than such battles tend to be is that the distinction between Netbooks and other ultra-portable notebooks is also a fault line in a competitive battle between Intel and AMD.
For Intel, Netbooks have been the big product category win for its Atom processor. (If a somewhat serendipitous win. Atom was originally more focused on a new class of "Mobile Internet Devices" (MID), a product category that so far hasn't taken off.) For its part, AMD has focused on an incrementally higher price and processing power point with its Athlon Neo platform (found in the HP dv2).
As a result, it's in Intel's interests to promote Netbooks as something new that is both apart from and incremental to the notebooks that use higher-end (and higher dollar) Intel parts. At the same time, it's in AMD's interest to denigrate Netbooks as underpowered and not real PCs.
Finally, there is a continuing trickle of evidence, such as this NPD Group report, suggesting that consumer satisfaction with Netbooks isn't all that great.
Like James Robertson, this latest report struck me as a bit curious. Many of the people I know with Netbooks are almost excessively fond of them. However, it's fair comment that most of the people I know as also geeks, are attracted to the new and different, and understand what a Netbook class of device can do--and what it can't. It doesn't stretch credulity to imagine less educated consumers taking a $300 notebook home and then being dissatisfied because it's not a general replacement for a $1,000 notebook.
Highly portable notebooks without the road warrior premiums historically associated with portability are a great advance for consumers. But I'm also excited about the devices that new screen technologies and widespread wireless connectivity could enable. The possibilities in this space are great. Netbooks are just a flavor of notebook.
We most associate hypervisors and virtualization with servers from their beginnings as tools for development and testing, through their widespread adoption as a means to reduce the number of physical servers needed, to their current stage as a foundation for dynamic IT architectures. Virtualization on the client side has been more of a niche although application virtualization continues to grow in importance and some specific uses, such as running Windows applications on Macs, have proven quite popular.
As for embedded devices, special-purpose computers, virtualization has had essentially no impact.
That's beginning to change. Wind River, one of the major players in embedded operating systems and recently purchased by Intel, today announced the availability of Wind River Hypervisor. From the press release:
Wind River Hypervisor enables virtualization for devices across a broad range of market segments, including aerospace and defense, automotive, consumer devices, industrial, and networking. Within these markets, embedded developers are adopting hypervisors to enable the replacement of multiple boards or CPUs with a single board and/or a single CPU, create innovative new devices that leverage multiple operating systems, and reduce complexity when integrating multicore processors. The benefits of using the Wind River Hypervisor include reduced hardware costs and power consumption, opportunity for innovation, and accelerated time-to-market.
This hypervisor can be employed in a number of different ways on a multicore processor. For example, it can be used to run multiple operating system (OS) and application instances on a single processor as a way of enabling single-threaded applications to access multicore performance.
However, what's probably the most interesting use case is consolidating different operating systems on a single processor--and thereby potentially reducing the otherwise need for separate chips or devices. This hypervisor targets two primary operating systems: Wind River's VxWorks and Wind River Linux. To understand why mixing these two might be interesting and useful, consider the differences between them.
VxWorks is Wind River's proprietary "hard real-time" operating system. It's widely used in places like aerospace and defense (think radar, avionics, and so forth) and the data processing of network gear.
Real-time, in general, refers to operating systems and software that have a very predictable response time to events. Predictability runs in opposition to overall throughput so commercial operating systems have historically not been real-time operating systems. Hard real-time typically refers to the need to have truly guaranteed response with the possibility of failure or damage if a response is not made in time.
Wind River Linux is the company's version of Linux optimized for embedded devices. In 2007, Wind River acquired FSMLabs, a real-time Linux vendor, to augment its Linux efforts. Wind River had earlier had a partnership with Red Hat, now discontinued.
Without going into all the gory details of schedulers and so forth, suffice it to say that the real-time characteristics of Linux have improved considerably over the years. Furthermore, various patches can further optimize Linux for real-time uses. Today, we see Linux in applications (such as this IBM/Raytheon deployment) that would have historically been well outside the realm of even customized general-purpose software.
That said, an operating system like VxWorks retains a specialized focus on real-time and comes in versions that carry stringent certifications. Thus, there are many situations where it may make sense to use VxWorks for those parts of an application that require those certifications or are otherwise better served by the specialized real-time OS. At the same time, Linux may be a better fit for other parts of the application that can leverage the Linux ecosystem for components such as user interfaces.
In addition to having different technical requirements, embedded systems make for a somewhat different virtualization use case than in enterprise IT. In embedded, operating systems remain far more specialized and bespoke and this makes the ability to mix and match them on increasingly powerful and multicore processors very useful. This is another face of increasingly pervasive virtualization.
Microsoft's Server and Tools Business did the virtual conference thing for industry analysts last week. Fellow analyst Judith Hurwitz ably describes the limitations of this format. I concur with much of what she writes.
That said, I give Microsoft props for trying. A lot of companies have canceled or decided not to hold in-person events this year without making any real effort to put together an alternative. Limited interactivity and engagement aside, some of the pre-recorded videos were informative, STB President Bob Muglia was in typical energetic form, and I had good telephone discussions on a variety of topics.
Here are some of my take-aways and observations.
"Costs less" was a big part of Microsoft's pitch. This is consistent with the theme of its consumer advertising. It's also consistent in that Microsoft chooses targets for comparison with some care. For example, Microsoft isn't so much emphasizing low cost in the context of general scale-out infrastructure (where Linux and other open-source software is most widely deployed and popular today). Rather, Bob Muglia emphasized being able to put together solutions with partners at a fraction of the cost of proprietary software; he especially emphasized business intelligence, which has been the focus of a great deal of SQL Server development over the past few years.
Hyper-V. Muglia said that the "first year of Hyper-V being out has been significantly better than I expected." He also noted that it has been "gaining share every day." Of course, Microsoft would have to gain a lot of share to seriously dent VMware's dominance. That said, Microsoft's virtualization solutions (together with those of competitor/partner Citrix) will often be the low-effort path for Microsoft shops. Hyper-V gets a big boost this fall when it gets Live Migration as part of the Windows Server 2008 R2 release. This is Microsoft's counterpart to VMware's VMotion (which allows running VMs to be moved to another physical server without interruption). Even Microsoft will now pretty much admit that this technology is table stakes for a serious virtualization deployment.
Cloud computing was, of course, much discussed in the course of the day. There are a number of aspects to this but I'll focus here on Azure, which I discussed with Steven Martin, the senior director of developer platform product management. Microsoft describes the Azure Services Platform, to use its full name, as a "cloud operating system" that provides a set of services such as SQL database access. A few points from our conversation:
- I hear a lot of concerns about security and privacy in off-premise cloud deployments. Martin notes that payroll was one of the first widely outsourced enterprise applications and Salesforce.com customer relationship management is the poster child for software as a service. Your employee and your customer data--few things are more confidential. This is a great point. It's not that we shouldn't be concerned about cloud security but the reality is that we've been letting third parties access much of our data for years.
- What additional types of services might we see for Azure? Martin highlighted commerce services such as a shopping cart and B2C (business-to-consumer) as something "we talk a lot about." Reporting and compliance was another area he mentioned. "Potentially" but more in the vein of "if customers demand them" is database models other than the existing SQL Data Services. In general, Microsoft sees Azure as bridging internal .NET development and an external cloud so they're probably hesitant to head in directions that don't fit as well with an internally hosted environment.
- One final interesting angle is the intersection between an abstracted cloud computing platform like Azure and multi-core/parallel programming. As I've previously written in a different context, it seems that one of the ways that we'll make it possible for application programmers to deal with the inherent difficulty of writing parallelized code is to provide them with abstractions that handle a lot of the low-level rocket science. Azure and other systems in a similar vein could well turn out to be appropriate abstractions for this purpose.
Those are just the highlights. Other topics we covered included client virtualization (Microsoft seemed more open to possibilities than in the past), Silverlight ("barely nine months in... and will continue to see a gloves off nasty fight with Adobe"), and Microsoft's continued focus on management as its big differentiator around virtualization in general.
What strikes me most about the admittedly somewhat selective set of things that I have highlighted is that it's generally forward-looking. Yes, Windows Server is still at the core of much that STB does, but there's also substantial focus on virtualization, cloud computing, and Web-centric approaches in general. That's a substantial change from a few years ago.
I plan to delve into Hewlett-Packard's new ProLiant SL Extreme Scale-Out (ExSO) line more deeply in an Illuminata Insight over the coming weeks. But it's a significant announcement that highlights some important trends, so hitting some of the highlights of today's announcement is worthwhile.
(Credit: Hewlett-Packard)To start off, it's a new ProLiant form factor that joins existing tower, rack, and blade lineups. Essentially, it represents a shift up to the next lot size of server purchases. In other words, tower servers came first and were often purchased one at a time. Rack servers a few at a time. Blade servers: a chassis worth, maybe 8 or 12 at a time. ProLiant SL is optimized around purchases of a rack at a time.
ProLiant SL also optimizes around the requirements of the sorts of customers who make purchases at this sort of scale. This means focusing on metrics such as performance per watt or dollar or square foot. It also means leaving out the things such customers don't care about. For example, large-scale Web and HPC sites tend to build and use their own management tools. They're looking to server vendors to mostly just provide low-level tooling for monitoring and updates.
For the ExSO debut, HP is introducing three servers that are physically a sort of horizontal blade server--though HP chose to describe them to me as "skinless servers." The servers go into a new 2U z6000 chassis that then goes into a standard rack. (Typically, five chassis at a time will go into a standard HP rack using a 10U bulk rail kit.)
- ProLiant SL160z G6 is optimized for large memory, such as applications that benefit from a large memory cache near the processing
- ProLiant 170z G6 is optimized for large storage, such as for Web search and database applications
- ProLiant SL2x170z is optimized for compute density, such as for many HPC and Web front-end applications
Although no other major vendor has quite the same design approach to high-scale x86 computing, conceptually, there is a great deal in common here with systems like IBM's iDataPlex and Sun's blades.
HP will argue that ProLiant is based on more standardized components, such as standard racks, and can more easily mix and match with third-party components. There is some truth in that assertion. However, from my perspective, what's most distinctive about this product announcement is not so much the particular hardware that HP is selling but rather its context.
Namely, this announcement extends from and builds on supply chains, channels, and the considerable success of ProLiant in the marketplace. What would be a mildly interesting server design from a smaller or less successful server vendor is very interesting coming from HP.
Coming from a technical background, when I hear the word "standards," I tend to think of things that usually go by strings of numbers (802.11), inscrutable abbreviations (USB), or at best a slightly more melodious moniker dreamed up by a marketing department (WiMAX).
They may be codified by a standards body as part of a formal de jure process. They may evolve through the efforts of one or several companies and gain wide enough usage to be considered a de facto standard. Or, as with PDF, they may start life as a de facto standard that is later ratified by a standards body.
Whatever the particulars, such technical standards allow equipment or software from a variety of different sources to work together in predictable ways.
When people talk about cloud computing, these are the sorts of standards that they're usually talking about. The main issue being addressed is portability--the canonical example being moving an application developed for Amazon Web Services to some other vendor's service.
In the Amazon case, a subset of AWS has indeed become a sort of de facto standard. Eucalyptus is one example of implementing a subset of AWS outside of Amazon. Another approach is epitomized by RightScale, which has emerged as a dominant management platform for AWS; it has efforts under way to mask the differences between different cloud infrastructure providers at the management level.
Well-established Web standards of various types also play key roles in creating and accessing cloud-computing services.
So technical standards for cloud computing are indeed moving forward. However, I find that when I talk to consumers of cloud computing, they don't really care much at this point. I noted this previously after I interviewed Tobias Klauder at Razorfish.
That's not to say that people don't care about standards in cloud computing. I led a session at the Massachusetts Technology Council unconference on The Future of Software and the Internet last week to address the question of whether we need standards for cloud computing.
The participants argued that we do indeed need standards. But they had a different sort of standards in mind--something more akin to these definitions:
- an average or normal requirement, quality, quantity, level, grade, etc.
- those morals, ethics, habits, etc., established by authority, custom, or an individual as acceptable
They were looking for more transparency in understanding data protection schemes--backup procedures, recovery point objectives, and recovery time objectives. They wanted to understand what is private and what is not and how data is secured and exported. They wanted this to be communicated in a straightforward manner and, ideally, audited by a trusted third-party in some way.
The issues raised in my session were less about finely tuned service level agreements (SLAs) and more about simply understanding the characteristics of a service. One size does not fit all. Thus, an online backup service such as EMC's Mozy has to offer a variety of options--including whether a user supplies their own encryption key (which itself must be kept secure and protected) or let the service provide one. An organization with specific archive requirements would need other types of guarantees and capabilities.
These are all standards. Some may become true standards over time in the sense of codified best practices and metrics. However, it's clear to me that what users most want in the near-term is to better understand, in plain English, some of the basic practices followed by cloud-service providers.
[UPDATE: Clarification that CA "acquired some of their data center automation and policy-based optimization expertise and assets" rather than the company as such.]
Although it's hardly unique to this area of technology, it seems as if the start-ups in the forefront of developing data center automation tools have had a particularly tough time flourishing as standalone businesses even before the current spending downturn.
The latest casualty is Cassatt, from whom CA is acquiring data center automation and policy-based optimization expertise and assets on undisclosed terms. From Tuesday's press release:
Cassatt's Rob Gingell, executive vice president of Product Development and Chief Technology Officer, and Steve Oberlin, Chief Scientist and co-founder, have joined CA, along with their team of developers, engineers, and other key employees. In addition, CA has acquired several Cassatt patents and patent applications, as well as other intellectual property.
"Cassatt has long been a champion for using a cloud-style architecture to manage data centers like a 'compute utility,'" said Cassatt Chief Executive Officer and founder Bill Coleman. "This is a great move for both organizations because of the vision we share -- delivering a new, dramatically more efficient way to run data centers. The acquisition of Cassatt's data center automation technology and expertise by CA, one of the world's largest and most successful software companies and an innovator in business-driven automation, will help make this vision into a reality for customers."
It's not surprising that someone would acquire Cassatt. The company has been peddling very innovative policy-driven automation software for a number of years now. Along the way, company execs have updated their strategy more than once with an eye to making their technology more consumable and more directly responsive to near-term IT concerns.
For example, the company packaged together a product specifically oriented around data center power optimization. More recently, it has spun its story around the idea of constructing private clouds.
Automation technologies such as Cassatt's address very real problems. But they're tough for a small company to sell for a couple of reasons.
The first is that they remain on the leading edge of the adoption curve. Large IT departments are indeed handing off more and more operations to their management software. But relinquishing control of data center operations has long been a slow and incremental process.
The second is that automation software is primarily interesting at large scale. If you only have 10 servers, you probably don't feel a pressing need to automate. It's when you have a thousand servers and you can't run things manually any longer that you are most driven to turn to software for help.
But adopting a management platform for large swaths of a data center is a big commitment and requires a level of trust that enterprises are more likely to place in a CA, Hewlett-Packard, or IBM than they are in a start-up--however great the products.
The result is this, as CNET Blog Network blogger and former Cassatt employee James Urquhart noted in late April:
In the end, though the pipelines were always big, the deals dragged on for months and months and often failed to close in the end. Coleman himself acknowledged as much in the Forbes.com article:
"What frustrates me is my own naivete," he says. "I thought I could give companies something radical that had a proven return on investment, and they would be willing to change all their companies' computer policies and procedures to get that. Right now it's hard to get people to get beyond proof of concept tests or a data center energy analysis."
From CA's perspective, it seems like a good acquisition. The traditional management players such as CA, BMC Software, and Symantec have not been at the forefront of the real action in the data center the past few years. Virtualization and other technologies that largely came in from the grassroots level have had far more impact of late than enterprise-spanning products such as CA's Unicenter.
All of these companies have been fighting back, but they've had to make up for seriously lost momentum. Cassatt brings CA some very good technology that CA should be in a better position to get into the hands of customers than Cassatt ever was on its own.
I've been getting a fair number of questions about multi-threading the past couple of weeks. The reason is that Intel has been previewing its "Nehalem EX" Xeon processor in advance of Advanced Micro Device's six-core "Istanbul" CPU launch. Intel's Nehalem generation has simultaneous multi-threading (SMT)--which Intel calls Hyper-Threading (HT)--while Istanbul does not.
I wrote about this topic in depth a couple of years back in "Gradations of Threading," but it's worth reviewing in the context of these new server processors.
First, a little terminology.
A thread is a sequence of instructions that can execute in parallel with other threads. The details of what exactly constitutes a thread and the relationship between threads and other structures such as processes vary by operating system. However, for our purposes here, think of a thread as an independent task.

Simultaneous multi-threading.
(Credit: Illuminata)A core is, in most respects, a complete processor that includes all the hardware such as execution units, registers, and so forth required to execute a sequence of instructions. Although multiple cores on a single die or in a single package (i.e. a chip or socket) may share certain resources such as cache memories, logically each core is a full central processing unit (CPU). That multiple cores are packaged together today is essentially an implementation detail that relates to getting the best performance out of the most economically sized silicon die.
Absent multithreading, each core can execute one thread at a time, running that thread until it has completed or until the operating system scheduler swaps it out for another thread.
SMT changes that 1:1 relationship. On a processor with SMT, more than one thread can execute on a single core at the same time--in the case of HT, it's two threads per core.
SMT potentially allows a processor to be more efficiently utilized. The reason is that modern microprocessors have multiple execution units within each core. For example, they have separate logic to handle integer operations and floating-point operations. Thus, in principle, if a thread with mostly integer operations runs concurrently with a thread that mostly crunches floating-point numbers, we could keep the processor busier by running both threads at the same time than we could running them sequentially.
The other main benefit is to hide memory latency. CPUs have to operate on data and that data has to ultimately come from memory or disk. Computer designs incorporate all sorts of techniques--such as caches and prefetching--to keep data close to processors in time and space. Nonetheless, processors still spend a lot of time waiting for data to arrive from relatively pokey memory. SMT lets a CPU quickly switch away from a thread that's sitting idle waiting for associated data to arrive.
SMT is therefore essentially a technique to use a processor more efficiently. It does not itself add execution resources to a core. And, in fact, the duplicated hardware and other logic that SMT requires to function (such as registers) takes space away from implementing other features (such as larger caches) that could themselves provide alternative ways to boost chip performance.
Intel's HT implementation--a fairly "lightweight" approach relative to IBM's on its Power processor--uses on the order of 5 percent of the total chip area to deliver typical performance gains of between 10 and 20 percent. (Optimized applications can see bigger gains. On the other hand, applications that are already efficiently using the CPU's execution units--or that are bottlenecked in ways that SMT can't assist with--may see no gain at all.)
Ultimately SMT is just one performance feature among many that may or may not be a match for a given processor's design. In Intel's case, it's been in some x86 designs but not others since it debuted on the Pentium 4; Itanium uses a simpler Temporal multi-threading approach.
SMT's in the plus column of the features checklist. But what really matters is overall processor performance on relevant workloads and platform capabilities. SMT is one tool to get there.
Not long ago the infrastructure pieces needed to construct a data center were pretty straightforward--Computer Room Air Conditioning (CRAC) units, power conditioning equipment, uninterruptible power supplies (UPS), and electrical and plumbing to tie it all together. It wasn't unimportant. But it was largely a well-understood extension to the HVAC infrastructure of a typical commercial building.

That's changing in a big way for two major reasons.
The first is that servers may have gotten smaller but IT shops are trying to cram ever more of them into a given space. The result is that more power has to be delivered to and more heat taken away from ever smaller volumes of space.
The second is that data center operators are starting to factor power efficiency into their buying decisions. Power Usage Effectiveness (PUE) has entered the lexicon as a metric for evaluating how much of the power delivered to a data center goes into running the computers themselves as opposed to the infrastructure needed to support them.
In short, figuring out innovative ways to build efficient data centers is suddenly sexy. I've been offered more tours of data centers in the past year by companies such as Intel intent on showing off newly developed approaches to cooling and modularity.
Thus, it's not especially surprising that IBM is now announcing that, together with Syracuse University and the state of New York, they "have entered into a multi-year agreement to build a new computer data center on the university's campus that will incorporate advanced construction and smarter computing technologies to make it one of the most energy efficient data centers in the world. The data center is expected to use 50 percent less energy than a typical data center today, making it one of the 'greenest' computer centers in operation."
The $12.4 million, 6,000-square-foot data center will have on-site electrical co-generation system that uses a natural gas-fueled microturbine engine to generate all the electricity for the center and provide cooling for the computer servers.
Syracuse will manage and analyze the performance of the data center, "as well as research and develop new data center energy efficiency analysis and modeling tools. IBM will provide more than $5 million in equipment, design services and support, which includes supplying the electrical co-generation equipment and servers such as IBM BladeCenter, IBM Power 575, and IBM z10 systems. The New York State Energy Research and Development Authority (NYSERDA) is contributing $2 million to the project."
This will be an operational data center, albeit a relatively modest-sized one compared to mega-service provider facilities. (New Microsoft and Google data centers are reportedly in the 100,000- to 500,000-square-foot range.)
This may not be a particularly surprising announcement given the level of activity in this area. But it's nonetheless notable that an aspect of computing that was, in many respects, a sleepy backwater of incremental advance and its own impenetrable jargon is suddenly the subject of lots of new fundamental research.
Irving Wladawsky-Berger, chairman emeritus of the IBM Academy of Technology, offers what I think may be the best way to think about the evolution toward cloud computing.
We should view computing models much more like forests than trees. These computing model forests have a variety of different trees, and the transition between them is gradual, not abrupt. With the passage of time, as you walk around them you begin to see new trees, but the old ones are still around. But one day you realize that the forest you are now walking through is markedly different from the one you were in twenty years ago.
Put another way, it's a piecemeal evolution--neither a new term applied to the same old thing nor an overnight sea change in the way that all computing is done. Terminological debates will doubtless continue. And there are plenty of unanswered questions about exactly which new "trees" will thrive and which will die out. However, we're starting to see come consensus emerge around at least some broad outlines of the cloud's evolution.
As Irving wrote after the recent MIT Sloan CIO Symposium:
A lot of the benefits of cloud computing, such as virtualization, shared infrastructures, highly disciplined systems management, flexible deployment and scalability are of value to just about all data centers and service providers, whether you run them as a private clouds providing services to only members of the company, or as public clouds open to everyone. There is also general agreement that you should make cloud deployment decisions on a case-by-case basis, especially decisions as to which applications should be run on private versus public clouds. Public cloud deployments make the most sense for highly commoditized, standardized, mass customized applications.
There was also a broad consensus that infrastructure savings and flexible scaling where key adoption drivers for cloud computing. One panelist remarked that "The benefits of cloud computing start and end with the dollars you can save. But it can also help getting your best people away from working in areas that can be outsourced to the cloud. This way you can allow your best people to focus on an area that drives differentiation for your company."
There are a few points that I'd like to highlight:
Cloud-like computing architectures within organizations are garnering a lot of interest. Whether you call them "private clouds" or just the next iteration of service-oriented architectures (SOA), the bottom line is that organizations--especially larger ones--are far more interested in leveraging the approaches embodied by cloud computing than they are in actually hosting their applications elsewhere.
There's also interest in the public cloud, but primarily for standard off-the-shelf applications. This is, in fact, wholly consistent with the pattern of IT outsourcing going back years. Payroll was perhaps the first application to be farmed out in a widespread way. Important? Sure. But also largely standardized and in no way a source of competitive advantage.
Distractions matter. Enterprises can arguably do a lot of things as cheaply in-house as can a third-party. However, do too many non-strategic things and you have the corporate version of too much "stuff" rattling around and getting in the way of what's really important.
It's arguably been the dramatic "Big Switch" take on cloud computing that has led to so much of the hype surrounding it. But it's arguably the enabling technologies--as adopted in thousands of distributed organizations--that are more relevant for any reasonable planning horizon.





