Cloud is a tremendous success; look at the trade press, the literature published by vendors offering cloud-related products, or the general press. In many ways, this declaration of triumph is true. Cloud vendors enjoy increasing revenues and stock prices. It seems that “cloud” is on everyone’s lips. Cloud implementations are enabling many organizations to slip away from the surly bonds of inflexible on-premises implementations.

But there is a dark underside to cloud implementations. Many have outright failed. Others have stalled in a morass of unmet expectations and disappointment. Yet others succeed only in lip service: an organization may implement a cloud project that has only marginal success, but the organization still may hold it up proudly as an innovative implementation of forward thinking and woe to anyone who says different.

These symptoms are shared with the early adaptation of most innovative technologies. Whenever a technology captures the interest and imagination of management and the public, there are bound to be occasions when organizations chase the phantom of a technological solution rather than address the real obstacles to progress.

Cloud Failures

Cloud solutions are open to a double punch: the cloud concept is both business and technical. Both the CFO and the CIO have an interest in cloud implementations. CFOs see a new business model in which IT costs show up on a monthly invoice based on transparent resource consumption. In a crisis, the CFO hopes to be able restrain the cloud service and reduce the monthly invoices.

The investment in on-premises computing is in depreciating technical assets that rapidly become obsolete and unrecoverable. Consequently, these costs are difficult or impossible to control. Once the investment is made, there is no going back. CFOs become excited at the possibility of dialing down IT equipment costs during business slowdowns and dialing them up when situations improve. There is a shining light for a future where the total cost of delivering services will decrease.

CIOs see greater flexibility for modifying existing services and introducing new services. Services that scale up and down automatically in response to demand are a solution that IT has wanted for decades. Technologists are tantalized by the prospect of developing services based on the instant availability of seemingly unlimited computing and storage capacity.

The CFO and CIO, as well as the CEO, are easily enthralled with visions of praise and gratitude from their boards and stockholders because they are reaping the benefit of the attractive new cloud concept that everyone is talking about. Even the name, cloud, conveys romance and vision, unlike “service-oriented architecture” or “distributed systems” that suggest someone with thick glasses and a pocket protector working nights.

But these benefits may not appear as expected or on schedule. Long-term contracts, startup costs, and opportunity costs all complicate the vision. Modifying existing applications for cloud deployment can be more difficult and time-consuming than expected, especially when development is unfamiliar with cloud. Worst of all, poor planning or faulty technical implementation can result in services that have to be redesigned and rebuilt after the cloud implementation is up and running. When these headwinds become too great for executive management to stand, the deflation of expectations is punishing.

In this atmosphere of over-expectation and minimal understanding, projects can start for the wrong reasons with inadequate or inappropriate strategic and tactical planning. Success, not failure, is surprising.

The problem is especially vexing because both the business and technical sides of the enterprise have expectations, and both must cooperate to achieve success. If the business side sees cloud computing as a cost-cutting measure with minor technical requirements or the technical side sees cloud as a technical effort that will save the business a bundle without similar investment from the business, success is difficult.

Cloud success requires full participation by both business managers and technologists. For example, a business manager may propose to move to a cloud an in-house application that fluctuates broadly in resource consumption. The manager is hoping to take advantage of usage-based billing to reduce costs during slow periods. Without the help of the technologists, the business manager may not realize that the application has a monolithic architecture that cannot scale by adding virtual machines. Therefore, it must be redesigned to scale horizontally if substantial cost reductions are to be gained from usage-based billing. The business manager will not be able to make an informed decision without a technical estimate of the cost of building in horizontal scaling, which could be minor or prohibitive, depending on the construction of the application. A proposal from the technical side may not take into consideration business requirements. For instance, they may propose moving an application to a cloud without being aware that the application is subject to auditing requirements that could not be met on the cloud. If this is not discovered until an objection is raised on the audit, the results could be disastrous.

Business Failures

Many of these issues stem from lack of planning and expectation setting. Cloud implementations transform capital investments into operational expenses over time, but that shift may be hard to detect because most of the time, current asset investments continue to support existing services or they have already been written off. Consequently, the immediate effect of deploying a cloud service is to increase operational expenses without a corresponding decrease in capital investment. There may be a decrease in capital investment, but it is a sum not spent, and it will not appear on either a revenue statement or a balance sheet. A cloud deployment may generate real cost savings, but only comparisons between real project costs and projected costs will show the savings. In real life, comparisons of real costs to projected costs can be unconvincing because they depend too much on the judgment of whoever made the projections.

Usage-based costing is a sword that cuts both ways. The traditional up-front investment in technology, hardware and software, offers some assurance of predictable costs. Usage-based costing may be predictable over a longer term, but monthly costs may vary unpredictably. When combined with inevitable startup costs, the early-days bill for a cloud deployment can be startling.

