Visibility and control of external resources

As with SaaS applications, simply grabbing a cloud resource to execute a task is often too easy. To be successful, you need to have the ability to apply controls so that you can gain visibility into the cloud applications and services.

The biggest management challenges of external cloud resources are identifying the most appropriate services to use, verifying their characteristics (performance, security, cost, and so on), and making sure that these services are used exclusively. The rationale for using these resources to the exclusion of other resources is that after a service has been selected, investments in training, testing, and building infrastructure software will occur to make the service work effectively. You should avoid selecting and using a different service that has the same functionality, as it can double the costs of using the functionality.

Because using resources and building applications are fundamentally technical activities, the development organization or IT (if software is being developed for internal company use) should drive their management. Development has knowledge of the functionality of the resources required for the product(s) they’re developing, how a service will integrate into the product framework, and the long-term technical goals of the business.

The general cycle for approval, use, and eventual reuse of cloud services is:

1. Identify and define the functional requirements of the software being developed.

2. Research resources available from the cloud providers that are already used by the business to find a good match.

   Extend the search to other cloud providers if adequate solutions aren’t found or if additional cloud providers should be nurtured in the spirit of multicloud.

3. Perform tests in a pilot project to verify the resource(s) found in Step 2 meet the functional requirements.

4. If the testing is successful, form a business relationship with the service vendor and get access to the production version of the resource.

   The vendor may be a cloud provider or a third party who makes its software available in a cloud platform. If the testing is not successful, go back to Step 2 or consider building the resource internally.

5. Document the new service and its availability to the full development organization.

6. On a regular basis, perhaps yearly, revisit existing resources (internally developed as well as external resources), the requirements they need to meet, and their operational history and issues.

   If requirements or the resource have changed, consider restarting this process at Step 2 to see whether a new resource may be a better fit.

The importance of self-service

The idea of creating a catalog of approved computing resources that consumers may select from is critical to being able to manage in a consistent and predictable way. It’s a simple idea, but a very important one.

Cloud providers make it as easy as possible for consumers to find and use their services. At the low pay-as-you-go prices of most cloud resources, it’s a very compelling bargain. However, the company should limit employee choices of computing resources to approved resources.

The challenge is to make it easier for employees to use the company’s catalog to select what they want rather than go to the cloud themselves. To do so, the company must get ahead of the curve to understand the requirements and needs of development organizations. If the work of looking for, testing, and approving resources can be completed before the needs of the development organization become critical, then the catalog can include what the development organization needs. That proactivity will allow the easiest choice to be the right choice.

Service level agreements (SLAs)

Every cloud resource comes with a contractual agreement, known as a service level agreement (SLA), that outlines what the provider is delivering, along with the customer’s responsibilities. The agreement should outline characteristics like availability, accuracy, response time, throughput, and security. These important traits are critical for selecting resources that will meet the performance requirements of the services or applications that will use them.

Many public cloud services are quite clear that the vendor accepts responsibility in only a limited set of situations for a problem. For example, if someone in the organization misconfigures a service and it’s out of commission, the vendor accepts responsibility. If the vendor is directly responsible for a security breach, the responsibility is clear. However, there are many gray areas. For example, what happens if a flood in the region knocks out service or destroys data? What if third-party networking services that link a customer and the cloud are down? The vendor didn’t create the flood or outage. Therefore, the disruption may not be covered by the SLA. What does it mean if the problem is the vendor’s responsibility? Will the vendor be liable for your lost business when the service is down, or will it simply refund the money you were charged during the outage? In many cases, end-user businesses have complex insurance policies to cover these types of technology outages that lead to business disruptions.

Performance claims also constitute SLAs, which are formal commitments for performance of the resource in actual use. In many cases, cloud vendors battle each other and on-premises technologies in terms of uptime. One vendor may claim 99.99 percent uptime while another might claim 99.999 percent uptime. Although the difference may seem negligible, an extra nine is equivalent to approximately 47 more minutes of uptime a year. Forty-seven minutes may sound like a small disruption or a catastrophe, depending on the workload — for example, a test environment versus a retailer’s transactional system. Table 4-1 shows the approximate amount of downtime per a year based on system availability.

Of course, as you get more nines, the cost of the service will increase. A cloud that claims five nines will be more expensive than a less predictable offering that has two nines Claims are routinely verified by consumers and third-party auditors, either through test harnesses or within operation of the completed application or service. But SLAs go further: Failure of a computing resource to meet SLAs can and should be grounds for canceling contracts.

Managing a hybrid cloud environment

Businesses are increasingly leveraging a combination of public and private clouds. The combination of these resources provides the benefits of scalability, flexibility, and performance to their internal computing consumers. Nowadays, with public clouds offering a high degree of security to match its broad catalog of services and resources, companies who still use private or hybrid clouds may have even more stringent requirements than before. As cloud computing matures and becomes core to the business strategy, the organization will likely select well vetted applications and resources, with more thorough security. In a private or hybrid cloud context, the approval process will be more important than ever.

Carefully curated cloud resources offered for use in private or hybrid clouds are perfect for self-service. Not only will the carefully selected resources have been preapproved by the business with licensing or purchase already completed, but the resources will be specifically what the company requires to enable and secure critical in-house applications. In a mature self-service hybrid cloud, all the available resources and applications will be well architected to be the building blocks of a productive and safe data center.

