Picture credit: https://twitter.com/dameelizabeth

“I fell off my pink cloud with a thud,” a quote from the legendary American actress Dame Elizabeth Taylor, relates to ‘her habit of falling in love quickly, getting married, and the ensuing reality check that almost inevitably led to the divorce courts.’ Pink is associated with romance, perhaps the thud is referring to the judges gavel when yet another Liz Taylor divorce was closed (toptenz.net). Colloquially, being in a “pink cloud” indicates a state of high spirits and ecstasy, as one may experience, for example, upon achieving success in a major endeavor. Can such success in the “move-to-cloud” incur a feeling of being in a pink cloud, and conversely, will a major failure resulting from such a move feel like falling with a thud?

Move-to-cloud—migration of existing and emerging computing infrastructure and applications to the cloud or the construction of new applications directly in the cloud—is now a prevalent IT modernization strategy. The huge “Cloud-Shift” currently underway is fueled by high expectations of big benefits in cost efficiency, operational speed, and business agility. In fact, Gartner estimates that the cumulative cloud-spend will be a trillion USD by 2020. Of course, such benefits will only accrue if the migrations to (and on) cloud are successful.

In established companies, computing infrastructure and applications landscapes are quite complex. Large companies on-board several cloud technology platforms each with their own nuance; a cloud migration method that works for one such platform will not exactly work for another (“RightScale State of Cloud 2017” report).  So, for non-trivial cloud migrations, we are forced to deal with hybrid (public+private+on-premise) and heterogeneous (multiple technology platforms) cloud landscapes.

If you are starting to wonder if the odds that the targeted success of moving to cloud could be in danger, you may be right unless you have taken care of certain essentials by design. During the early years of cloud adoption, I witnessed many CIOs move large chunks of infrastructure or applications to the cloud only to change course (at great cost and agony) a short time later. Major issues with those failed cloud transitions included lower performance; broken integration, interoperability, or business continuity; inadequate security or data privacy; and increased costs. Many of these problems were blamed on cloud service providers; in some cases, they resulted from poor design or implementation, and in other cases, opinions were divided as to what went wrong. While useful narratives of failures related to cloud adoption are not as easy to find as the success stores (failure is often shunned), articles on the subject do occasionally appear. For example, a 2015 article in InformationWeek by Andrew Froehlich, titled “9 Spectacular Cloud Fails” listed several service failures from cloud service providers that included most of the top names in the industry.

One way to guarantee system performance is to do a good job of gathering all the necessary functional (what the system must do) and non-functional (essential qualities that the system must possess) requirements up front, ensuring that they are incorporated and fulfilled during system design and implementation. For traditional infrastructure and applications, the art and science of functional requirements (FRs) and non-functional requirements (NFRs) are well developed but still evolving for the move-to-cloud.

However, finding the essential FRs and NFRs for a move-to-cloud will not be frustrating if investigated logically (see figure ). For starters, one must have easy availability of the services needed to utilize a cloud system (e.g., operating systems, databases, options for virtualization or containerization, popular development and testing frameworks, source code management, emerging technology services like IoT, analytics, machine learning, cognitive computing, AI, etc.). These can be seen as very basic (functional) requirements that are easy to locate. Requirements that are either more specific or demand special attention when building up a cloud system may include the following (see graphic):

  1. Functional: The main categories in the context of legacy migration are “elasticity of compute, storage and network capacities, and the associated unambiguous pay-per-use terms” and “high automation in environment provisioning.” In the context of cloud-native applications these are DevOps tool-chain support, and automation and service-oriented dev/test environments.
  2. Non-Functional: Here, the main categories are performance (response time, throughput), reliability (load-balancing, availability, disaster recovery), security and compliance (related to access and usage of HW/SW and data), and service management (management of operations, run costs, SLAs).

In the case of multi- or hybrid cloud environments, integration is another key functional requirement just as interoperability is a pivotal non-functional requirement.

If you are starting to wonder why some of these FRs (or NFRs) are not similar to what you have seen or used in the past, then let me point out that here we are primarily discussing the FRs and NFRs of cloud-enabled systems, rather than the applications that actually run on such systems. The key to move-to-cloud success is being able to ask the right questions early in the game in order to derive the essential requirements, incorporate them in the design, validate them in the implementation of the cloud system, and devise and use the appropriate contingency strategies to tackle situations not covered by these requirements.

Walter O’Brien, an Irish businessman and media personality, once said, “As software engineers trained to turn ambiguity into absolutes, and fuzzy requirements into ones and zeros, we had a ‘eureka’ moment when we realized that our training had broader real-world applications.” These are wise words to follow when gathering requirements: do not go overboard, stay pragmatic, and focus on the ultimate end-use benefits.