The arguments for cloud implementations can be divided into business and technical arguments. On the business side, organizations expect reduced costs from usage-based costing and a shift from capital investments to operational expenses. They also expect an overall decrease in costs from more efficient use of resources, and they expect a decrease in IT expenses as internal IT costs are shifted to external cloud providers that are expected to provide similar services at lower cost.

Cloud Business Success

The risk of failure for cloud projects can be significantly reduced with strategic planning and thoughtful assessment of the potential benefits of the implementations. Cost-based arguments for cloud are real, and they grab attention, but, like most good things, they are no slam-dunk and may take time to achieve. However, cloud architectures provide business benefits that are more likely to offer immediate satisfaction than cost arguments. For example, scaling up and down automatically is a cloud feature that is frequently highlighted as a cost benefit. However, the superior user experience from the responsively scaling may be a substantially larger benefit. By strategically planning and emphasizing for these benefits, a cloud project becomes more likely to succeed early.

Cloud Strategic Planning

Without strategic planning, all projects are hit or miss. Formally, a strategy is a plan to move from one state to another by achieving certain objectives while considering the wider context within which the plan is executed. In other words, to plan strategically, an organization must know where it is, where it wants to go, what it wants to achieve, its peers, its competitors, its dependencies, and its obligations. All strategy involves some prediction of the future, which is always subject to error. However, prediction based on a full knowledge of present conditions is much more reliable than prediction without accurate knowledge of the starting point. Gathering the knowledge required for strategizing is often more difficult than forming the strategy.

Strategy differs from design. A design resolves a challenge that is defined by requirements and constraints. Strategy determines the requirements and constraints. Without a strategy, a design has no exterior direction. However, designs are the concrete means of implementing strategies.

A strategy moves an organization from one state to the next. The starting state could be, for example, success in a certain market. The end state could be continuing success. If the aims of the strategy are higher, the end state could be success in several related markets or creating an entirely new market. Identifying the desired end state is the greatest challenge in strategizing. Achieving the chosen end state will require many designs and subordinate plans, but the goals of these designs and plans derive from the strategy.

Organizations do not exist in a vacuum. They have competitors, partners, obligations, and dependencies that can defeat the strategy. An organization is unlikely to excel in a market without a strategy that does not recognize the capabilities of competitors. A strategy of datacenter expansion is likely to fail if it does not consider the cost of energy. An effective strategy must consider many sorts of questions: How will the organization obtain needed resources? How will it ward off competition? How will it foster the innovation needed to achieve its goals? Strategy encompasses all these considerations.

The designs constructed to implement a strategy must also consider the strategy’s environment. For example, dominating a particular market may be a strategy. A design that proposes a product identical to a competitor may be inadequate because the strategy calls for a product that is much better than its competitor.

Gathering the knowledge needed for a good strategy is difficult because it involves many sources, including board resources and the highest levels of executive management. Often, forming a strategy is a trickle-down affair. The board determines a few fundamental high-level goals and principles. Executive management adds detail and color, and division and department heads work out the practical implications of the strategy.

The top-down approach is sometimes limited by incomplete knowledge of the enterprise environment that could be supplied by employees lower on the enterprise ladder. Progression through management layers can push aside historical and environmental context and practical limitations.

ITIL practices suggest some tools that help avoid these limitations when dealing with IT services. The basic ITIL strategy tool is the service portfolio. The service portfolio is a master catalog of IT services.¹ It includes services that are no longer in production, services in production, and planned services. The portfolio records the goals and expectations for each service, life-cycle status, who is responsible for the service, the service’s customers, its dependencies, the plans for the service, and other relevant information. Taken altogether, the service portfolio contains the strategy for IT services in the organization.

The ITIL service portfolio is a business document because its primary purpose is to describe services as parts of an overall business plan for IT services. The portfolio typically contains only references to detailed technical designs and descriptions of the implementation of the services. Nevertheless, the service portfolio is important for technical planning. The portfolio shows the business relationships between services, which ones reveal information flows, the relative importance of services, which services are expected to decline in use and withdrawn from operations, which services will expand and scale up, and a host of other details of the life cycle of services.

The broad service portfolio view of IT services encourages building services and components that will have a long and useful life. Information from the portfolio can have immediate practical implications. A service nearing withdrawal is not a good candidate for redesign for scalability. A service slated to evolve into new business models is an excellent candidate for moving business logic to an easily modified separate module instead of hard-coding new layers of logic into a monolithic application.

