Feed on
Posts
Comments

Red Hat CTO elaborates on lofty ‘cloud’ vision discusses the effort Red Hat is making to engage its customer base on Wall Street:

“In terms of engaging its customer base, for example, Red Hat has worked with Wall Street’s financial institutions to simplify data center operations by capturing a single operating system image, including hardware and software. The payoff: IT has only one image to update and manage, which can be deployed across the network, he said. Currently, Red Hat is testing this technology by burning an OS image onto a USB key and using it to boot up servers, desktops and laptops, he said.”

The thing to note that an effective virtualization strategy does not virtualize the existing, diverse landscape, it redeploys into a highly standardized infrastructure with uniform configurations. Furthermore, the effective process involves discovering the 80% solution, the small set of standard virtualization strategies and standards, that meet the vast majority of workload requirements for the target workloads.

Technorati , , , , , ,

Zero Data Centers

I just stumbled upon a curious headline “Sun Plans To Close Its Data Centers” describing a post by Brian Cinque. Brian’s post was about Sun’s aggressive work within SunIT to reduce data center costs, including power and cooling requirements as well as the continuing vision of utility computing as seen by SunIT. The program has a target of zero Sun data centers by 2015.

The blog post was a healthy perspective on the future of SunIT from the viewpoint of the writer as an architect in SunIT operations, not Sun Microsystems in its entirety. That is, there will surely always be a need for Sun to maintain infrastructure internally to develop the machines and products that Sun sells to its customers to service their businesses. These businesses include Sun’s own business operations though SunIT.

Does SunIT need to own and manage its own data centers for all production systems, all desktop infrastructure and all other Sun business operations? Sun needs this capability no more than any other business for most standard business operations, but Sun certainly does need data center footprint insofar as it assists Sun in developing and perfecting Sun technology for sale.

For example, my home directory is managed on a very busy SunIT managed server running the bleeding edge of Nevada. This is good for Sun’s customers and good for Sun’s strategic ability to understand and develop solutions for our customers. We drink our own kool-aide before we sell it to our cstomers. Does everyone at Sun have their home directory on a server at or close to the tip of Nevada? Certainly not. Most of the Sun home directory infrastructure is on standard Solaris, current generally available release.

Will it always make cost effective sense for SunIT to manage typical, generally available, home directory infrastructure on captive hardware in SunIT managed data centers? Perhaps not. Sun certainly has a right, and an obligation to its stockholders, to leverage the same cost-effective utility and cloud computing models that Sun is helping to develop and foster. Again, to be clear, I’m not referring to SunIT participation in the management and maintenance of bleeding edge Nevada or whatever happens to be the next generation of Sun infrastructure and Sun software. This sort of activity is, and likely always will be, a valuable SunIT contribution to Sun’s ability to serve its customers.

Somehow, the healthy reduction in Sun’s compute footprint, increasing utilization, lowering costs, reducing the number of data centers, including through vendor managed Sun servers, is by some erroneous extension an indictment of Sun products and services. I don’t get that at all. If computing with Sun products and services is simpler, easier, less expensive, and enterprise services and applications can be more rapidly provisioned and are less expensive to manage and operate than the competitive products, won’t the world need a lot more Sun servers? Does it really matter where these servers are housed? Have the laws of supply and demand been repealed? What am I missing?

Somehow it seems that housing and managing servers has a value proposition that can only be met by captive IT operations. I don’t get that either. The truth is we are facing a future where computing will be 25kW a rack or more for fully populated racks, roughly 5 times the current, typical rack power densities and data center power designs. True, these densities come with beneficial orders of magnitude increases in compute capacity, but is a 5kW per rack data center with a few servers per rack sensible? This reality challenges the physics and financial viability of in-house data centers. As computing demands continue to increase, the laws of physics and economics will tend to compel more and more data center consolidation, probably as close to power plants as possible to increase efficiency ad reduce line loss. In the future, power will cost more than the computer hardware, utilization rates will have to improve, and new application deployments will have to take minutes not months. None of this should be news to anyone.

