ServiceMesh

You’ve decided to create your first private cloud. This can be both an exciting and complex endeavor. Since you’re asking about hardware and software, let’s assume you’ve already evaluated the business drivers and uses cases:

• Your use case(s) are not a fit for public cloud.
• You have internal staff capable of managing and supporting your private cloud.
• You’ve evaluated current application environments and identified one or more that would benefit from being in the cloud and you have an approach to migrate them.
• You’ve mapped out any integration or specialized support requirements that might be required for your cloud to go into production
• You have the management support, resources, and project plan in place.

Okay, now let’s answer your question, “do I have to get all new hardware and software?” Unfortunately, the best answer is also the least satisfying “it depends”. In order to build your private cloud, you’re going to need a well thought out design architecture that will accommodate expected workload types. That means it depends on whether you are supporting:

• Dev/test infrastructure or platforms
• Apps with high I/O utilization (traditional SAN based apps)
• High availability
• High performance
• Distributed and/or portable
• Low latency
• Stateless design
• Etc..

The answers to the above questions will help drive your decision on what hardware and software to use. Here are a few additional tips and considerations:

-    Building a private cloud isn’t as easy as bolting together some hardware and installing  virtualization software.

-    You’re probably better off working with a partner and/or focusing on hardware that you already have familiarity with.

-    Understand your internal risk upfront. Is this first effort positioned as a test, or is this intended to be the cornerstone of your future IT infrastructure design.

-    Establish a good balance of idealism vs. pragmatism:

• Example of idealism:  Stateless environments that include a hardware and virtualization software agnostic solution
• Example of pragmatism:  Less initial automation and integrated management so you can speed up time to production readiness.
• Another example of pragmatism: Building with “known” components to simplify the project, but with a slightly lower expected ROI as a result. Using older hardware can be okay, but make careful considerations on how you will simplify the upgrade/replace cycle. Again, the ideal is that replacing hardware should be a “live” activity.

-    Key hardware & network considerations

• You can’t have too much memory or network bandwidth
• Define your standard subscription and plan for the appropriate processor and memory utilization breakdown (i.e., 1 Ghz virtual CPU and 4 GB of RAM per instance). This will define your “subscription” limits and help you determine whether the selected hardware is financially viable. In other words if the only way you can get to 1000 VMs is to build 10 racks worth of gear, then you’re most likely better off buying new. The new gear will save you power, space, cooling and network overhead.
• Try to design around a “SAN less” architecture, unless of course it’s SAN gear you’re considering reusing and you have the staff and expertise to continue to manage it.
• Think 10GBe

 -    Deciding on the right software might be your biggest hurdle. It’s unlikely that you’ll have all the software you need to build your private cloud. With the exception of your virtualization platform and related tools, you’re going to have to evaluate some new solutions. Here are some key Software considerations by function:

• Security – You may assume you can use the security capabilities supplied by the vendors with their virtual platform, but I strongly suggest expanding your view here and doing some serious research. You could also bring in some help to define your requirements so the solution you implement actually does what you need it to.  
• Policy & Governance – Now that you’ve got the ability to automagically deploy hundreds of instances, you’re going to want to ensure that you’re applying the appropriate controls and rules to each.
• Data Management: Where will it reside, how is it prioritized, and what are the movement restrictions.
• Access roles need to be well defined. At a minimum you’re going to need roles for the following; infrastructure admins, developers, production, and customer (depending on your catalog strategy).
• Automation – There are a number of tools that can help with developing automation. As much as possible you want to stay away from generating a laundry list of scripts and instead focus on an integrated solution. (See a previous blog for some of my thoughts on the importance of automation and what you should consider automating.)
• Lifecycle management
• Performance monitoring & management
• o   Key usage metrics and monitoring
• Visibility into where each of your vm’s reside
• Image & Stack development and management
• Sharing & publishing image and stack work efforts

So, now that you’ve got a small taste of what building a private cloud entails, it’s time to get started. Keep in mind that this blog is by no means comprehensive, so please go out and find great help and do your research. I’m looking forward to the birth reports of your first baby cloud. I wonder what you’ll name it.

The following are links to a few of my previous blogs that relate to the above topic, enjoy.

Cloud Management: What’s the Big Deal?

Discerning Freedom and Servitude in the Growing Cloud Management Space

Automation in the Cloud: The Devil is in the Details

Finding the Right Path to Cloud(s)

Using a Down Market to Prepare for Cloud