Cloud implementation strategy potentially affects every aspect of IT services. A cloud implementation is often a new approach to managing costs and investments. Without a master plan like a service portfolio, decisions are likely to be shortsighted and inconsistent. Choosing the order in which services or service support components will move to a cloud is a fundamental decision that architects make in the early stages of an implementation. Many factors influence that choice. Services subject to heavy regulatory constraints may never be implemented on a public cloud. Services with globally distributed consumers may be ideal candidates, as would be services that have to scale up and down easily. A current and complete service portfolio makes prioritizing much easier with information on the role and plans for all services in one place.

Other aspects of a cloud implementation work best when guided by a strategic view of IT services that is part of an overall strategy for the enterprise. For example, failover and disaster recovery are aided by a strategy that identifies the priority of services for business activities. A portfolio that indicated service dependencies is also important for planning recovery. Understanding expansion plans are important for designing for scalability.

Too often, without a service portfolio, there is no comprehensive view of IT services. Cloud architects are forced to interview departmental managers and monitor service usage to determine the relative importance and relationships between services. This kind of research may always be necessary, but a comprehensive portfolio greatly increases the probability of a good design.

Cloud Business Strategies

The concepts in this section are primarily business considerations that affect technical implementations. One of the biggest mistakes that can be made in establishing a cloud architecture is to ignore or under-use the business advantages of the cloud.

Design for Flexibility

Virtual systems are flexible, but cloud deployments can be designed to be even more flexible. In fact, a cloud project that does not increase the flexibility of the organization should be reevaluated. Flexibility is crucial for enterprises in the rapidly changing 21st century. The structure and direction of businesses change daily. Video rental stores are gone. Who buys music on CDs today? Cab companies don’t own cabs anymore. Businesses that continue to succeed are flexible.

What do we mean by flexibility? Flexible services are easy to change. They may be closely tailored to the needs of a particular line of business, but they are also designed with generic components that can be reused to support other lines of business. They are also designed with the assumption that the environment and the business may change in the future. The more flexible a service is, the fewer resources are required to modify the service to serve a new purpose.

Flexibility does not appear automatically when a cloud implementation is chosen. Ultimately, it is a business decision to invest in the foundation to support flexibility and support the guidance supplied by business to IT architects and designers. The technologists must understand how business is expected to evolve and where flexibility is needed.

The basic architecture of cloud, a hidden physical system that appears to support a limitless number of lightweight VMs, is ideal for generic service components that can be stopped, started, and reconnected at will. Instead of endless estimates of loads and reconfiguring machines and clusters, tailoring a service to a new line of business potentially becomes a gap analysis to determine new service components needed and how to reconfigure existing components. In the end, a service for a new line of business rolls out.

Reusable components are one of the foundations of flexible services that can support changing requirements and environments. With reusable components, services can molded to fit new circumstances by putting the components together in different ways like building bricks. However, reusability is not as easy to build in as it might appear. All too often, when the time comes to reuse the component, it comes close to the requirements, but the gap is wide enough to force some recoding. If this happens repeatedly without considering the overall architecture, the component is no longer generic and becomes a collection of disconnected bits of code specific to a number of services. This kind of component often becomes difficult to understand and maintain.

Reusable and enduring generic components stem from a cooperative effort between business and technology. Frequently, a poor component incorporates details that do not transfer beyond its initial tasks because the component design did not properly isolate the changing features from the static features. An analysis performed jointly by business and technology can determine which aspects of the component are likely to stay the same as a business evolves. Both business and technology contribute to identifying the appropriate level of generality, and both are needed for a system that can evolve smoothly and quickly over the long term.

Another aspect of flexibility is scalability. A cloud service should gracefully respond without interruptions or dips in performance when consumer demand suddenly increases or decreases. When service consumption decreases, consumption of computing resources should also decrease. The increase or decrease in service consumption could be the result of the unpredicted success or failure in business, such as an overwhelming response to a Super Bowl television spot; the discovery of a new use for the service; or the expansion or contraction of the business environment caused by fluctuations in the global economy.

Autoscaling is an example of an autonomic service, a service that can respond to its environment and manage itself. An application that adds additional VMs in response to increasing load is autonomic. Scaling is not the only possible autonomic response. Any process that responds to changes in its environment can be considered autonomic. For instance, streaming services can be designed to change the streaming rate in response to the quality of the network connection. Autonomic services have great potential for increasing the manageability of large systems such as those deployed on clouds.

One of the annoying aspects of typical traditional systems is that their cost seldom tracks to consumption of the service. If an e-mail system is designed to support 10,000 messages an hour, traditionally the cost will be the same when business slumps and traffic drops to one message an hour. In a well-designed cloud system, some of the system overhead will be inelastic (staff costs and amortized design and software development costs, network infrastructure for communicating with the cloud, and so on), but a substantial portion of the cost that would ordinarily go for on-premises equipment and the staff to keep it running will drop in proportion to usage. This elasticity will be important to any enterprise in the long term.