Knowing this, the preponderance of negative and emotional reactions to Bran’s post have all at once puzzled, surprised and alarmed me.

Some of the more telling reactions are “Is this half-baked plan/news something you should post in a public blog. Moron!” and “you’re confusing some people ….” or “Look how foolish parts of Sun’s management behave…” These are fearful reactions. These seem like reactions from people who find their cheese is moving.

If so, I agree, your cheese is moving.

Perhaps the wording in the blog itself, or the preponderance of other trade press and blogs elsewhere regarding industry trends have been unclear, but whether it is 2015, earlier or later by a bit, the world view though the looking glass of captive enterprise data center computing, just like the now defunct view of the world through mainframe glass-house computing, is approaching its end. We will still obviously need general purpose computing infrastructure and data centers somewhere, but what is it about the way we currently provision and manage computing infrastructure that is immutable or unassailable? What is it about the likely end-games and outcomes for current direction of the industry, and trends toward utility and cloud computing, SOA and SaaS that is confusing, hard to understand, inscrutable or surprising?

If all the business and technical mechanisms were in place today to enable businesses to use utility and cloud computing securely, cheaply, quickly and efficiently, eliminating the need to design, build, staff and maintain costly and complicated captive data centers, why would the data center as we know it today exist? What is so insanely great about owning and managing a data center that, in the future, provides no strategic advantage to the business that owns it? Are all of the IT departments, mechanisms, operations and infrastructure patterns of today somehow more entitled to survival than the glass-house operations they replaced? I think not.

Admittedly, all of the mature mechanisms for all enterprise computing to be provisioned external to the enterprise on a compute grid are not yet here. We face plenty of technical and physical challenges, but it seems like, based on the sort of reactions seen to Brian’s post, the political challenges to the changes will be the greatest.

One example given as an objection to “zero Sun data centers” in the blog post reactions was a question concerning how would Sun host it’s own Sun Ray desktop infrastructure on some vendor managed compute cloud or utility facility. The challenges to this are more around data security than around network performance and latency, since much of Sun’s work at home staff already use Sun Rays connected though VPN and high-latency broadband or DSL connections to the Sun network. Also, as a corollary trend, I can assure you that as high-speed wired and wireless networking becomes more ubiquitous, I’ll be eying a Sun Ray laptop. Lugging around gigabytes of disk will become silly, needlessly backbreaking and dangerous. I’m not alone. Several of my colleagues in various Sun groups have been playing with this technology. In any event, my Sun Ray needs an IP address that provides my desktop services, not a data center. How the service is provided and where the service is on the network is irrelevant to the Sun Ray or me as a desktop user.

As the business and technical solutions for data and network security in virtualized, multi-tenant environments mature, nothing stands in the way of hosting Sun Ray sessions on vendor managed infrastructure. In fact, because of Sun’s ruthless elimination of heavy-weight desktop infrastructure in favor of Sun Ray, Sun is in much better shape to leverage and execute on utility or cloud computing for desktops than most businesses.

I’d put a much different spin on the problem of secure cloud computing or, more correctly, the opportunity. What if we could dynamically create networked computer environments that we could share securely with selected customers, vendors and partners? What if we could create virtual data centers, just for individual projects, programs or any business interaction, in a few minutes? The problems going forward revolve around dynamic management of secure, persistent interactions and virtual computing facilities for any imaginable grouping of individuals, groups and businesses. Do you really think this is a pipe dream? How far are the current social networking technologies from this reality?

I imagine the biggest problem people are having visualizing the not-too-distant future state comes from comparisons to the currently prevalent enterprise outsourcing models that are, in my humble opinion, largely a wrong-headed, expensive disasters. Simply turning your data center staff and equipment over to a vendor doesn’t add a lot of value, or at least not very interesting value to me.