Understanding the role of internal SLAs

When a company is a private or hybrid cloud provider to its internal consumers, the company should define SLAs for the resources and services provided. Doing so will formalize the operational requirements for those services and increase the chances that consumers will be pleased with the internal services. SLAs provide objective targets for performance and other operational characteristics, such as meantime between failures, and therefore are important for determining whether performance problems with applications are due to problems with the application or problems with the resources and services that the application uses.

In the public cloud, management of resources and services is the responsibility of the public cloud vendor or the third party who provides the software. A responsible organization should continually monitor the software operation to ensure that SLAs are being met. In the private cloud environment, it’s usually the responsibility of IT operations to monitor the software for deviations from SLA commitments.

While public cloud providers have the responsibility to watch SLAs, they have many customers and may not always respond immediately. On the other hand, a company running its own private cloud has one customer (itself) and is equally responsible for ensuring that all applications, services, and resources are always working effectively. In some organizations, executives will be watching whether SLAs are being met because problems can affect the company’s bottom line.

Supporting cloud customers

Providing call centers and support for internal consumers of private/hybrid cloud applications is an essential part of managing a private or hybrid cloud. When customers run into problems with an application, they expect quick help. For third-party applications, comprehensive support will usually come from those third parties although internal support should be aware of the common issues consumers may encounter. But if applications are developed or maintained in-house by internal development teams or by IT acting as a development organization, then development has a role to play with support.

For their part, support organizations pride and measure themselves on delivering quality and timely support. In fact, support organizations increasingly see a reduction of support calls as a goal. Reducing the number of calls can be accomplished by making the software more robust and more intuitive, but support organizations have little control over the software features being developed. Hence, development and support need to work closely together to provide world-class support.

Monitoring internal and external systems

High quality support requires knowledge of the systems being supported and their operational status. Customer problems may be due to misunderstandings or lack of knowledge of how an application works or how to use it to get a specific result. In these cases, support needs to understand the application in depth so that it can guide the customer in the right direction. Of course, hopefully the customer has been trained to use the application, but once the customer calls, support must address the issues.

Imagine that a customer calls with a problem regarding a specific feature of an application. When support receives the call, the first step will likely be to ask the customer what application they were using and what they were doing. This type of call probably happens every day, perhaps all day long. Remember that support is being measured on how quickly they can help customers, so how can they streamline this process? One answer is that the application should be tracking each user’s activities and saving the information in a location that is accessible to support. Then, when a customer calls, support can look up the customer’s recent activities and quickly know exactly what they were doing when they called support. When the process is fully automated, the phone system can recognize the caller, find the username, and present the support staff with the customer’s latest activities.

Rather than asking the caller for what application they were using, the support staff can answer the call with “I see you were using our CRM application and just got an error message when you tried to look up a business by its nickname. Is that what you’re calling about?” The time saved on each call, multiplied by all the calls, will be a big success for the support organization, the customer, and the company.

This example is just one of many that shows how monitoring applications improves the management of those applications. The following sections look at a few more examples.

Constructing dashboards

A wealth of data and information comes from a busy cloud environment, and many employees can use that information to solve their daily challenges. No one can process all that information in its raw state; there are just too many details.

Harnessing this information into a form that is useful requires at least two parts:

• Analysis software that processes and reduces the data to a manageable form
• A visualization technique that makes the information easy for people to recognize

Dashboards are often the best tool for presenting operational information to various audiences. With flexibility in how dashboards are constructed, different views with different focuses can be designed for different audiences. Support needs information to help users with problems, developers need to see performance data and information about what customers are doing, product managers need to see KPI and other usability information, and executives need to see high-level status and data on customer acceptance.

DevOps and deployment to public clouds

Nowadays, best practices for developing software for the cloud are based on DevOps practices. DevOps combines Development with Operations and enables continuous development and deployment of software. (See Chapter 11 for a more in-depth discussion of DevOps.) DevOps streamlines the management of application and service life cycles by eliminating handoffs between development and operations and makes the software more robust because developers are now paying more attention to operational issues.

After an application is deployed to the cloud, DevOps engineers continue to watch the software while it’s running. If operational issues come up, the engineers responsible for the software are immediately involved and can either solve problems tactically in the cloud or, if necessary, make changes to the application and redeploy it with fixes as quickly as the code can be changed and tested.

External system monitoring

With applications and services used by customers in other companies, it’s even more important that system monitoring gather application and service usage than it was within a single company. After all, companies have many more opportunities to quiz their own employees about how well systems work than quizzing employees of other companies.

Similarly, pushing product and operational status to external customers becomes more important because the customers will have less awareness of those issues and less loyalty to the software than internal customers.

Application and service life cycles

In the public cloud, there is less tolerance for problems, outages, and frustrations. Applications and services in the public cloud must be as robust as possible. Consider these issues for making applications and services fit the “always on and always available” expectations of the public cloud:

• DevOps’s goal for continuous development and deployment is to release new features as soon as they’re ready. But while it was once okay to take the application down while it was being upgraded, it isn’t acceptable in the cloud. Applications and services must be able to be upgraded without disturbing customers who are using the application.
• Application and server failures are always bad, but they’re probably worse in the cloud (if only because there may be many more users). Designing in failover capabilities so that a failure causes only a momentary pause is much more desirable than having the application be completely unavailable, or perhaps worse, cause user data loss.