Geographic flexibility is also important. For some businesses, penetrating markets in new geographical areas is critical. Where and when a new market will appear is often unpredictable. Rapidly deploying services to these new markets often determines the success or failure of the venture. Cloud implementations can be geographically agnostic: a service designed for geographic flexibility on the right cloud can perform identically and equally well in Canberra, Indianapolis, and Munich.

The process described here is idealized. Services for new business opportunities are not trivial to design. There is no substitute for vision and insight. Nevertheless, cloud computing removes many physical obstacles to flexibility.

Working together with the IT department, an organization can plan a cloud deployment that offers great flexibility. However, flexibility is wasted if the business does not use it. One of the most effective ways of taking advantage of a well-designed system is to follow the ITIL Service Strategy best practices that were discussed in Chapter 3. The fundamental tool of ITIL Service Strategy is the service portfolio, which catalogs all the services of the enterprise, including quiescent historical services, production services, and planned services. Enterprise strategists, usually senior people from both the technical and business sides of the organization, can use the flexibility of cloud deployment to advance the entire portfolio, not just a single department, line of business, or technology.² Services that are planned and deployed as part of a portfolio designed to support the enterprise effectively can take advantage the flexibility and agility that a well-designed cloud deployment will provide.

Plan for “Bring Your Own Device” (BYOD)

Mobile devices—laptops, smartphones, and tablets—have become a way of life in the workplace. Although mobile devices are not inherently tied to cloud deployments, many mobile apps interact with applications on clouds. An enterprise mobile app combined with an enterprise cloud can be a powerful combination.

The ubiquity of mobile devices has driven major changes in the architecture and security of the enterprise. These changes have been intertwined in many cases with increasing use of cloud services. We’ve pointed out several times before that the old model of enterprise systems was a fortress with impregnable walls with a small number of armored entrances. Employees entered the physical enterprise through cipher and card locks. Security guards scanned for valid authorization badges. The enterprise network was inaccessible outside the building. Access to the Internet was strictly limited through proxy servers. All devices attached to the enterprise network were usually owned by the enterprise with tight controls over their configuration and contents.

Applications were built assuming they were protected by the enterprise outer wall. Developers assumed that their main security concern was preventing ordinary users from sneaking system administrator privileges and they could concentrate on easy and open access to applications from users inside the wall. The wall guaranteed that the user had at least lowest common denominator authorization. Users within the wall could be assumed to be using hardware controlled and sanitized by the IT department.

This has all changed for many organizations. The perimeter has expanded or even dissolved. Some employees work from home. They may be working with strategic documents that must be kept secret. Others are seldom in one place for long, working from their mobile devices wherever fancy takes them yet still accessing strategic or critical information. HR workers may have access on their mobile devices to confidential information that may invoke legal action if it is exposed. Salespeople on the road have full access to order tracking, inventories, and product literature including documents that require nondisclosure agreements. Senior executives have access to the most critical and confidential information both inside and outside the office and while traveling, perhaps to countries with significantly different rules on information practices.

BYOD practices often mean that employees may purchase their own devices and mingle their data with enterprise data on the same device. In some circumstances, there is a risk that the enterprise may become responsible for the safety of personal as well as enterprise data. These devices may be highly insecure, and they can be lost or stolen. In addition, these devices may have limited resources. Architects cannot assume that these devices meet some corporate minimum standard. Many issues must be addressed though management policies rather than technically, but a technical solution that cannot be ignored or intentionally violated is usually preferable.

Security issues aside, a roving user base has different performance and reliability issues that stem from using an external network for communication.

Cloud-based systems already face many of these problems. Cloud deployments are, almost by definition, remote implementations that are accessed from outside the sphere of control of the cloud provider. Self-implemented private clouds may be an exception, although many private clouds are constructed following the same principles as public or community clouds. When private cloud are deployed on the enterprise premises, they are not inherently remote like public clouds usually are. However, on-premises private clouds can be constructed outside the corporate network. This may be done when the private cloud is intended to be accessible in the same way a public cloud is accessible.

Cloud deployment gives the enterprise architect some help in designing a system that will effectively support BYOD, but only if BYOD requirements are kept it mind. For example, a cloud application that is designed to be distributed between geographically remote cloud datacenters may help maintain performance for far-roving mobile devices as well as provide failover sites that can respond to regional failures. Mobile apps are well suited for interacting with remote cloud implementations, especially if they have built-in provisions for temporary communications outages.

