Building a Private Cloud, Step-by-StepA white paper by David S. Linthicum

Executive SummaryToday the private cloud is a well-used architecture and technology within enterprises. Even so, most enterprises are still not well-versed in how to define, build, and deploy private clouds. There is a “gap of confusion” that exists between the proper use of private clouds and rank-and-file enterprise IT.

The purpose of this paper is to solve the mysteries from private cloud. We will provide you with a step-wise path to understand your own requirements, pick the right hardware and software, deal with secu-rity and governance, and finally implement the private cloud solution that will get it right the first time. These steps include:

Step 1: Define the Purpose Step 2: Define the Workloads Step 3: Define the Hardware Step 4: Define the Software Step 5: Define the Network Step 6: Define Security Step 7: Define Governance Step 8: Define Management Processes and Tools Step 9: Implementation Step 10: Testing Step 11: Operations

Building a Private Cloud, Step-by-Step 1

www.stratoscale.com

IntroductionThe private cloud offers most of the advantages of the public cloud: Self-service and scalability, multi-tenancy, the ability to provision machines, and change computing resources on-demand. Private cloud also improves on security by limiting access to key IT people. Complexities are emerging for DevOps teams around their "infrastructure as code" practices as larger companies consider moving their most business-critical applications off the public cloud and onto private/hybrid clouds.

Complexity issues include:• Time-consuming infrastructure configuration and maintenance.• Inconsistent visibility into infrastructure utilization and cost.• Ever increasing complexity with custom requirements in every project.

Private clouds are specialized cloud computing implementations that are purpose-built to address some limitation or shortcoming around the use of public clouds. Core factors that drive private cloud adoption are compliance, security, and even the sense of control that many in enterprise IT require. Or, think they require.

As DevOps organizations are built within enterprises, private clouds as the deployment platforms mesh well with existing DevOps automation approaches and tool sets. Those within enterprises can tell you that private clouds are a sound architectural option, and they require “some time.” Just as public clouds require “some time.” Most enterprises will end up with both, using hybrid or multi-cloud implementations. In this paper, we’ll focus on private clouds, and the steps to successfully implement private clouds.

Executive SummaryToday the private cloud is a well-used architecture and technology within enterprises. Even so, most enterprises are still not well-versed in how to define, build, and deploy private clouds. There is a “gap of confusion” that exists between the proper use of private clouds and rank-and-file enterprise IT.

The purpose of this paper is to solve the mysteries from private cloud. We will provide you with a step-wise path to understand your own requirements, pick the right hardware and software, deal with secu-rity and governance, and finally implement the private cloud solution that will get it right the first time. These steps include:

Step 1: Define the Purpose Step 2: Define the Workloads Step 3: Define the Hardware Step 4: Define the Software Step 5: Define the Network Step 6: Define Security Step 7: Define Governance Step 8: Define Management Processes and Tools Step 9: Implementation Step 10: Testing Step 11: Operations

Building a Private Cloud, Step-by-Step 2

www.stratoscale.com

IntroductionThe private cloud offers most of the advantages of the public cloud: Self-service and scalability, multi-tenancy, the ability to provision machines, and change computing resources on-demand. Private cloud also improves on security by limiting access to key IT people. Complexities are emerging for DevOps teams around their "infrastructure as code" practices as larger companies consider moving their most business-critical applications off the public cloud and onto private/hybrid clouds.

Complexity issues include:• Time-consuming infrastructure configuration and maintenance.• Inconsistent visibility into infrastructure utilization and cost.• Ever increasing complexity with custom requirements in every project.

Private clouds are specialized cloud computing implementations that are purpose-built to address some limitation or shortcoming around the use of public clouds. Core factors that drive private cloud adoption are compliance, security, and even the sense of control that many in enterprise IT require. Or, think they require.

As DevOps organizations are built within enterprises, private clouds as the deployment platforms mesh well with existing DevOps automation approaches and tool sets. Those within enterprises can tell you that private clouds are a sound architectural option, and they require “some time.” Just as public clouds require “some time.” Most enterprises will end up with both, using hybrid or multi-cloud implementations. In this paper, we’ll focus on private clouds, and the steps to successfully implement private clouds.

Building a Private Cloud, Step-by-Step 3

www.stratoscale.com

Why Private CloudPrivate and hybrid clouds are emerging around common use case patterns that are most likely to provide value for enterprises. They include:

Compliance-oriented, or, basically, deploying to private and hybrid clouds to deal with industry regu-lations and, ultimately, risk. The use of private cloud, including the cost of hardware and software, is justified considering the risk of running afoul of industry regulations.

For instance, PII (Personally Identifiable Information), if breached, can cause all sorts of legal and public relation nightmares, as well as damage an actual person. If the cost of this risk outweighs the additional cost of using a private cloud, then the private cloud should be selected. Other examples include control and security around financial information, as well as some customer data.

Performance-oriented means deploying to private or hybrid clouds based upon the need to have dedicated hardware resources to insure high and consistent performance. These requirements are typically around large database systems that need direct raw access to underlying hardware systems, such as I/O to support systems that won’t function well with “bursty” performance metrics that are often delivered by public clouds.

Core systems that define the business are often found in this category, including predictive analytics that link directly into business processes, transactional systems that are customer-facing, as well as high performance computing requirements. Most recently, there have been several gaming compa-nies that have pulled their gaming systems back in-house to deal with performance limitations of some public cloud providers, as well as to control cost (explained next). Business-oriented, or, when the use of private clouds saves money. There are two scenarios that seem to be emerging:

First, when there is a sunk cost in hardware and software systems made in the recent past, and the use of public cloud means those investments go unutilized. Thus the cost in dollars lost exceeds any cost benefit that comes from using a public cloud.

Second, when the cost of public cloud exceeds that of maintaining a private or hybrid cloud infrastruc ture. While the hype and the press would lead you to believe that this will never be the case, the reality is that, even with the never-ending price reductions, public clouds can cost more than private clouds, when considering the costs holistically.

DevOps-oriented, when the use of private or hybrid cloud is needed to support an emerging DevOps organization. As we mentioned above, public clouds are often the desired end-points, when it comes to DevOps and application development that can be automated with DevOps approaches and tools.

However, there are many use cases where it makes sense for these deployments to occur on private or hybrid clouds, based upon requirements that the infrastructure be 100 percent in control of opera-tions and developers.

Building a Private CloudNow that the value of building a private cloud is well understood, let’s look at what it takes, stepwise, to build one. While there are many patterns that can be found in traditional IT, there are some new approaches and technology that must be understood around the proper design and deployment of a private cloud.

Step 1: Define the Purpose

While you would think that this goes without saying, many enterprises don’t reflect on the core purpose of the private cloud. Its general purpose infrastructure has general purposes uses, many of which have yet to be defined. However, the keys to defining the core purpose include the following:

• Understand the current requirements, such as storage and compute.• Understand the future requirements, with an estimation of growth over the years. • Understand security requirements.• Understand governance requirements. • Define the types of workloads that the private cloud will host (discussed next). • Define the operation of the private cloud.

Building a Private Cloud, Step-by-Step 4

www.stratoscale.com

Why Private CloudPrivate and hybrid clouds are emerging around common use case patterns that are most likely to provide value for enterprises. They include:

Compliance-oriented, or, basically, deploying to private and hybrid clouds to deal with industry regu-lations and, ultimately, risk. The use of private cloud, including the cost of hardware and software, is justified considering the risk of running afoul of industry regulations.

For instance, PII (Personally Identifiable Information), if breached, can cause all sorts of legal and public relation nightmares, as well as damage an actual person. If the cost of this risk outweighs the additional cost of using a private cloud, then the private cloud should be selected. Other examples include control and security around financial information, as well as some customer data.

Performance-oriented means deploying to private or hybrid clouds based upon the need to have dedicated hardware resources to insure high and consistent performance. These requirements are typically around large database systems that need direct raw access to underlying hardware systems, such as I/O to support systems that won’t function well with “bursty” performance metrics that are often delivered by public clouds.

Core systems that define the business are often found in this category, including predictive analytics that link directly into business processes, transactional systems that are customer-facing, as well as high performance computing requirements. Most recently, there have been several gaming compa-nies that have pulled their gaming systems back in-house to deal with performance limitations of some public cloud providers, as well as to control cost (explained next). Business-oriented, or, when the use of private clouds saves money. There are two scenarios that seem to be emerging:

First, when there is a sunk cost in hardware and software systems made in the recent past, and the use of public cloud means those investments go unutilized. Thus the cost in dollars lost exceeds any cost benefit that comes from using a public cloud.

