Archive

Posts Tagged ‘data center’

What’s a private cloud anyway?

February 4, 2011 2 comments

So in a perfect world all data centers be magically become clouds and the world is a better place. All kidding aside..I am tired of all of the hype. Let me put it this way.  All data centers cannot and will not become private clouds– at least not for most typical companies. Let me tell you why I say this.  There are some key principles of the cloud that I think are worth recounting:

1. A cloud is designed to optimize and manage workloads for efficiency. Therefore repeatable and consistent workloads are most appropriate for the cloud.

2. A cloud is intended to implement automation and virtualization so that users can add and subtract services and capacity based on demand.

3. A cloud environment needs to be economically viable.

Why aren’t traditional data centers private clouds?  What if a data center adds some self-service and  virtualization? Is that enough?  Probably not.  A typical data center is a complex environment.  It is not uncommon for a single data center to support five or six different operating systems, five or six different languages, four or five different hardware platforms and perhaps 20 or 30 applications of all sizes and shapes plus an unending number of tools to support the management and maintenance of that environment.  In Cloud Computing for Dummies, written by the team at Hurwitz & Associates there is a considerable amount written about this issue.  Given an environment like this it is almost impossible to achieve workload optimization.  In addition, there are often line of business applications that are complicated, used by a few dozen employees, and are necessary to run the business. There is simply no economic rational for such applications to be moved to a cloud — public or private.  The only alternative for such an application would be to outsource the application all together.

So what does belong in the private cloud? Application and business services that are consistent workloads that are designed for be used on demand by developers, employees, or partners.  Many companies are becoming IT providers to their own employees, partners, customers and suppliers.  These services are predictable and designed as well-defined components that can be optimized for elasticity. They can be used in different situations — for a single business situation to support a single customer or in a scenario that requires the business to support a huge partner network. Typically, these services can be designed to be used by a single operating system (typically Linux) that has been optimized to support these workloads. Many of the capabilities and tasks within this environment has been automated.

Could there be situations where an entire data center could be a private cloud? Sure, if an organization can plan well enough to limit the elements supported within the data center. I think this will happen with specialized companies that have the luxury of not supporting legacy. But for most organizations, reality is a lot messier.

Why all workloads don’t belong in the cloud

November 2, 2009 5 comments

I had an interesting conversation with a CIO the other day about cloud computing. He had a simple question: I have an relatively old application and I want to move it to the cloud. How do I do that? I suspect that we will see a flurry of activity over the coming year where this question will be asked a lot.  And why not — the cloud is the rage and who wouldn’t want to demonstrate that with the cloud all problems are solved.  So, what was my answer to this CIO? Basically, I told him that all workloads do not belong in the cloud. It is not because this technically can’t be done. It can. It is quite possible to encapsulate an existing application and place it into a cloud environment so that new resources can be self-provisioned, etc. But, in reality, you have to look at this issue from an efficiency and an economic perspective.

ROI

Cloud computing gains an economic edge over a traditional data center when it supports a relatively small simple workload for a huge number of customers. For example, a singular workload like email or a payment service can be fairly optimized at all levels — the operating system, middleware, and the hardware can all be customized and tuned to support the workload. The economics favor this type of workload that support large numbers of customers. The same cannot be said for the poor aging Cobol application that is used by 10 people within an organization. While there might be incremental management productivity benefits, the cost/benefit analysis simply doesn’t work.

So, the answer is pretty simple. You just can’t throw every workload into the cloud. It is not a panacea for all IT problems.  Organizations that are trying to figure out what to do with these pesky old workloads need to look at three options:

1. Decide if that workload is still supporting business objectives in a cost effective manner. If it does the job, leave it alone.

2. That old workload might be better supported by traditional outsourcing. Let someone else keep the application alive while you move into more mission critical tasks.

3. Think about rebuilding that old workload — either by encapsulating key elements and placing them within a modular flexible environment. You might even discover that there are components that are actually useful across the organization. When you discover that sharing components across divisions/department is a productive and pragmatic approach, you might be ready to move those workloads into the cloud.

cloud_box