A better sense for the future can be gleaned from visualizing a developer writing a Ruby on Rails or PHP application for deployment to a full-service Solaris Zone or “kernel in user space” provider on the Internet or Facebook, Amazon EC2 or some other “social networking” framework. How great is the leap in technology and vendor capability to an enterprise developer deploying an application to an external host for use by an internal department or selected partners? Not very far, I think. In fact, surprise of surprises, it is already happening.

On more than one occasion, my group has “turned up” small but important applications that our customers’ business departments are hosting externally as part of our application inventory efforts supporting consolidation initiatives. How much easier, cheaper and secure does the application outsourcing avenue need to be before this trickle of occasions becomes an avalanche? The IT departments where this has happened are almost always dismayed and surprised, but then again, they maintain inventories of servers, not applications, right? How would they know what is going on with their customers?

The best, albeit weak, argument I’ve heard against this trend is the lack of control and security presented by externally hosted applications that is required by regulatory drivers like Sarbanes-Oxley. This is true, but not compelling, and sounds more like an excuse than an argument. Do you think the right, bright hosting vendor in the not-too-distant future might enable better, more cost-effective, configuration management, security and control than many IT operations?

Here is the bit that surprises me the most about the surprise. There is very little discussion of why this happens and how to provide the types of IT services the business needs to avoid these situations. Is enterprise IT is entitled to provide all computing services for all time solely in its captive or traditional out-source data centers? We live in a competitive, capitalist economy, where innovation rules, and the pieces are coming together for disruptive changes to the way enterprises purchase and manage computing.

To me, the visceral reactions to Brian’s post are far more alarming than the prediction itself. The reactions indicate we have a long way to go in this industry to embrace the inevitable changes that are coming. If you don’t want your cheese to be moved for you, you had better move it yourself. Enterprise IT needs to find more innovative ways to provide secure, rapidly provisioned, highly-available, cost-effective solutions to its business customers before the world overtakes it. Sun is working furiously to support all enterprises in this effort with products and services designed to address these needs. SunIT is working furiously to deploy and use Sun’s products and tools first, both to reduce Sun’s internal IT costs and to support Sun in developing and delivering field-proven products to its external customers.

Perhaps the current trends to virtualization will soften the blow for many, but those of us that don’t make the inevitable shift away from managing servers to managing services may not find their cheese.

Technorati , ,

The typical method employed for migrating existing workloads to ESX from physical machines involves instrumentation of the workload in the current environment, coupled with technical and business analysis to determine:

  • Workload suitability for virtualization
  • ESX resource requirements to support the workload

The technical resource sizing method most often used leverages the VMware Capacity Planner. VMware capacity planner employs an offsite analysis of the workload in a VMware hosted service. This service utilizes collected VMware Capacity Planner metrics for over 20,000 machines, coupled with experience with factors affecting virtualization and ESX resource utilization, to provide a “black box” solution to consolidation target composition.

The solutions provided are generally accurate enough to substantially mitigate risks associated with oversubscription of ESX resources. Typically, organizations are able to migrate with minimal additional empirical workload testing from the physical server to the ESX virtualized environment.

Organizations that cannot use the VMware Capacity Planner facilities for workload analysis, due to policy or technical constraints that disallow the use of the VMware offsite analysis facility, must employ more elaborate and extended empirical testing of workloads to ensure that virtualized workload is suitable for VMware virtualization in the targeted configuration.

“VMware Migration and Consolidation Without the VMware Capacity Planner” discusses the issue and provides an approach for managing migration risks when the Capacity Planner is not an option.

Technorati , , ,

Red Shift Virtualization Drivers

Vladis’s Blog has just posted an entry on good and bad reasons to virtualize titled “Virtualisation, comfortable or tight trousers“. I’d like to elaborate on the subject a bit.

Vladis mentions several important drivers supported by measurable, direct IT operational cost reductions, typically enabled by:

  • More efficient use of the existing server footprint through higher utilization,
  • More efficient operations through reduction in the number of physical servers,
  • Peak utilization of a large number of servers is low, and
  • Reduction in power and space consumption.