BYOD security is often implemented using encryption. Encrypting critical data is generally a good policy in cloud implementation. Since the data is in the hands of a third party, even with the strictest personnel policies, the data is accessible via administrative mistakes or rogue employees. Although the possibility is remote, encryption provides some protection against such unauthorized access. By building applications that encrypt all data as an optimized part of the fundamental design, data in the cloud and data on mobile devices are both less accessible to outsiders.

Strategists and architects are often tempted to take existing applications and perform a minimal port to an IaaS or PaaS cloud. They are likely to be disappointed because the benefits they gain from the cloud implementation may not compare well to the experience of peers who make better use of cloud characteristics. Enterprises have an opportunity to respond to both the challenges of BYOD and the demands for agility and efficiency with a cloud deployment, but only if using the advantages of the cloud.

Designs and Business Plans for Usage Based Costing

Perhaps one of the most disappointing aspects of cloud computing is the failure of some businesses to reap the promised savings from usage-based charging for computing resources. There are several reasons for the difficulty. Perhaps the easiest to explain is the ease with which additional resources are obtained. When a new VM can be launched in minutes with little or no strategic authorization, there is little constraint on overusing resources, and usage-based costs go up. This is often called VM sprawl.

It is also easy to forget that an application that is not designed to take advantage of usage-based cost may cost as much to run idle as it does to run at peak capacity. One of the most important financial goals for cloud computing is to couple business activity to computing costs. If the cost of IT does not go down as business decreases, it is fixed overhead that will eventually become onerous. Cloud computing promises to allow the cost of IT to decrease when the business it supports declines.

Applications designed to scale vertically rather than horizontally typically do not respond to a decrease in demand by reducing the number of VMs in use. Cloud costs are typically calculated on the number of VMs running. In other words, shutting down a line of business or curtailing production in other ways will not decrease the cost of running the application.

Storage is less of a problem. Storage costs are usually calculated on the quantity of data stored and the frequency of access. Most applications will not write or read as much data when usage decreases, which causes storage costs decrease as usage decreases. Generally, the elastic nature of cloud storage implies that applications can write without regard for exceeding physical storage limits in a cloud environment.

Even when applications are designed to increase or decrease resource consumption as usage changes, the enterprise may not take advantage of these changes. Often this is the result of the absence of a comprehensive cloud strategy that combines technology and business strategy. For example, suppose the enterprise uses an SaaS-based document processing service and back charges each business unit a fixed amount for the service. The fixed back charge may be an artifact from a previous era when the enterprise purchased a site license with unlimited usage. If the back charge policy is not changed, the business units will see the service as free and have no incentive to use it prudently.

A different type of example is SaaS customer relations management (CRM). An on-premises CRM system is typically a fixed cost no matter what the usage. Unlike document processing, many businesses will experience an increase in CRM usage when business goes down because the sales department increases its use of CRM to find customers ready to spend. The increased cost of the SaaS CRM could be a nasty surprise if business plans assume that the cost of CRM will remain constant as it typically does when the solution is on-premises.

Benefits from use-based compute and storage pricing can be substantial, but they are not automatic, and the strategies to realize benefits are both business and technical.

Prepare for the Transition from On-Premises to Cloud Deployment

The transition from on-premises to cloud-based services is not trivial. Even when the transition involves only deploying existing applications on an IaaS cloud with minimal porting, the organization will change.

Simply porting an application to IaaS minimizes transition. The change is similar to moving from one operating system to another. The IT technicians who administer the application have the most to learn and the most significant changes to make, but the rest of the organization will experience a few changes. They may see changes in the performance of the ported application—perhaps improvements, perhaps degradation, and most likely a mix. Support may change also. The service desk may have to learn to distinguish between issues that can be solved by the local team and issues that have to be solved by the cloud provider, and the user will have to change their expectations for the speed of resolutions. Change on this scale is easy to cope with, but it may not be the best strategy. Avoiding change minimizes disruption, but it also can minimize the benefits of a cloud implementation.

Cloud transitions that minimize change may not require extensive transition and training plans, and they may not involve changes in staffing. However, by avoiding changes to the business, they also minimize the potential benefit to the organization. In addition, even minimal changes can be more disruptive than expected. Transition planners should never forget that moving to cloud computing is a business change as well as a technical change. Part of the transition often involves training for business managers on the possibilities for management offered by the cloud implementation.

When substantial service changes may be required, ITIL provides detailed guidance for transition to new or modified services that can be useful in cloud transitions. Transition in ITIL practice is not an isolated event. Transition begins long before technology is deployed. It starts with strategy and design that identifies the goals of new services, who will implement the service, who will operate the service, and who will be the consumers of the service. Early on, an assessment begins to determine what will be needed from each of these groups for a smooth and successful deployment.