Second, when the cost of public cloud exceeds that of maintaining a private or hybrid cloud infrastruc ture. While the hype and the press would lead you to believe that this will never be the case, the reality is that, even with the never-ending price reductions, public clouds can cost more than private clouds, when considering the costs holistically.

DevOps-oriented, when the use of private or hybrid cloud is needed to support an emerging DevOps organization. As we mentioned above, public clouds are often the desired end-points, when it comes to DevOps and application development that can be automated with DevOps approaches and tools.

However, there are many use cases where it makes sense for these deployments to occur on private or hybrid clouds, based upon requirements that the infrastructure be 100 percent in control of opera-tions and developers.

Building a Private CloudNow that the value of building a private cloud is well understood, let’s look at what it takes, stepwise, to build one. While there are many patterns that can be found in traditional IT, there are some new approaches and technology that must be understood around the proper design and deployment of a private cloud.

Step 1: Define the Purpose

While you would think that this goes without saying, many enterprises don’t reflect on the core purpose of the private cloud. Its general purpose infrastructure has general purposes uses, many of which have yet to be defined. However, the keys to defining the core purpose include the following:

• Understand the current requirements, such as storage and compute.• Understand the future requirements, with an estimation of growth over the years. • Understand security requirements.• Understand governance requirements. • Define the types of workloads that the private cloud will host (discussed next). • Define the operation of the private cloud.

Building a Private Cloud, Step-by-Step 5

www.stratoscale.com

Step 2: Define the Workloads

Determine, as best you can, what types of applications and application data will run on the private cloud. The best way to do this is to divide the workloads up into the following categories:

ApplicationsSolutions defined by code, including the mechanism for execution. You need to note the impact on compute and storage needs, and how applications can be managed. Also, the impact of coupling with the data or databases, discussed next.

DataDefine the data workload, no matter if it’s stored in a raw file system or within a database. You need to note the data model, structure (if any), and how the data is accessed. The focus needs to be on input/output mechanisms and their impact on the platform/private cloud.

InfrastructureThis includes file systems, networks, anything that sits below the applications and data. We look at this separately due to the fact that, in some instances, private clouds just provide infrastructure, and have little to do with applications or data. Again, you need to determine the profile of the infrastructure services that will be impactful on the platform, and to what degree.

Step 3: Define the Hardware

Defining the hardware means that we take the data gathered in the previous step and size up a hard-ware system that will provide the right support now, and into the future. You must select the right servers, networks, power, cooling, and even approaches to physical operations. Work with your private cloud software provider to determine the best hardware sizing for your needs, based upon your workload profiles and plans.

Step 5: Define the Network

Now that we know the workloads, hardware, and even have an idea of the private cloud software, it’s time to define the network. This includes:

• Physical network, including all equipment. • Physical network security.• Network management.

Step 6: Define Security

The focus here should be on Identity and Access Management (IAM). IAM is clearly the best security model and best practice. Indeed, many private cloud providers use IAM, such as OpenStack distrib-uters. The concept is simple; provide a security approach and technology that enables the right indi-viduals to access the right resources, at the right times, for the right reasons. The concept follows the principles that everything and everyone gets an identity. This includes humans, servers, APIs, applica-tions, data, etc.. Once that verification occurs, simply define which identities can access other identi-ties, and create policies that define the limits of that relationship.

Step 7: Define Governance

Why do we leverage cloud governance? Once we get to a certain number of cloud services, we won’t be able to keep track of them all and provide the control they will require. Those who leverage many services provided by private clouds call this the “tipping point,” or, the point where the number of services under management becomes so high that’s it’s impossible to manage them properly without a governance model, approach, and service governance technology.

The number of services, as well as the complexities around using those services within the context of cloud computing, makes service governance even more compelling. You’ll need service governance that covers:

• Location of the services. • Service dependencies. • Service monitoring. • Service security.

Step 8: Define Management Processes and Tools

Here we focus on what it will take to operate the private cloud. This includes determining the point-of-monitoring, including part of the application, data, and infrastructure. Also, we need to deter-mine the platform itself, network, and even the power that supplies the servers.

While this seems like IT best practices that already exist, the reality is that you need something differ-ently when considering a private cloud. The private cloud can do very different things on different days, thus the monitoring and operations aspects of private cloud become that much more import-ant. You can easily run out of capacity, or cause failures or service disruptions in other ways.