The blog rightly recommends sticking to a “by the numbers” approach to determining suitability of your situation for virtualization, and also mentions the tools we have for helping customers with consolidation and virtualization planning. In fact, I happen to work for a customer facing group in Sun that focuses on this topic. We use these tools for customers on a daily basis.

Although “below the line” kinds of IT cost initiatives are typical, they are not the only good reason for what I prefer to call optimization. Why optimization? Because optimizing for direct IT cost metrics is a subset of the overall discipline of optimization, and a business may actually have other things it considers in the optimization equation.

Agility

Business concerns outside of IT may have strong impacts on optimization initiatives. The most prevalent drivers in this area revolve around needs to increase IT agility and capability to quickly meet business demands. The typical virtualization scenario here is the ability to deploy applications with configuration versus procurement; deploying a new application does not necessarily cause IT to go procure hardware, generally at least lowering the time to deploy new applications.

Strategic Advantage

Businesses that are able to lower barriers and costs to automate will create greater internal demand for new IT services. Businesses that operate with higher business capabilities derived from automation disadvantage their competition. This is a Red Shift thinking: IT is a competitive weapon.

Above the Line Thinking

The real ability of IT to accomplish these sorts of optimizations has a lot more to do with IT understanding their customers than technology, and some of the business process related issues can be somewhat stickier. IT departments that are structured entirely as cost centers are particularly disadvantaged: how does an IT department, constructed as a cost center, go about developing their department as a “business within a business” to better serve customer demand?

Being wildly successful with this sort of optimization requires more than bright ideas, it requires reconstructing the IT organization, IT thinking, and the IT financial model to support the effort and the revised thinking.

Nonetheless, success on the revenue side of the business equation starts simply. We, as IT professionals, need to stop looking at our feet. A lot of good flows from a little opportunity exploration, and in many cases, a simple by the numbers approach from the revenue side of the equation can quickly move mountains. Take a walk on the wild side, the Red Shift side, the making money side of the equation. Making the company money is a good and righteous lever.


Technorati , , ,

The large array of Sun platform choices for modernizing older SPARC implementations has a consequence: discerning the correct path, based on your particular situation. There are pros and cons to every approach. For many operations, the most difficult fork in the decision tree is deciding between Sun CoolThreads (CMT) and SPARC 64 architectures versus Sun platforms with x86/x64 processor architectures. This is particularly true for enterprises with existing Linux x86 implementations on competitor platforms facing technology upgrades of aging SPARC infrastructures.

This is a revision of a brief Sun put together for a customer as part of a consolidation workshop. Note: my colleagues Teresa Major, Christine Tran, Cecil Jacobs and Matt Fifer all contributed to the original brief.

