The private cloud offers most of the advantages of the public cloud—self-service and scalability, multi-tenancy, the ability to provision machines, and changing computing resources on demand. The private cloud also improves on security by limiting access to key IT people. But complexities are emerging for DevOps teams around their infrastructure as code (IaC) practices, especially as larger companies consider moving their most business-critical applications off the public cloud and onto private/hybrid clouds. These issues include:
- Time-consuming infrastructure configuration and maintenance
- Inconsistent visibility into infrastructure usage and cost
- Ever-increasing complexity with custom requirements in every project
How do you maintain the consistency and team velocity that your public cloud and DevOps practices provide as you move to a more customized, cloud-based ops environment? Here are some of the challenges teams face as they embark on this kind of project.
The wisdom of private clouds
The first question: In these days of public cloud—and the widely held understanding that they are cheaper, faster, and provide more agility—why consider private clouds? Well, you may not need to. Private clouds are specialized cloud-computing implementations built to address certain limitations or shortcomings perceived in public clouds. Core factors that drive private cloud adoption are compliance, security, and even the sense of control that many in enterprise IT need (or at least think they need).
This isn't just another article that disputes the wisdom of using private clouds. The core message here, rather, is that private clouds are a clearly relevant option for certain enterprises. The installation could be a standalone private cloud, or a hybrid cloud that pairs private and public cloud implementations. You just need to justify its use through your requirements.
The trend over the last year has been public cloud deployments—just look at the rapid growth of Amazon Web Services, and you can see this is more than an emerging pattern. As public cloud usage explodes (and the deployments are largely successful), questions begin to form around the use of private clouds versus public clouds, and how to take advantage of the efficiencies that the cloud really offers.
Enterprises now see the advantages of public clouds, including production costs, time to market, and agility. In some cases, public clouds offer a strategic advantage that allows the core business to move faster into new markets and quickly get their solutions up and running. The business itself is also removed from the limitations that come with the purchase of massive amounts of hardware and software.
DevOps has also become public-cloud focused. As DevOps organizations are built within enterprises, these clouds mesh well with existing DevOps automation approaches and tool sets when used as the primary deployment platform. Moreover, the concept of IaC (explained below) was largely born within public clouds, and continues its quick expansion to this day.
This isn't to say that private clouds are losing steam, so much as public clouds are picking up steam. Having implemented both, those within enterprises can tell you that private clouds are a sound architectural option, and require some time, just as public clouds require a ramp-up period as well. Most enterprises will end up with both, using hybrid or multi-cloud implementations across different types and sections of data.
Understanding the use cases
Private and hybrid clouds are emerging around common use case patterns that are most likely to provide value for enterprises. These use case patterns include:
Compliance-oriented use: This typically means deploying to private and hybrid clouds to deal with industry regulations 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.
PII (personally identifiable information), for instance, can cause all sorts of legal and public relations nightmares if breached. It can even damage individuals. And if the cost of this risk outweighs the additional cost of using a private cloud, the private cloud should be selected. Other examples include control and security around financial information, as well as some customer data.
Performance-oriented use: This means deploying to private or hybrid clouds based on the need for dedicated hardware resources to ensure high and consistent performance. These requirements typically center on 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. Data of this nature is 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, customer-facing transactional systems, and high-performance computing requirements. Most recently, there have been several gaming companies pulling their systems back in-house to deal with performance limitations of some public cloud providers, as well as cost—which brings us to our next point:
Business-oriented use: This is when the use of private or hybrid clouds saves money. There are two scenarios that seem to be emerging:
First, when there's a sunken cost in hardware and software systems that were developed somewhat recently, using public cloud means not using those investments. Thus, the cost in dollars lost exceeds any cost benefit that comes from using a public cloud.
The second is when the cost of public cloud exceeds that of maintaining a private or hybrid cloud infrastructure. Although the hype and press would lead you to believe this will never be the case, the reality is that even with the never-ending price reductions, public clouds can often cost more than private clouds—specifically when looking at the costs holistically.
DevOps-oriented use: This is when the use of private or hybrid cloud is needed to support an emerging DevOps organization. As mentioned above, public clouds are often the desired end points when it comes to DevOps and application development. This 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 on requirements that the infrastructure be 100 percent in the control of operations and developers.
The notion is that IaC is the complete automation of infrastructure by developers. And while it's native to most public cloud IaaS providers, the use within private clouds is less understood. There are risks and benefits to consider, of course—keep reading.
Enter infrastructure as code
IaC can both be a friend and an enemy, with respect to private or hybrid cloud deployments. It's helpful to consider the pros and cons up front before you move further down the DevOps path. On the whole, IaC can treat the configuration of systems using the same patterns that treat software source code. This means functions like source code management, continuous testing, and continuous integration all live within the infrastructure as well, completely programmable by developers. The advantage of IaC here is that it can ensure that changes to infrastructure are tested, repeatable, and invisible to application users.
So, things are changing. Public clouds make their infrastructure services accessible via APIs. Similar APIs are now appearing within private clouds as well as traditional systems. The majority of organizations that build their own private clouds expose APIs to developers for the control of the infrastructure in the initial steps of the building process.
But the evolution of private clouds with IaC is more of an evolution than a quick transition, so developers and operations are still learning how to define its value. It's safe to say the value of private or hybrid clouds—or any cloud for that matter—will be in their ability to provide fully automated infrastructure resources for developers as part of the DevOps processes and tools.
Private or public, DevOps, and IaC...Oh my!
The use of private and hybrid clouds comes with a certain set of risks and benefits, despite the use cases above. This includes time-consuming infrastructure configuration, in which respect private clouds aren't very different from existing on-premise systems. You need to consider the costs included for each approach—both hard costs such as actual money spent, and soft costs such as the strategic savings afforded through agility.
Also, be mindful of the ever-increasing complexity driven by custom requirements in every project. You may have dozens of software development projects under management, all with different infrastructure requirements, whereas in the past you probably had a few configurations controlled by the sysadmins. Today, you could have 1,000 applications that define 1,000 different infrastructure configurations. How does operations keep up with that complexity in the long term?
Just as important, think about inconsistent visibility into infrastructure usage and cost. If you have 1,000 infrastructure configurations, ask how you would track the use of those resources for showback and chargeback. The honest answer? You really can't—not to the degree of granularity you'd need, at least. There are tools now appearing on the market to help with this, but few are IaC-aware for private and hybrid cloud.
Finding the best approach
Most organizations are considering a hybrid approach to cloud computing. Most are also working with IaC approaches and mechanisms already, whether they use the term "IaC" or not. The trick is to define an approach that can blend with your current approach and automation for DevOps, as well as your use of both private and hybrid clouds.
The path to non-disruption is to understand the points of intersection of IaC and private/hybrid clouds. This means doing the following:
- Define the degree of infrastructure configuration that'll be exposed using IaC approaches. It's typically not as extensible as public clouds, but not static, either. What's controlled, and by which mechanisms?
- Define the configuration management approach, as well as tool sets to leverage. They should be able to record thousands of instances of infrastructure configuration, with the understanding that the infrastructure will ultimately be configured through complete automation, and is thus forever dynamic.
- Define how the developers and DevOps organization should use these mechanisms, while placing governance and policies over and above the use of IaC.
- Create automated processes for monitoring and accounting of IaC and DevOps. You need to determine what's working and what needs improvement.
It's not a matter of if you'll head down the IaC road with a private cloud, but when it will show up. Private clouds are needed, working along with public clouds. The consistent use of IaC, as well as other emerging DevOps approaches, is becoming just a fact of life in the enterprise.
Keep learning
Choose the right ESM tool for your needs. Get up to speed with the our Buyer's Guide to Enterprise Service Management Tools
What will the next generation of enterprise service management tools look like? TechBeacon's Guide to Optimizing Enterprise Service Management offers the insights.
Discover more about IT Operations Monitoring with TechBeacon's Guide.
What's the best way to get your robotic process automation project off the ground? Find out how to choose the right tools—and the right project.
Ready to advance up the IT career ladder? TechBeacon's Careers Topic Center provides expert advice you need to prepare for your next move.