Step 9: ImplementationHere we stage the private cloud, including hardware and software, and be sure to at least pre-test that the system is running up to standard. It is a good idea, in some cases, to hire consultants who under-stand the private cloud that you’ve selected. They can work around the inevitable issues you’ll have with installation and configuration. Keep in mind that this is pre-testing, and we may have to loop back to this step to correct any issues found in testing.

Step 10: TestingTesting your private cloud should be a high priority. Your private cloud will do many different things, running many different workloads, and all should be validated. Test processes should include:

• Black box testing.• White box testing.• Penetration testing.• Performance testing.• Recovery testing.• Customized testing to reflect workload usage.

Step 11: Operations

We finally reach private cloud operations, also known as CloudOps. At this step, we define how we will operate the cloud, taking into consideration all that’s been defined thus far (see step 8). In some instances, operations need to mesh with your DevOps strategy, and need to include:

• Monitoring and metrics.• Automated management tools.• Security operations.• Governance operations. • Data operations.• Application operations.• Network operations. • Etc.

ConclusionWe can’t include everything in a single paper that you’ll run into when building a private cloud. Howev-er, we can provide some basic guidance, or a checklist, for how to approach your first or perhaps second private cloud project.

Keep these facts in mind as you move forward:

Your requirements are everything. Understand where you’re at now, and what is critical to the success of your private cloud deployment.

Trust, but verify. Test all hardware and software components that deal with security, management, governance, and performance.

Sweat the details. Take your time and understand all aspects of your solution. Private cloud that are missing key components, due to unrealistic deadlines, often fail.

Plan on making mistakes. They are a part of the process, and should be understood before being overcome. Dial them into your initial project.

If followed, these will become your guide for successful private cloud deployments.

Step 4: Define the Software

You need to select a private cloud software system. You can go either proprietary or open. If you’re moving to open solu-tions, then OpenStack is your primary choice. OpenStack is an open-source software solution that provides an Infrastructure-as-a-Service (IaaS) platform for private cloud deployments. OpenStack has become the de-facto standard in the open source community. While still a relative-ly new technology, industry support for OpenStack has been impressive. Thus, it should be the first technology on your list to consider when moving to a private cloud.

Step 2: Define the Workloads

Determine, as best you can, what types of applications and application data will run on the private cloud. The best way to do this is to divide the workloads up into the following categories:

ApplicationsSolutions defined by code, including the mechanism for execution. You need to note the impact on compute and storage needs, and how applications can be managed. Also, the impact of coupling with the data or databases, discussed next.

DataDefine the data workload, no matter if it’s stored in a raw file system or within a database. You need to note the data model, structure (if any), and how the data is accessed. The focus needs to be on input/output mechanisms and their impact on the platform/private cloud.

InfrastructureThis includes file systems, networks, anything that sits below the applications and data. We look at this separately due to the fact that, in some instances, private clouds just provide infrastructure, and have little to do with applications or data. Again, you need to determine the profile of the infrastructure services that will be impactful on the platform, and to what degree.

Step 3: Define the Hardware

Defining the hardware means that we take the data gathered in the previous step and size up a hard-ware system that will provide the right support now, and into the future. You must select the right servers, networks, power, cooling, and even approaches to physical operations. Work with your private cloud software provider to determine the best hardware sizing for your needs, based upon your workload profiles and plans.

Building a Private Cloud, Step-by-Step 6

www.stratoscale.com

Step 5: Define the Network

Now that we know the workloads, hardware, and even have an idea of the private cloud software, it’s time to define the network. This includes:

• Physical network, including all equipment. • Physical network security.• Network management.

Step 6: Define Security

The focus here should be on Identity and Access Management (IAM). IAM is clearly the best security model and best practice. Indeed, many private cloud providers use IAM, such as OpenStack distrib-uters. The concept is simple; provide a security approach and technology that enables the right indi-viduals to access the right resources, at the right times, for the right reasons. The concept follows the principles that everything and everyone gets an identity. This includes humans, servers, APIs, applica-tions, data, etc.. Once that verification occurs, simply define which identities can access other identi-ties, and create policies that define the limits of that relationship.

Step 7: Define Governance

Why do we leverage cloud governance? Once we get to a certain number of cloud services, we won’t be able to keep track of them all and provide the control they will require. Those who leverage many services provided by private clouds call this the “tipping point,” or, the point where the number of services under management becomes so high that’s it’s impossible to manage them properly without a governance model, approach, and service governance technology.