Although this analysis presents a strong bias toward SPARC, the point is to provide points of reference for a reasoned discussion for enterprises making strategic decisions around large-scale processor architecture decisions related to consolidation and optimization. I love my x4100 and my Intel Mac, but there are larger, serious considerations in play when dealing with estates of hundreds or thousands of servers, strategic IT decisions and large, enterprise workloads.

  1. Deployment of compiled applications from SPARC to CMT and SPARC64 is a simple migration, re-deployment from SPARC to x86 requires more complicated steps such as re-compilation. For customers re-deploying from SPARC Solaris to Solaris x86, the Sun Source Code Compatibility Guarantee significantly reduces the risks of changing platforms to Solaris x86 versus full porting to other operating systems such as Linux. However, there are still risks presented by migration from SPARC to x86/x64 architectures versus simple platform change to a more modern version of the same SPARC T1 processor architecture.
    1. Data migration must account for byte ordering and byte alignment differences between the x86 and SPARC processor architectures.
    2. Re-compilation will require source code, which may not always be readily available or known to match the current deployment.
    3. Dependencies on all third party SPARC libraries and tools must be satisfied by equivalent x86 libraries that may be difficult to acquire or may not be available in the older, currently deployed versions.

    The impacts from re-compilation requirements for transition from SPARC to x86/x64 may even exist at some level for architecture-independent J2EE and Java implementations, since many organizations include the practice of re-compiling applications as a preliminary step to production deployment. This at least implies adjustments to the pre-production build processes and configurations as part of a processor architecture change.

  2. The Niagara uses 72W and provides 32 threads (virtual CPUs) per socket. It can do the same work as an x86/x64 architecture machine for less power. The same advantage of newer CMT designs over x86/x64 processors will persist for the foreseeable future. However, this general advantage of the CMT architecture efficiency can’t substitute for empirical workload characterization against various processor choices for the best choice; the power use of a system is extremely sensitive to the workload. Parenthetically, any organization with data center power and space constraints, which is almost every one I see, should be including CoolThreads machines in its evaluations. If there is any single factor most likely to influence structural changes to an enterprise’s processor architecture strategy, it is the serious and growing issue of power efficiency.
  3. Solaris has excellent ISV support. Solaris on SPARC has over 4300 applications shipping as of October 12. While ISV enthusiasm Solaris on x86/x64 is growing, there were about 2600 applications for x86/x64 shipping as of October 12.
  4. SPARC systems have greater RAS (Reliability, Availability, Serviceability) than X64 systems with features such as ASR (Automatic System Recovery) and predictive self-healing. Sun x64 systems have many innovations that implement higher RAS characteristics than similar, competitive x64 products, such as hot-swappable and redundant hard disk drives (when RAID is used), fans, hot-swappable and redundant power supplies, and hot-swappable I/O cards and components available in the x64 blade servers, particularly when running Solaris x86, but these capabilities lag overall SPARC systems RAS characteristics and features in all product lines.
  5. CMT and SPARC64 run several Linux variants, including Ubuntu and Gentoo, diluting the value proposition of alternate open source UNIX variant availability for x86/x64 platforms versus SPARC.
  6. The CMT servers support Logical Domains (LDOM), which allow for simple server micro-partitioning of CPU and memory resources. SPARC64 platforms support Dynamic System Domains (DSD), which allow for socket partitioning of machines. There are no x86/x64 platforms with a similar capability.
  7. Logical Domains (LDOM) and SPARC64 Dynamic System Domains (DSD) provide a greater degree of isolation between OS environments than Solaris Containers, xVM, Xen or VMware virtual machines. LDOMs are only available on Sun CMT processor architectures. Dynamic Domains are only available on Sun-Fujitsu SPARC64 platforms. This virtualization strategy decision point revolves around a stress between isolation, efficiency and utilization: it is generally simpler to leverage excess capacity with Solaris Containers, xVM or VMware vs. LDOMs. However, it is generally simpler to implement, manage and operate statically defined LDOM and DSD resource pools. LDOM and Dynamic Domain availability may be a stronger factor in the decision making process for operations attempting to virtualize and consolidate multi-processor, one-machine, one-application services and workloads, since the simple application of static, fixed resources to an application or service using LDOM or DSD may out-weigh the business and operational implications of the efficient sharing of resources between business units using Solaris Containers, xVM, Xen, VMware or other similar technologies. CMT and DSD capable processors represent the greatest possible flexibility and the deployment architecture can leverage the full complement of virtualization methods: LDOMs or DSDs and Solaris Containers, as appropriate.
  8. The vitality of the SPARC roadmap versus various vendors x86/x64 plans is not a valid basis for comparison of the options. The SPARC lineup and robust roadmap is supported by a growing Sun Microsystems and a growing, vibrant developer community. SPARC has a well defined, published, and committed roadmap of innovation that extends well beyond 2011. This roadmap includes:
    • the sun4u SPARC64 processor and SPARC Enterprise line from Sun-Fujitsu,
    • the sun4v T1, T2, multisocket T2 (”Victoria Falls”) from Sun, and
    • the sun4v ROCK processors from Sun.
  9. The complete range of scaling choices for SPARC and CMT is unmatched in x86/x64 implementations. The recent announcement of 64 thread implementations reinforces this growing advantage of SPARC over x86/x64. The current and future product lines based on the SPARC instruction set range from single socket systems to multi-socket, massively scalable systems with over a terabyte of RAM and hundreds of execution threads, all of which can run any application supported on SPARC. This range of vertical and horizontal scaling options may be a factor for organizations that have both types of application workloads that wish to limit the proliferation of processor architectures in deployment as much as possible.
  10. The sun4v architecture provides the mechanism for presenting an abstraction of the hardware layer to the Solaris operating environment, making it much easier to deploy new hardware platforms based on sun4v while continuing to use the same version of the Solaris OS for extended periods of time. This reduces the risk of having to do another migration in the future just to take advantage of newer, faster hardware.
  11. Sun’s commitment to open source across all parts of it’s business and product offerings includes the processor design for the UltraSPARC T1. This has already resulted in a binary compatible third-party embedded solution.