Transition from on-premises to cloud services may be more difficult than other transitions. ITIL practice points out that a change in a service often requires a shift in responsibilities.³ This applies to movement to the cloud as much as a transition on the enterprise premises. The transition is not only to new applications. The transition also requires understanding of new cost models and external dependencies. These changes can result in displacements of established relationships within the organization.

Data Strategy

The cloud offers new opportunities for storing and using data. Cloud data costs are dramatically lower than the costs of storage and access when many of the basic applications that run businesses were written. Some applications go all the way back to the mainframe era when bulk data storage meant tape drives. Tapes, compared to disks, are slow, both to record and to access data. Although tape is by no means dead, large datacenters now tend to use disk technologies for long-term storage. The slowness and difficulty in accessing tape archives often limited the value of this stored data.

Cloud vendors often offer tiered storage. At the top of the tier, using specialized hardware such as solid-state drives, access is very fast, but the cost is relatively high. At the lowest tier, cost is moderate, but retrieval may take minutes instead of milliseconds. Even top-tier fast data storage is cheap compared to the systems of a decade ago.

Cloud implementations offer the opportunity to store much more data than in the past. In addition, many more transactions run through computer systems, increasing the volume of data to be stored. Mobile devices with global positioning systems have added a whole new type of data that can be collected and stored. Innovations in data processing (Big Data) have made available ways to analyze and use unstructured data, unlike not too long ago when usable information could be extracted only from data stored in hierarchical and relational databases.

Cloud data strategy should take into account these changes. Applications can write more to storage and use new data management techniques to handle the increased volume. This stored data may eventually become a long-term asset for the organization. In general, cloud storage costs are less than storing locally. Consequently, enterprises can store more, especially because new analysis practices can increase the value of stored data.

Understanding Cloud Providers

A cloud provider, or at least a public cloud provider, is a third party. The priorities of the provider are never identical to the priorities of the cloud consumer. Cloud consumers must recognize this fact. Whether the consumer negotiated their service level agreements (SLAs)⁴ and contract with their cloud provider or the provider dictated them to the consumer, a successful cloud implementation is impossible if consumers do not thoroughly understand their SLAs and contract. The consumer’s implementation must accommodate the provisions of their SLAs and contract. The provider may not automatically report SLA violations to the consumer. The consumer may have to detect and report violations to the provider and request payment of penalties. If there are misunderstandings, the consumer must take an informed stance to hold their own in discussions.

Prepare for Provider Outages

A provider may consider a one-hour outage for a limited number of consumers to be a minor glitch, but when that outage causes a gap in sales during a peak selling period, it may be a major issue to an online retailer. The cloud provider calculates its liability under its SLAs and gives a collective shrug because the loss is manageable. On the other hand, after collecting the SLA penalty from the provider, the retailer still might go out of business.

Most public clouds are reliable, but reliability is a relative term. Even the most reliable cloud service will eventually have some failures. The probability of a failure on any given day may be miniscule; the probability of a failure some time in a year is much higher. Over a longer period, some outage becomes almost a certainty.

The extent of preparation for outages will depend on many interrelated factors. The first of these is the criticality of the uninterrupted delivery of the service. Other factors include the availability of alternative sources for the service, the robustness of the provider’s operations team, and the adequacy of the SLA and service contract for compensating losses from an outage.

A service that could go down for several hours or even days with little effect on the cloud consumer’s business does not need much preparation for a provider outage. The plan may be as simple as a procedure for escalating service outage issues to the person who manages relations with the provider.

When the service is critical, the plans must be more complex. Long before the service goes into production, the service manager should make some critical calculations. In the event of an outage, what portion of the real damages will be compensated by the SLA penalties? Are those penalties certain to be applied? Some SLA agreements have provisions that limit SLAs to certain configurations or circumstances. When a multiday outage starts tearing into the enterprise bottom line is not the time to learn that a service is not eligible for outage compensation because it does not meet configuration requirements. For example, implementations that are not distributed over geographically separate datacenters within the provider’s cloud may have a weaker SLA than implementations that follow the provider’s specifications. It is usually the cloud consumer’s responsibility to see that the implementation is distributed properly, even though the cost may increase.

Managers of critical services should have some plans made for an outage. The first step is to know exactly how to inform the provider of the outage and get their assessment of the severity and likely duration of the outage. Contact with the provider could be direct communication by the service manager, or it could be through the IT department. The IT department may have failover or recovery procedures that they can put into effect. Second, the manager should have an escalation plan within the organization. Who needs to know about the outage? Transparency is often a good policy. Finally, the manager should have a “Plan B” for failures that go beyond the expected. For example, point-of-sale registers may be designed to operate when the cloud is unavailable, but when an unexplained defect or situation shuts down point-of-sale registers, Plan B may be to give cashiers pads and paper to record sales, rather than close the store.

