Table of contents
Introduction: The Hybrid Cloud
By Lee Atchison
As enterprises increasingly move to the cloud, many of them are finding that they’re not yet ready to completely abandon their data centers and move all of their workloads to the public cloud. Instead, they’re often taking a hybrid approach, keeping some workloads in on-premise data centers while leveraging the cloud for other tasks.
But while the term “hybrid cloud” has found its way into common usage among IT operations folk, not everyone agrees on exactly what it means. Basically, a hybrid cloud refers to any situation in which you have applications or their services running in your company’s data center, and in one or more public clouds, such as AWS, Microsoft Azure, or Google Cloud Platform.
A private cloud, meanwhile, is when your company incorporates cloud-type architectures and capabilities into your own private data center. The goal here is to make your data center “look” like a cloud and take advantage of cloud principles and best practices, but it is reserved for your company’s own use.
Some people use the term “hybrid cloud” specifically to refer to companies that use a public cloud and have implemented a private cloud in their own data centers.
To me, though, any time you have a data center connected to the public cloud and applications shared between that data center and a public cloud, you’ve got a hybrid cloud … no matter how you choose to manage your private data center.
Given that definition, lots and lots of companies have a hybrid cloud to one extent or another. There is nothing magical about it.
Basically, the hybrid cloud is a tool for any organization that wants to take advantage of some of the benefits that the cloud provides without having to move everything in its application infrastructure over to a public cloud.
3 Types of hybrid clouds
The increasing importance of the hybrid cloud may not be news, but there is more than one way to implement a hybrid cloud. In broad terms, there are three different approaches to implementing a hybrid cloud:
- Using the hybrid cloud to add data centers and capacity
- Using the hybrid cloud to add cloud capabilities
- Using the hybrid cloud for app migration
It’s important to note that these approaches are not exclusive. Many companies undertake multiple, simultaneous cloud migrations, each one using a different approach—or combination of approaches—and affecting different applications and different business units with particular needs and goals.
A company typically will have multiple applications, some of them in the cloud, some of them in traditional data centers, and some of them various hybrids. This kind of multi-variant hybrid cloud environment enables the company to handle the needs of all these cases.
Prioritizing cloud migrations
But that doesn’t mean they all happen the same way at the same time. Often, companies prioritize moving applications to the cloud based on the type of the application:
Not surprisingly, that multifaceted combination has important implications for monitoring and managing the performance of all those applications. We will look at those issues in Chapter 4.
Chapter 1: Using Hybrid Clouds to Add Data Center Capacity
Perhaps the most common hybrid cloud use cases comprise companies that simply want to be able to provision new servers faster than they can in their own data centers. Their purpose for moving to a hybrid cloud architecture is not to adopt particular cloud capabilities, but simply to leverage the cloud as an extension of their own data centers.
This may be to quickly address ongoing growth in production capacity requirements, since public clouds can often add capacity at a rate much faster than a traditional data center. Or a company may want to merely spin up temporary application environments for testing and debugging applications. Or it may want to create a whole new data center in the cloud to improve its availability, or to get better “coverage” in specific regions of the world. Again, public cloud vendors can often do this much faster and cheaper than a company could build its own data center.
Compliance is another common driver for hybrid cloud adoption. Some industries have specific geographic compliance requirements that specify where data must be stored. Others insist that data be stored locally or regionally (as is the case with some European Union compliance regulations), while still others may require data to be geographically distributed (often, in data centers at least 100 miles apart) for backup, redundancy, and disaster recovery reasons.
Whatever the reason, the cloud can be a relatively easy, quick, and affordable way to spin up an entire new data center—or additional data center capacity—to augment existing data centers.
Monitoring challenges when adding data center capacity in the cloud
Every hybrid cloud use case brings its own monitoring challenges. When using a cloud provider as an additional data center or for additional data center capacity, it is important to ensure that your monitoring tools work consistently across all your infrastructure—including the portions in your own data centers and in the cloud.
If you have different monitoring tools based on the location of your application or infrastructure components, you may have a difficult time diagnosing problems across domains. Additionally, configuring your tools, setting up alert thresholds and conditions, and similar monitoring management tasks can be more complicated when you have to use multiple monitoring tools.
Chapter 2: Using Hybrid Clouds to Add Cloud-Based Capabilities
As hybrid clouds become more and more common in enterprise IT settings, an increasing number of use cases and journeys are becoming apparent.
In Chapter 1, we looked at how the hybrid cloud can be a faster and more economical way to add new data center or server capacity—or even an entire new or better data center. But the ability to provision computing resources quickly is only one part of the cloud story.
The public cloud also provides unique capabilities that are very attractive for use in many applications, including applications that are not naturally cloud-based applications. Taking advantage of these capabilities in the cloud is typically much easier (or at least less impossible) than building them yourself, saving significant development time and cost, which benefits both enterprise dev and ops teams.
A simple example is Amazon S3, or Simple Storage Service, which provides an inexpensive, efficient, easy-to-use yet secure, resilient, and massively scalable file-storage mechanism for many applications. Imagine, for instance, that your company has a video management app that needs to store large video files and make them accessible to users around the world. Taking advantage of S3 is a popular way to deliver that functionality without having to build it and provide the infrastructure to operate it yourself.
Coping with huge quantities of data
Another example is the cloud’s much larger “edge” capability to provide highly scalable data bandwidth. For instance, some mobile applications and Internet of Things (IoT) use cases require huge quantities of data to be imported and stored for later processing. This may be because customers download lots of data from an application (such as video streaming), or because an application must communicate with a large number of agents all over the Internet (such as with IoT applications). If a company needs a bigger data intake or data export pipe than its data center can cost-effectively provide, the public cloud is extremely good at performing this type of “edge” data intake/export at almost any scale.
Then there’s the need for unique data processing, such as video processing. If you are adding new capabilities to your applications that deal with giant data sets, you may be able to find already optimized solutions available in the cloud. The cloud-based versions can give you a rapid way to add these capabilities to your application or company, usually without a massive upfront investment.
The cloud also offers managed capabilities that can help reduce your operational support burden. Dealing with databases, managing services, and creating application environments are use cases perfectly tailored to cloud-based services such as Amazon’s RDS and Elastic Beanstalk. While useful for production workloads, these technologies are especially useful for internal-use applications, experimental applications, or application-testing environments, where the ability to leverage the cloud to handle much of the operational support burden is highly valuable.
Finally, the cloud offers a highly scalable ability to handle extremely large data sets, making it easier to build data warehouses, perform map-reduce operations, and handle other data analyses useful in providing business analytics and other high-volume data-processing operations.
Monitoring challenges when adding cloud-based capabilities
Edge tier data-bandwidth connections and high-volume data-processing capabilities are likely central to your application, so you need a monitoring solution that monitors them as easily as it does the rest of your infrastructure—including the on-premise components.
More generally, if you think about the cloud capabilities that make moving these components to the cloud useful in the first place, it’s typically the cloud’s ability to handle large scaling requirements and/or huge data management. But don’t forget that large scaling and big data applications also generate huge quantities of analytics and monitoring data. Your monitoring toolkit must be able to handle this cloud-scale volume of data, and that typically means a cloud-based monitoring solution.
Chapter 3: Using Hybrid Clouds for App Migration
For many companies, the goal isn’t to share their applications across both their own data center and the public cloud. Rather, they want to move some of their applications lock, stock, and barrel to the cloud. If some of the company’s apps live in the cloud while others remain in the on-premise data center, then intentionally or not, these companies also have hybrid clouds.
The process of migrating entire apps to the cloud, virtually unchanged, is sometimes called “Lift and Shift.” In some cases, companies lift and shift entire applications to the cloud pretty much as they are, while others may re-architect those applications to make them better cloud citizens, or to make greater use of cloud features.
App migration is often part of the process of outsourcing as much of a company’s data center infrastructure as possible. Many of these migrations are in process at companies of all sizes, and most companies choose to migrate some applications but not others. Typically, “internal only” apps are migrated first, while the big, clunky mainframe apps are the last to be moved—and some of these apps may never make the transition.
In fact, many companies stop their app-migration process after moving only some of their applications to the cloud, usually for some business or technical reason. They may decide that the cost/benefit ratio for moving some applications, such as older or “problematic” applications, is not worth the effort. This creates an ongoing hybrid cloud architecture.
Monitoring challenges for “lift and shift”
You need a solid monitoring story to understand how your application works both before and after an app migration. That’s because you need to compare your application’s performance before the migration and after the migration. Variations in performance between the two could indicate a problem, or a need for further tuning and refinement in order for the application to function successfully in the cloud.
In order to monitor the results before and after migration, you need to use the same monitoring tools in both environments or the comparison may not be meaningful. This implies using a monitoring tool that works in the cloud and on-premise.
Even if you plan on completing the “lift and shift” maneuver and move 100% to the cloud, it is important that your monitoring solution work with your entire infrastructure, including both on-premise and cloud infrastructure components, during the migration itself. Depending on the size, complexity, and number of applications in question, that process could take months or even years.
Chapter 4: Monitoring Complex Hybrid Cloud Environments
Hybrid clouds often involve a wide variety of paths and use cases, even within single organizations. That means that many companies end up with surprisingly complex hybrid cloud environments, either during a transition to the cloud, or on an ongoing basis.
The biggest issue in monitoring complex hybrid cloud environments? Consistency.
You need a monitoring strategy that works across your entire organization and handles all of its needs in the same way. This includes on-premise legacy applications, newly created cloud-only applications, mobile apps, and naturally hybrid applications. Using a single monitoring vendor helps you provide a consistent monitoring story companywide, reducing administrative complexity and the chance that important data will be lost or underutilized.
One tool to rule them all
When you have some of your infrastructure in the cloud and some in your data center, you obviously want your tooling and management to, as much as possible, work in a consistent way across both areas. This is why technologies like OpenStack are so popular. They attempt to make private data centers look as much like the public cloud as possible.
The same goal applies to your monitoring solution. The worst scenario is to use one set of monitoring tools in your data center, and another set of monitoring tools in the cloud. You want one set to monitor everything.
Diagnosing problems is much harder if you have to keep switching tools. And even small delays resolving a crisis could cost you money and customers. In addition, using multiple tools places an additional cognitive load on your engineering, operations, and support staff. The more tools they need to use to do their jobs, the harder it is for them to do a good job.
Minimizing the need for customization
Don’t forget, it takes a certain amount of tweaking and adjusting to get your monitoring tools to work exactly the way you want them to and show exactly the information you want to see. Doing this in multiple tooling sets is inherently more difficult, and potentially problematic.
Consider setting alert thresholds. Having to set up alert and problem notifications identically in two different systems increases the chances of making a mistake. Again, mistakes in this area can mean lost revenue and unhappy customers.
Finally, think about the role of monitoring during the actual application-migration process. When moving an app from a private data center to the cloud, the first step is to monitor that application in the data center to get a baseline understanding of how the application is performing. Then, during and after the migration, you can refer to that baseline to determine if the migration has introduced any problems into the system. Of course, that works best if you’re using the same monitoring system before, during, and after the migration.
The hybrid cloud continues to evolve, so even if your organization isn’t currently dealing with a particularly complex cloud environment, that may not always be the case. Your monitoring solution should be designed to make it easy to deal with whatever cloud challenges you’ll face, both now and in the future.