Getting Started with Cloud Computing
Chapter 12 discussed the importance of service-oriented architecture (SOA) governance given the likely expansion of services within an organization. That expansion pales when you consider the growing number external services in the cloud that are available to any given organization. If you are going to include external services in your SOA, you need to establish a way to evaluate those services and the systems and hardware that support those services. A data center provides the systems and hardware. This chapter provides an overview of how to evaluate external services and data centers for cloud computing.
Expand Your Internal SOA to Include External Services
At this point, you will have the choice of weaving together services from other organizations with services your organization uniquely provides. This is where you could, for example, integrate an external customer relationship management (CRM) service, much like what was described in the initial story about C. R.’s business trip.
Staffing issues
If you have been experimenting with Web services and incrementally adding new services, you may very well be sailing along. You might have several teams involved with weaving together services. The team members’ skills position you to be ready to change things quickly should there be a business need for changing some aspect of your SOA in a hurry.
Likely change issues
The most likely change issues you will encounter at this point are:
Not invented here—As time goes on, more and more external services will be available that could replace internal custom-built services. Be prepared to continue to address this resistance through proper communication of the advantages of these services to your organization.
Our problems are special—This change issue is related to the previous one. It is difficult for many people to realize that specific problems are not special. The opportunity lies in weaving together “not-so-special” services into a special architecture for your organization.
Governance Considerations
Part of governance related to cloud computing is deciding which cloud-based services are critical and which are not. In C. R.’s business trip, services that support his travel (e.g., airlines, trains, and so on) are critical. It is important to really care about availability of those services. On the other hand, services that help C. R. with life experiences (e.g., art, museums, menu translation, and so on) are less critical. If one of those services happens to be unavailable it might be very frustrating, but it is not critical to his business trip.
Of course, for some of the critical services you just need to assume they have high availability. For example, your organization does not have much choice but to assume that cloud-based services provided by an airline or car rental agency will be highly available.
For those critical services where you have a choice of cloud providers, there are issues in addition to those discussed with SOA governance that started on page 161. There are legal, business, and technical issues.
Legal issues
You will need to work with a legal team on what should be in a contract with a cloud provider. Your organization needs to retain the right to its data. You need to consider legal jurisdiction and privacy laws in the location of the data center(s) and details on what will occur at the beginning and end of the contract period. You also need to consider including service standards, notification of changes in the data center, liability for data breaches (e.g., hacking or employee theft of data), disaster recovery, and remedies for when things go wrong.
Finally, you need to know if you have a legal requirement for your data to physically stay within a certain jurisdiction. This will affect your choice of a cloud provider.
Business issues
A business relationship with a cloud provider is just like any other business relationship. You should have a thorough understanding of the provider’s reputation, financial stability, longevity, and management practices related to the running of the data center.
Technical issues
It is important to understand the tools or dashboards available related to the cloud-based service. Establish an agreement on change management for the services provided. You need to understand the technical aspects of how the cloud provider supports high availability. This includes how they provide for redundancy and failover should the data center experience an incident such as a massive power failure in the geographic area in which it is located. You need a thorough understanding of the cloud provider’s security and how you can best protect your data in their system.
Data Center Considerations
It is important to realize the significant role the data center plays in cloud computing. Figure 13.1 illustrates some basic features for the data center. It is often a large facility with rows upon rows of rack-mounted hardware running software that allows for the provisioning of virtual machines/servers that make all the resources such as storage appear as if locally attached.
Figure 13.1 Data center with virtual machines/servers behind a collection of services.
The dynamic nature of provisioning gives rise to the terms scalability and elasticity for the number of virtual machines/servers and the amount of allocated storage. Of course, as shown in this figure, all this backs up what logically looks like a collection of services, as illustrated by the circles representing a collection of CRM services.
Depending on how you plan to use the services from a cloud provider, you need to take into consideration issues related to availability, disaster recovery, business stability, and legal arrangements.
Availability issues
Failover is automatically switching to a backup or standby. This could be hardware (virtual or physical) such as a server, network, or disk. It could be failover for software such as an application server, messaging such as a router or enterprise service bus (ESB), a database management system, or custom software for the service. Failover could involve the entire data center so that a backup data center is available. You should work with your technical team to create availability requirements necessary for your organization. (I will provide more on availability later in this chapter.)
Disaster recovery issues
Analyze the disaster recovery plan for the data center. Some possibilities to consider here are the geographic location, type of physical construction, physical security, power sources, power backup, and virtual/software-based security. Again, work with your technical team to develop what your organization might need for disaster recovery. There are publications that go into the technical issues to consider that are related to disaster recovery.
Examples of Technical Issues Related to Availability
Availability can be achieved in multiple ways. There is a lot to consider for availability. This section will give you a few examples of the technical issues to consider. Again, you should work with your technical team members to create availability requirements necessary for your organization
Failover options for messaging and databases
As mentioned earlier, the process of a secondary machine taking over for a primary machine is known as failover. Listed here are three types of failover that apply to messaging (message routers or ESBs) and databases. The terminology for types of failover can vary.
Transparent copy—the second machine takes over without the knowledge of the application.
Transparent cluster—in a clustered environment, if one node goes down, the remaining node(s) take over for the failed node without the knowledge of the application.
Application/service—the application/service needs to detect the loss of the master and switch to the second machine.
The first two forms of failover are acceptable for an SOA, but the third form, application/service, is not in most cases. It would require applications/services that depend on a machine being available to detect the loss of the machine. This would mean, for example, that messaging would need to detect that the primary machine for a master database has failed and then route data to the secondary machine. Conversely, the machine handling the master database would need to detect the loss of the primary machine used for messaging and route data to the secondary machine. This detection of machine loss among disparate components of an SOA is too intertwined.
Database availability options
Much like messaging, there are basic options for databases that need to be considered. These are shown in Figure 13.2.
Figure 13.2 Availability options for database management systems.
A basic database management system is shown in the lower-left quadrant. As with any database management system, it will protect all data that is successfully updated even if the machine on which it is running should fail. Nevertheless, this does not provide for a secondary machine to take over should the primary machine fail. It also does not provide options for load leveling through using more than one machine. Load leveling spreads activity or load across more than one machine.
The lower-right quadrant shows a database management system that uses replication. It provides for a secondary machine to take over should the primary machine fail. The data is replicated, which means, depending on the type of replication, data will be available on the secondary machine should it need to take over when the primary machine fails. (Replication options will be covered in the next section.)
The two upper quadrants each show a distributed database, which is one way to load level access to the database. Databases can be distributed in the same location or in separate geographical locations. It is really a design issue. Not every system needs a distributed database, which can add complexity to a system. Nevertheless, there are architectures that can benefit from distributed databases.
The upper-right quadrant shows a distributed database management system that also uses database replication at each node in the distributed database. This is one way to achieve both load leveling of database access and high availability through database replication.
Much like messaging, if the availability of the data in a master database is critical to your organization, then you should consider database replication to make the database highly available. (By the way, Figure 13.2 shows one replicated database in the right quadrant. Many products allow more than one replicated database if that should be needed for your architecture.)
Similarly, if the master database management system is not performing sufficiently on access speed, then distributing the data among multiple machines is an option for load leveling this access.
Replication options for messaging and databases
Both messaging (message routers or ESBs) and databases could take advantage of replicated data. Four types of data replication are listed here. The terminology for types of replication can vary. For this reason, each term is also defined in the right of Figure 13.2.
Real time—replication occurs as part of a transaction.
Store and forward—replication occurs on a periodic basis.
The only type of replication that will guarantee that no data is lost at time of failover is real-time replication. All the other forms can lose some data at failover time in one way or another. Real-time replication, however, has a cost. It may double the time it takes to update the stored data in either a messaging system or a database. Nevertheless, if it is important to your architecture that no data be “lost” due to failover, then real-time replication is the only way to go.
Other options concerning replication have to do with how the primary and secondary sites can be used. Some systems allow only updates on the primary site (sometimes called master site). The secondary (or slave or replicated) site exists only to receive the secondary update. Other systems allow data to be updated on either the primary or secondary site. The first master-slave technique is simpler. The second technique may open up architectural opportunities. A lot depends on your organization’s needs to determine which would be more useful.
Cloud Brokers
Sometimes it can be helpful to employ a cloud broker to help you sort through your options for cloud computing. Cloud brokers act more or less like mortgage brokers. They evaluate your cloud computing needs and provide you with a choice of cloud providers that best meet those needs. A cautionary note here is to ensure that you are working with an independent cloud broker. When a cloud broker is affiliated with a cloud provider, it raises doubt that you are getting choices that best meet your needs.
Should You Be Your Own Cloud Provider?
Your organization can be its own cloud provider, but you need to weigh the technical and business issues to take this on. As opposed to an external cloud provider where you pay for resources as you use them, you will need to invest upfront in the hardware and software for the data center. Of course, there can be legal or business reasons that you would want to do this.
There are options that can make this technically easier, such as “cloud computing in a box,” which creates a fully configured data center for your organization. Sometimes, it is possible to find a leasing option for such a “box” so that you can minimize your upfront costs.
You need to consider issues of availability. For example, will you need software that provides for replication and failover within you data center? Will you need to maintain a second, replicated data center should your primary data center fail for some reason?
In any case, you will need to invest in the people who maintain your data center and keep it secure. What you can offer people in the way of technical challenge and compensation will affect how well you can staff your data center. This is one area where an external cloud provider might have an easier time maintaining the staff necessary to properly maintain a cloud data center.
Summary
This chapter discussed the expanded role of governance related to cloud computing. As part of that governance, it is important establish a way to evaluate cloud-based services and the data centers that support those services. This chapter highlighted issues of availability related to cloud computing. At the end, it presented issues to consider if your organization wants to become a cloud provider.