Some outages can be avoided by taking advantage of failover facilities of the cloud and transition smoothly to other facilities. Traditional applications that are ported directly to a cloud environment may not distribute well to remote datacenters. Cloud business planning may need to assess this possibility and require the necessary technical changes, which may be considerable.

The cloud consumer should always assume that outages are possible. SLAs and contracts can compensate for this eventuality, but the compensation is often only partial when the full effects of the outage are considered. Damage to the reputation of the cloud consumer’s business is one such effect. Technical solutions are often costly, but business requirements may outweigh the cost.

Prepare for Security Breaches

Provider security breaches are similar to provider service outages. They are not supposed to occur, but they do, and when they do, the consumer must be prepared.

A cloud implementation, in terms of business, can be breached in two ways: via the cloud provider and via the cloud consumer’s code or the consumer’s interface. Breaches via the consumer’s own code or interface are similar to security breaches that occur with on-premises applications.

Consumer Security

Applications running on clouds have vulnerabilities somewhat different from on-premises applications, but many of the weaknesses are the same. The consumer is responsible for any breaches that occur, just as they are responsible for on-premises breaches.⁵ Cloud consumers should take all the precautions that on-premises systems take. This includes instructing personnel on best password practices, avoiding using the same password to access critical data and functionality, appropriate use of encryption both of stored data and interprocess communication, secure system partitions, network traffic analysis, firewalls, and traditional anti-malware software.

Although some vulnerability is unavoidable, consumers are largely as vulnerable as they allow themselves to be. Security is not free. It is expensive and inconvenient. For enterprises with valuable assets online, such as thousands or millions of credit cards, the justifiable cost and inconvenience of security is very high. Enterprises with less vulnerable value may see less justification. However, they should be aware that value might not be apparent until it goes out the door.

Prevention is usually not enough, particularly for enterprises with large assets online. Despite every precaution, security breaches may still occur. Rogue employees, stolen laptops and phones, or a clever phishing expedition and a second of inattention can all compromise the most carefully secured system. Security should not stop at system compromises. Plans and procedures should be in place to control damage and identify the intruders as quickly as possible.

Provider Security

None of the previous precautions is unique to cloud implementations. They represent good security practices for all systems. Cloud implementations do present special security challenges. Other than private clouds, cloud providers are third parties. Systems running in a cloud datacenter are as secure as the physical datacenter and its personnel. The cloud consumer has no direct control. The datacenter does not belong to them, and the datacenter personnel are not consumer employees. The consumer must rely on the cloud provider to enforce the integrity of the facilities and their personnel.

This is a contractual, not a technical, issue. The vulnerabilities of the consumer are for the most part determined by the levels of security the provider has contracted to provide. This may include physical security of the cloud datacenter, secure communications between datacenters, background checks on personnel, bonding, liability insurance, and so on.

Some of the most insidious cloud security threats involve cross-communication between consumers. One example is the possibility of a defective hypervisor that allows ordinary users to execute privileged commands that allow one consumer’s virtual machines to access virtual machines launched by other consumers. A similar scenario might allow two consumers who share the same storage disk to access each other’s data.

Another scenario posits an illegal organization that stores data on a public cloud. The authorities could confiscate the miscreant’s data and in doing so confiscate the data of lawful consumers stored on the same disk. The lawful consumers would be left with disruption and delay.

The cloud consumer relies on contracts and the reputation of the cloud provider to avoid the kind of scenarios depicted. Consumers with critical data and processes may want to obtain guarantees that their activities run on dedicated processors and their data is stored on dedicated storage devices. They should look carefully at SLAs and determine what portion of the real costs of security failures will be compensated by the SLAs and take steps in proportion to their appetite for risk.

Many organizations may choose to require their providers to have some form of certification. ISO 20001⁶ certification and certificates from the American Institute of Certified Public Accountants (AICPA)⁷ are both prominent. These standards were discussed in Chapter 6. Although provider certification offers protection, cloud consumers should always be wary. Certification is “one-size-fits-all”; it addresses most of the vulnerabilities of most cloud deployments. However, organizations vary widely, and certification does not address every vulnerability of every consumer. The consumer is responsible for identifying areas where the standard does not protect their organization.

Know Provider Backup Procedures

It is tempting to believe that using IaaS or PaaS will relieve IT administrators of all their responsibilities, but that is nowhere near true. Although the cloud provider takes over physical administration, the consumer still is responsible for keeping the software deployed on the platform running properly. That can involve applying patches, overseeing automated load balancing, and performing any maintenance or administrative procedures that involve hands-on intervention. SaaS deployments are an exception. The provider takes responsibility for both hardware and software administration and maintenance. This is one of the attractions of SaaS.