The number of services, as well as the complexities around using those services within the context of cloud computing, makes service governance even more compelling. You’ll need service governance that covers:

• Location of the services. • Service dependencies. • Service monitoring. • Service security.

Step 8: Define Management Processes and Tools

Here we focus on what it will take to operate the private cloud. This includes determining the point-of-monitoring, including part of the application, data, and infrastructure. Also, we need to deter-mine the platform itself, network, and even the power that supplies the servers.

While this seems like IT best practices that already exist, the reality is that you need something differ-ently when considering a private cloud. The private cloud can do very different things on different days, thus the monitoring and operations aspects of private cloud become that much more import-ant. You can easily run out of capacity, or cause failures or service disruptions in other ways.

Step 9: ImplementationHere we stage the private cloud, including hardware and software, and be sure to at least pre-test that the system is running up to standard. It is a good idea, in some cases, to hire consultants who under-stand the private cloud that you’ve selected. They can work around the inevitable issues you’ll have with installation and configuration. Keep in mind that this is pre-testing, and we may have to loop back to this step to correct any issues found in testing.

Step 10: TestingTesting your private cloud should be a high priority. Your private cloud will do many different things, running many different workloads, and all should be validated. Test processes should include:

• Black box testing.• White box testing.• Penetration testing.• Performance testing.• Recovery testing.• Customized testing to reflect workload usage.

Step 11: Operations

We finally reach private cloud operations, also known as CloudOps. At this step, we define how we will operate the cloud, taking into consideration all that’s been defined thus far (see step 8). In some instances, operations need to mesh with your DevOps strategy, and need to include:

• Monitoring and metrics.• Automated management tools.• Security operations.• Governance operations. • Data operations.• Application operations.• Network operations. • Etc.

ConclusionWe can’t include everything in a single paper that you’ll run into when building a private cloud. Howev-er, we can provide some basic guidance, or a checklist, for how to approach your first or perhaps second private cloud project.

Keep these facts in mind as you move forward:

Your requirements are everything. Understand where you’re at now, and what is critical to the success of your private cloud deployment.

Trust, but verify. Test all hardware and software components that deal with security, management, governance, and performance.

Sweat the details. Take your time and understand all aspects of your solution. Private cloud that are missing key components, due to unrealistic deadlines, often fail.

Plan on making mistakes. They are a part of the process, and should be understood before being overcome. Dial them into your initial project.

If followed, these will become your guide for successful private cloud deployments.

Step 2: Define the Workloads

Determine, as best you can, what types of applications and application data will run on the private cloud. The best way to do this is to divide the workloads up into the following categories:

ApplicationsSolutions defined by code, including the mechanism for execution. You need to note the impact on compute and storage needs, and how applications can be managed. Also, the impact of coupling with the data or databases, discussed next.

DataDefine the data workload, no matter if it’s stored in a raw file system or within a database. You need to note the data model, structure (if any), and how the data is accessed. The focus needs to be on input/output mechanisms and their impact on the platform/private cloud.

InfrastructureThis includes file systems, networks, anything that sits below the applications and data. We look at this separately due to the fact that, in some instances, private clouds just provide infrastructure, and have little to do with applications or data. Again, you need to determine the profile of the infrastructure services that will be impactful on the platform, and to what degree.

Step 3: Define the Hardware

Defining the hardware means that we take the data gathered in the previous step and size up a hard-ware system that will provide the right support now, and into the future. You must select the right servers, networks, power, cooling, and even approaches to physical operations. Work with your private cloud software provider to determine the best hardware sizing for your needs, based upon your workload profiles and plans.

Building a Private Cloud, Step-by-Step 6

www.stratoscale.com

Step 5: Define the Network

Now that we know the workloads, hardware, and even have an idea of the private cloud software, it’s time to define the network. This includes:

• Physical network, including all equipment. • Physical network security.• Network management.

Step 6: Define Security

The focus here should be on Identity and Access Management (IAM). IAM is clearly the best security model and best practice. Indeed, many private cloud providers use IAM, such as OpenStack distrib-uters. The concept is simple; provide a security approach and technology that enables the right indi-viduals to access the right resources, at the right times, for the right reasons. The concept follows the principles that everything and everyone gets an identity. This includes humans, servers, APIs, applica-tions, data, etc.. Once that verification occurs, simply define which identities can access other identi-ties, and create policies that define the limits of that relationship.