Technorati , , ,

Constructing content for IT workshops is almost always best done by casting the objectives against two key approaches:

  • Cast the content and delivery in the context of the classical design, develop, test and implement engineering cycle components.
  • Cast the delivery in the context of classical optimization exercises, or more modern 6 Sigma DMAIC or DMADV elements.

For example, an IT workshop covering an IT consolidation initiative should be treated like any optimization exercise. You start with an understanding of where you are and where you want to be, develop methods for measuring your current baseline and determining success, and work though design alternatives that achieve the targeted success criteria.

For consolidation, the baseline consists of a thorough, documented accounting of the current infrastructure assets, applications, IT tools, operations processes and operations capability. The target or target scenarios look at the gaps between the current landscape and the desired landscape. Workshop activities can then be cast against any or all of these elements: understanding the measurable goals, exploring the pro’s and con’s of technical alternatives, discussing mechanisms and procedures for uplifting operational capability where required to support the target state, etc.

This approach, along with the assumptive role as a element in a change initiative, facilitates the proper construction of workshop attendance.

  • You need the smallest number of people required to have enough subject matter expertise to tackle the subject matter
  • You should have the audience most likely forming the Kotter style “guiding coalition” for the initiative.

Given the complex, multidisciplinary nature of IT initiatives, typical ideal “guiding coalition” attendees include:

  • Sr. System Administrators
  • Sr. Network Administrators
  • Application Architects
  • Sr. Security Administrators or Architects
  • Sr. Database Administrators
  • Sr. Application Infrastructure Architects and Operators
  • Business Application Owners
  • Executive Sponsor

Ideal workshop attendance should result in a total “guiding coalition” head-count of between 5 and 7. Additional head-count should be expected for subject matter expertise as well as facilitation skills.

Technorati ,

At some level, going to the Rails Conference has brought out the absolute worst in me. This is mostly because people ask me what I do, and I’m with an audience where I can really tell them.

In the keynote this morning, Cyndi Mitchell described the current state in IT as being bloated and corrupt. I live that life, and although I share the perspective of “bloated”, I think my spin on “corrupt” is closer to the meaning of the word as devolved and degenerate, as opposed to the one I think she meant.

Cyndi Mitchell

My group at Sun is tasked with helping customers find ways of reducing space, power and cooling costs in data centers, which sounds helpful and nice, but it doesn’t really work out that way in real life. Increasingly, the situations we deal with are quite desperate. There is no more space or power. Data center power and cooling costs are bankrupting the companies they serve. By the time we get involved in these situations, and by the time my group shows up, we are facing a pretty tense crowd (mob?).

But here’s the problem. There is no silver bullet for these situations. The typical troubled data center is a sprawl of different architectures, configurations and nuances of the software and IT services that make them up, belied by even in the most seemingly homogeneous row-after-row of machine-after-machine, all just the same, data centers. If you could visually see how the applications and services in these operations are frequently constructed, it would look more like something from a Mad Maxx movie. The shiny machines are a thin veneer over the underlying rust and corruption.