Backup is sometimes a gray area. It is hard to imagine a cloud provider that would not keep their system backed up, and consumers may be tempted to rely on the provider’s backup system. There are some circumstances when this is a reasonable approach. For example, when a consumer subscribes to a storage service, it is reasonable to expect the provider will restore the data if it is lost or damaged. However, that is not certain unless assurance is included in the service contract or SLA.

Data that is in process is more difficult. For example, an application that writes a file or storage in a virtual system is not necessarily writing to persistent storage. Consequently, the concept of “data in flight” may be considerably expanded in a cloud deployment.

Cloud consumers may find it expedient to perform their own backups of critical data. Cloud provider backups are usually intended for disaster recovery. These backups will not help a user who inadvertently deletes or overwrites a file and wants it restored. There are cloud services that address this problem, but they are SaaS backup services for users, not for enterprise failover.

Prepare New Financial Reporting Structure

Usage-based costing of cloud IT resources presents many advantages for managing IT investments in services, but only if the enterprise can make use of them. In a cloud implementation, one of the primary managerial documents should be a monthly report on charges for cloud computing. That report, at its simplest, consists of a single lump sum that rises and falls with the seasons and the business climate. This is the equivalent of running a retail business with a total cost of sales but no breakdown of where the cost went.

Most cloud providers offer the instrumentation and reports necessary for breaking down costs, but making use of the data requires some advanced planning and cooperation between business management and IT. Business management probably wants to see the cloud cost per service delivered by IT and possibly a breakdown by business unit consuming the service.

The problem is that the cloud provider is aware of the virtual machines running, the data moving on virtual networks, and the data being stored, but it has no insight into the services the cloud consumer has implemented on the cloud or how the consumer is using these services. Consequently, the IT department is responsible for implementing ways of breaking down usage.

Usually, this is not difficult. Providers offer ways of distinguishing services, but the IT department has to use the facilities provided. More importantly, business management has to make clear the data that should appear on reports and how it should be broken down. Making these plans early could prevent expensive missteps in implementing the cloud deployment and enable more effective business management of cloud services.

Conclusion

Cloud implementations are a joint effort between business management and IT because cloud computing is a much a business pattern as a technical innovation. If either IT or business management does not participate in a cloud implementation, failure or compromise is a real possibility.

Too often, a cloud implementation starts with enthusiasm from either the IT department or the business management, neither having a clear idea of the level of participation needed for success. Sometimes, a notion appears that an existing application can be quickly ported to a cloud environment and the organization will realize great benefits. This may be true occasionally, but more often, it is not.

This chapter has examined the business side of cloud implementation, pointing out areas where business must pay special attention to the implementation to aid in success.

_______________

¹ITIL also defines a “service catalog.” A service catalog helps manage services in production. It is not for managing services strategically. An ITIL service catalog does not contain services that have been removed from production or not in production yet. There is another concept of a service catalog that is an interactive application that employees use to order or modify services. This kind of catalog is often closely tied to the ITIL service catalog. Occasionally, ITIL service catalogs are implemented as part of service portfolios since there is some overlap in information in the two components.

²It’s worth noting that a rigorously applied service portfolio approach is an effective tool for preventing application sprawl and departmental computing silos, which can be a danger as cloud computing becomes more ubiquitous. Launching a private copy of an application or subscribing to an SaaS service is so easy and quick, small groups can quickly build a stack of applications that isolates them from the rest of the enterprise. This can lead to many of the abuses that appeared in the early days of distributed computing.

³Stuart Rance. ITIL Service Transition. The Stationery Office. 2011. Page 203. The service transition volume goes into detail on shifting responsibilities.

⁴SLAs may be part of a service contract or a separate business document. SLAs spell out penalties and incentives for levels of delivery of services. An example SLA is “For every minute of service outage over 99.9 percent service uptime per month, the consumer will receive $1,000 in credit.”

⁵SaaS and PaaS can be more complicated. For instance, if a malefactor breaches an application by taking advantage of a defect in the SaaS application or a component supplied by the PaaS provider, the breach will ordinarily be the responsibility of the provider. However, if, for example, the malefactor phishes credentials to get into the application, it is the consumer’s responsibility. In any case, the consumer should always read their SLA carefully. The SLA determines who is responsible for what, and that could be surprising.

⁶See www.iso.org/iso/catalogue_detail?csnumber=51986. Accessed September 2015.

⁷See www.aicpa.org/Pages/default.aspx. Accessed September 2015.