Step 7: Define Governance

Why do we leverage cloud governance? Once we get to a certain number of cloud services, we won’t be able to keep track of them all and provide the control they will require. Those who leverage many services provided by private clouds call this the “tipping point,” or, the point where the number of services under management becomes so high that’s it’s impossible to manage them properly without a governance model, approach, and service governance technology.

The number of services, as well as the complexities around using those services within the context of cloud computing, makes service governance even more compelling. You’ll need service governance that covers:

• Location of the services. • Service dependencies. • Service monitoring. • Service security.

Step 8: Define Management Processes and Tools

Here we focus on what it will take to operate the private cloud. This includes determining the point-of-monitoring, including part of the application, data, and infrastructure. Also, we need to deter-mine the platform itself, network, and even the power that supplies the servers.

While this seems like IT best practices that already exist, the reality is that you need something differ-ently when considering a private cloud. The private cloud can do very different things on different days, thus the monitoring and operations aspects of private cloud become that much more import-ant. You can easily run out of capacity, or cause failures or service disruptions in other ways.

Step 9: ImplementationHere we stage the private cloud, including hardware and software, and be sure to at least pre-test that the system is running up to standard. It is a good idea, in some cases, to hire consultants who under-stand the private cloud that you’ve selected. They can work around the inevitable issues you’ll have with installation and configuration. Keep in mind that this is pre-testing, and we may have to loop back to this step to correct any issues found in testing.

Step 10: TestingTesting your private cloud should be a high priority. Your private cloud will do many different things, running many different workloads, and all should be validated. Test processes should include:

• Black box testing.• White box testing.• Penetration testing.• Performance testing.• Recovery testing.• Customized testing to reflect workload usage.

Step 11: Operations

We finally reach private cloud operations, also known as CloudOps. At this step, we define how we will operate the cloud, taking into consideration all that’s been defined thus far (see step 8). In some instances, operations need to mesh with your DevOps strategy, and need to include:

• Monitoring and metrics.• Automated management tools.• Security operations.• Governance operations. • Data operations.• Application operations.• Network operations. • Etc.

ConclusionWe can’t include everything in a single paper that you’ll run into when building a private cloud. Howev-er, we can provide some basic guidance, or a checklist, for how to approach your first or perhaps second private cloud project.

Keep these facts in mind as you move forward:

Your requirements are everything. Understand where you’re at now, and what is critical to the success of your private cloud deployment.

Trust, but verify. Test all hardware and software components that deal with security, management, governance, and performance.

Sweat the details. Take your time and understand all aspects of your solution. Private cloud that are missing key components, due to unrealistic deadlines, often fail.

Plan on making mistakes. They are a part of the process, and should be understood before being overcome. Dial them into your initial project.

If followed, these will become your guide for successful private cloud deployments.

About StratoscaleStratoscale is redefining the data center, developing a hardware-agnostic, software platform converg-ing compute, storage and networking across the rack or data center. The self-optimizing platform automatically distributes all physical and virtual assets and workloads in real time, delivering “rack-scale economics” to data centers of all sizes with unparalleled efficiency and operational simplicity. Stratoscale is backed by leading investors including: Battery Ventures, Bessemer Venture Partners, Cisco, Intel and SanDisk.

© 2015 by Stratoscale. All rights reserved. All Stratoscale products and services mentioned herein, as well as their respective logos, are trademarked or registered trademarks of Stratoscale. All other product and service names mentioned are the trademarks of their respective companies. These materials are subject to change without notice. These materials and the data contained are provided by Stratoscale and its customers and partners for informational purposes only, without representation or warranty of any kind, and Stratoscale shall not be liable for errors or omissions with respect to the materials, the data or the informa-tion, that have been provided by its partners and/or clients for public promotional purposes.

For more information visit:http://www.stratoscale.comUS Phone: +1 877 420-3244Email: sales@stratoscale.com

Step 2: Define the Workloads

Determine, as best you can, what types of applications and application data will run on the private cloud. The best way to do this is to divide the workloads up into the following categories:

ApplicationsSolutions defined by code, including the mechanism for execution. You need to note the impact on compute and storage needs, and how applications can be managed. Also, the impact of coupling with the data or databases, discussed next.