The other thing you don’t see, when you look at row after row of shiny machine, is that all those machines, in aggregate, run at less than 10% utilization. Its like a national political convention without an air conditioner. What you are really looking at is an expensive bank of fans blowing hot air on stuff doing very little work. What a waste.

We actually can frequently replace large power hungry machines with smaller, more efficient equivalents, but these “tech refresh” approaches are likely to further reduce utilization; new machines are typically more powerful than the machines they replace.

Now, to be fair, not all operations run this way, but then my group never sees them. These operations never get in this mess. They have architectural governance and discipline. They have actual management of the technologies that their business operations require, at a much deeper level than simple vendor selection of software and hardware products. The other thing to be fair about is that most operations are at some future generation of the architectures they inherited: that is, the current operators can’t be fully accountable for the messes they’ve inherited.

What we see at a macro level is not a design, but a corrupt evolution. If what we see were a design, and if it really was actually designed, I like to I think it would have been designed at a happening. If the applications and services we see were designed, they would have been designed by a group of people that got together, dropped some acid, and drew it up on a bar napkin.

The result is, with apologies to Hunter S. Thompson, god rest his soul, is fear and loathing in the data center.

The point is, you don’t just consolidate this stuff without doing something about the chaos. There is no silver bullet. That fact doesn’t actually help our group at Sun that much, our customers and account teams don’t really want to face this, and both will persist in whatever they need to do to avoid “fixing” the situation. Its just too costly and painful.

Legitimately, many of the things that must be done to architectures to clean up the mess don’t add a lot of immediately visible business value. If you were call the business unit to talk about “fixing” his service in these situations, they really do not understand. Functionally, the Mad Maxx service is working fine for him. Don’t touch it. They remember, all too well, how hard it was to get the service up to begin with.

It’s refreshing to be at the Rails Conference, talking to folks about building brand spanking new applications. I pray that these new Rails applications, in some huge flood of data center Darwinism, will wash away a lot of the nastier things we see now.

Tim BrayThis will happen only if we do a good job of deploying and managing Ruby in the data center at a macro architectural and integration level. This was the key message to me from Cyndi and Tim Bray in the keynote this morning.

So when I go on and on about deployment, security, backup and recovery, performance, scaling, management and monitoring, and as you fall gently into a restful slumber from my oh-so-boring diatribe, please humor me. I must retain some shred of hope for salvation from what we see in the data center now. Deploying new things like shiny new Ruby applications and services present huge opportunities to deal elegantly and effectively with this boring stuff.

Technorati , , , ,

Server infrastructure consolidation requires analysis of factors beyond the attributes of the servers themselves. Operations and maintenance costs for server infrastructure are important factors, but other factors orthogonal to these attributes will have a large impact on ranking servers for consolidation.

This is particularly true for phased consolidation of servers in the data center, the most likely approach for larger data centers. Certain servers are likely to be more favorable than others for consolidation based on factors like

  • the type of applications running on them,
  • the business units using them,
  • life-cycle considerations for the applications,
  • network and security concerns, and
  • the release management role of the infrastructure (development, test, production).

Optimization is an iterative process, with each successive cycle seeking to achieve the maximum benefit for the expended effort.

Server Ranking High Level Structure

The most effective approach to forced ranking of servers for consolidation must include the additional dimensions of business, life cycle and application service costs in order to resolve to the best optimization candidates, strategies and scenarios.

The diagram presented here does not fully elaborate all of the attributes for the major components of an effective ranking tool, but provides a few typical attributes that are likely to be important in any situation.

The schema has three major axes, the server, the application and the group. The group is an arbitrary collection of servers and applications based on criteria important to stakeholders in the organization, over and above conventional cost factors like server and license costs.

The two axes of server and application may be sufficient in most cases, particularly if groupings are completely disjoint and can be handled by attribution of the servers and applications themselves. The examples given for grouping in the diagram are not very compelling: a given server typically belongs to one business unit, and is only used for one of the release management stages.

Technorati , , , , , , ,