Planning for Deployment
The hybrid cloud isn’t a single architectural model; rather, it’s a combination of a lot of different services that are located on different platforms. Therefore, there isn’t a simple way to define a hybrid architecture. Instead, from an architecture perspective, it’s important to look at the relationship among the services that are used together. Therefore, the usage of cloud management technologies (see Chapter 4 for more details on hybrid cloud management) needs to be considered as part of the architectural framework of the hybrid cloud.
In the hybrid cloud, you will never bring all services and elements together as though they were one system. Instead, you need to have a clear understanding of the distributed services and how they relate to each other. Many of the approaches require the creation of best-practices templates that can be used to create the right linkages between services. One of the best practices needed is to be able to keep track of what task a specific service executes, the rules for how it can be used, as well as definitions and dependencies. But the issues don’t stop with dependency. In a world where you’re going to leverage services based on different physical and virtual environments, you need to think about how the entire environment behaves under different circumstances. A well- designed hybrid cloud environment has to be built to support change. Change can be the addition of an additional cloud service, such as a SaaS application or a new business partner and their set of services. In essence, hybrid models have five primary architectural considerations:
Latency and performance
Security
Governance
Reliability in the context of change
We discuss each one throughout this section.
Latency: Performance matters
When planning your hybrid model, you need to consider the overall performance of your platform, which means that you have to monitor and measure your entire environment. For example, say that a critical issue for your business is the speed at which customers’ orders are confirmed. If you don’t handle this issue efficiently, customers won’t be happy and may move to another supplier. So, you may want to keep transaction management running within a private cloud or data center environment. If you were to use a public cloud transaction management service, the latency involved in moving data between networks would cause service delays. In addition, some applications require regular access to and manipulation of complex data. If this were to happen on a regular basis, you might not be able to perform as customers expect. In this situation, stick with either your current on-premises solution or a well-architected private cloud environment. On the other hand, you may discover that for other applications, such as customer management or human resource management workloads, a SaaS application provides acceptable latency to meet the needs of your constituents.
In addition to the performance of a specific cloud service, you need to consider the location of a service. A service in a public cloud may be fine for one type of use but may have unacceptable latency when several services need to exchange data very rapidly. Therefore, part of the hybrid architecture requires that you understand what role each service plays and how those services need to interact with each other.
Determining when to use a public versus private service depends on the context of what service is being delivered to the customer. The choices you make will depend on the task being executed. Therefore, you need to build the need for flexibility into the way you plan for latency in a hybrid cloud environment. For example, if you’re setting up a collaborative workspace with three partners, a public cloud environment will be cost-effective, and depending on the type of collaboration, this environment may perform well based on the type of collaboration being conducted.
However, if you have set up a mission-critical, high-volume transaction management platform, performance must be optimized. In contrast, if customers are looking up information occasionally or if data can be easily distributed, latency will not be an overarching problem. Many services have low volumes of data, in which case the system won’t constantly reach for massive amounts of data from on-premises data sources. These environments are practical for a public cloud platform environment.
Although people typically think of individual models and services, it’s worth looking at the issue of latency differently. Instead of assuming that each service runs as a stand-alone service, imagine that you combine a number of services to create a composite service. For example, say that you have a service where latency must be very low, but you want to take advantage of an inexpensive public commodity service in combination with a secure private cloud and some on-premise services. In this situation, you must determine which components of the environment will benefit from the public cloud services so that they match the overall service level requirement. As the needs of the organization change, it will be important to be able to change the location of a service if a different level of performance is required. There are situations where the volume of data that a customer needs to access has expanded so much that a different configuration will be needed.
Can encapsulation reduce latency?
In a service-oriented approach to computing, you can tightly couple a set of services that must execute with low latency. Pioneers in the services oriented architecture (SOA) market learned the hard way that loosely coupling (or connecting) business services doesn’t always provide the level of performance an organization needs. After learning this lesson, companies began tightly coupling services that needed faster performance. You can apply these same techniques to a cloud environment.
Creating encapsulated services (services where the elements needed to execute a service are combined together and provided with a clearly defined interface) that work as advertised isn’t easy. Technologists have struggled with getting this right for years. For example, the best practice of isolating underlying systems and software from the composite service is often ignored. Although this can be a huge problem within a data center, it can be disastrous in a hybrid cloud environment. Simply put, if you have a dependency to an outside service running in an encapsulated service that is used within a hybrid cloud environment, this dependency will cause failures. That failure may not happen until the dependent service is suddenly changed. For example, the service might require a certain version of a database. When that database is updated, the service will still look for the old version of the database. So, even when you do tightly couple services to reduce latency, you still need to follow the principle of loose coupling — services should be free of dependencies. At the end of the day, a well-constructed hybrid cloud must follow good engineering principles.
Security: Planning in context
When planning your hybrid environment, at the outset, you need to think about the security requirements for customers. What type of environment are you providing for your customers? Are you creating an informational resource that might be tied to a set of product data sheets? However, if you’ve created a platform that manages private health data, you must ensure that you’ve created the level of protection and privacy your customers demand. (Check Chapter 15 for more details about security and governance.) You need to understand these considerations before you begin your design. So, make sure your cloud providers can match your requirements.
Governance: Getting the right balance
Like security, governance requirements will determine how you plan and architect your hybrid cloud environment. Many industries have rules of engagement that are considered best practices. If you’re part of an industry that’s required to meet sophisticated governance requirements, it’s important to select partners that meet your needs. You may discover that you can’t use a third party for this part of your environment. Likewise, many countries have strict guidelines and requirements for how private data must be handled. In some countries, for example, an individual’s data must be stored physically within that country. These types of governance requirements demand that IT organizations plan their platform with this in mind. This means including process management services that determine where data must be stored. Which means that, in some countries, data is stored in a single physical data center. In other countries, data may be highly distributed across geographies without violating rules. Some cloud providers can implement automated policies that ensure that certain services run based on these rules.
Again, it’s critical to validate that your cloud vendors can meet your business requirements. For example, you must make sure that you can deploy your application and data in a specific country or region if necessary. The bottom line is that you have to match your architectural plan with the governance requirements in both your company and the industry.
Managing co-location
In the real world, compromise is a requirement for making computing perform well at an affordable price. In a perfect world, cost would never be an issue, but in complicated environments, compromise is a reality. The trick is to be able to manage across a hybrid environment that creates an architecturally balanced approach. So, when planning your hybrid cloud environment, you need to first select applications that fit well into the benefits and limitations of the cloud. Applications that do not match well for such a public cloud environment may need to stay on-premises, either on a traditional middleware deployment or in a private cloud environment. When companies or cloud creators have carefully architected their applications or services, they will be well-positioned to support a hybrid cloud environment.
Creating flexibility in the model
Companies looking at cloud computing typically assume that it’s an all or nothing model. However, cloud computing is simply part of an overall distributed architectural plan. Within an architectural framework, determining business, performance, and customer goals is important, and to do so, you must take into account all aspects of computing.
As we mention earlier in this chapter, you need to consider the issue of latency of overall performance and latency of managing data. If applications and services being offered to customers are based on a tightly coupled set of services with many dependencies, a public cloud service will cause serious problems with performance. However, if the organization is creating and leveraging a platform of well-defined and loosely coupled services that are designed to be easily linked together at runtime, a public cloud service is ideal.
Most organizations have a combination of these two scenarios; thus, architecturally, you need to think of your platform as a combination of data center, private cloud, and public cloud services. When you approach architectural considerations from this holistic perspective, the customer is well served and protected.
Some vendors will actually help you by providing several deployment options (public, private, data center) from the same platform, making it easier for your company to have a unified platform that can adapt to a wide number of use cases and constraints.