DataDefine the data workload, no matter if it’s stored in a raw file system or within a database. You need to note the data model, structure (if any), and how the data is accessed. The focus needs to be on input/output mechanisms and their impact on the platform/private cloud.

InfrastructureThis includes file systems, networks, anything that sits below the applications and data. We look at this separately due to the fact that, in some instances, private clouds just provide infrastructure, and have little to do with applications or data. Again, you need to determine the profile of the infrastructure services that will be impactful on the platform, and to what degree.

Step 3: Define the Hardware

Defining the hardware means that we take the data gathered in the previous step and size up a hard-ware system that will provide the right support now, and into the future. You must select the right servers, networks, power, cooling, and even approaches to physical operations. Work with your private cloud software provider to determine the best hardware sizing for your needs, based upon your workload profiles and plans.

Step 5: Define the Network

Now that we know the workloads, hardware, and even have an idea of the private cloud software, it’s time to define the network. This includes:

• Physical network, including all equipment. • Physical network security.• Network management.

Step 6: Define Security

The focus here should be on Identity and Access Management (IAM). IAM is clearly the best security model and best practice. Indeed, many private cloud providers use IAM, such as OpenStack distrib-uters. The concept is simple; provide a security approach and technology that enables the right indi-viduals to access the right resources, at the right times, for the right reasons. The concept follows the principles that everything and everyone gets an identity. This includes humans, servers, APIs, applica-tions, data, etc.. Once that verification occurs, simply define which identities can access other identi-ties, and create policies that define the limits of that relationship.

Step 7: Define Governance

Why do we leverage cloud governance? Once we get to a certain number of cloud services, we won’t be able to keep track of them all and provide the control they will require. Those who leverage many services provided by private clouds call this the “tipping point,” or, the point where the number of services under management becomes so high that’s it’s impossible to manage them properly without a governance model, approach, and service governance technology.

The number of services, as well as the complexities around using those services within the context of cloud computing, makes service governance even more compelling. You’ll need service governance that covers:

• Location of the services. • Service dependencies. • Service monitoring. • Service security.

Step 8: Define Management Processes and Tools

Here we focus on what it will take to operate the private cloud. This includes determining the point-of-monitoring, including part of the application, data, and infrastructure. Also, we need to deter-mine the platform itself, network, and even the power that supplies the servers.

While this seems like IT best practices that already exist, the reality is that you need something differ-ently when considering a private cloud. The private cloud can do very different things on different days, thus the monitoring and operations aspects of private cloud become that much more import-ant. You can easily run out of capacity, or cause failures or service disruptions in other ways.

Step 9: ImplementationHere we stage the private cloud, including hardware and software, and be sure to at least pre-test that the system is running up to standard. It is a good idea, in some cases, to hire consultants who under-stand the private cloud that you’ve selected. They can work around the inevitable issues you’ll have with installation and configuration. Keep in mind that this is pre-testing, and we may have to loop back to this step to correct any issues found in testing.

Step 10: TestingTesting your private cloud should be a high priority. Your private cloud will do many different things, running many different workloads, and all should be validated. Test processes should include:

• Black box testing.• White box testing.• Penetration testing.• Performance testing.• Recovery testing.• Customized testing to reflect workload usage.

Step 11: Operations

We finally reach private cloud operations, also known as CloudOps. At this step, we define how we will operate the cloud, taking into consideration all that’s been defined thus far (see step 8). In some instances, operations need to mesh with your DevOps strategy, and need to include:

• Monitoring and metrics.• Automated management tools.• Security operations.• Governance operations. • Data operations.• Application operations.• Network operations. • Etc.

ConclusionWe can’t include everything in a single paper that you’ll run into when building a private cloud. Howev-er, we can provide some basic guidance, or a checklist, for how to approach your first or perhaps second private cloud project.

Keep these facts in mind as you move forward:

Your requirements are everything. Understand where you’re at now, and what is critical to the success of your private cloud deployment.

Trust, but verify. Test all hardware and software components that deal with security, management, governance, and performance.

Sweat the details. Take your time and understand all aspects of your solution. Private cloud that are missing key components, due to unrealistic deadlines, often fail.

Plan on making mistakes. They are a part of the process, and should be understood before being overcome. Dial them into your initial project.

If followed, these will become your guide for successful private cloud deployments.