Develop on the Cloud, for the Cloud

Cloud-Based App Development Tools

Subscribe to Cloud-Based App Development Tools: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Cloud-Based App Development Tools: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Cloud Development Tools Authors: Yeshim Deniz, Pat Romanski, Dana Gardner, Zakia Bouachraoui, Elizabeth White

Related Topics: Cloud Computing, Microservices Journal, Cloud Data Analytics, Amazon Cloud Journal, Cloud Development Tools


What the Amazon Outage Means to Enterprises

Deploying and managing public cloud infrastructure is challenging

There has been a great deal of coverage over the last few days about the Amazon outage. Some of this coverage has focused on trying to understand why it happened, some has focused on what the outage may mean for cloud adoption, and some has focused on where the blame should be laid. Almost all of it has been focused on the impacts to start-ups. I believe that the outage provides enterprises with a unique opportunity to explore the challenges inherent in deploying cloud infrastructure and the implications that these challenges have on any organization's cloud adoption strategy. I feel uniquely qualified to help answer these questions because for many years I have had the privilege of having a front-row seat as cloud computing progressed from concept to rapid market adoption, first at managed hosting and cloud provider Rackspace, later with cloud start-up StrataScale, and more recently with Quest Software.

Make no mistake. Deploying and managing public cloud infrastructure is exponentially more challenging than deploying and managing enterprise infrastructure. The reason is quite simple. All of the devices and most of the software developed for managing infrastructure were designed with the large enterprise in mind. It was designed to manage and mitigate external risks and was never designed to address internal risks like those we see in the cloud today. In fact, the majority of cloud outages in the last few years have been the direct result of some internally originated event like the outage that effected Amazon. By internally originated I mean to say the result of unintended systemic behavior and/or the result of some other set of customers' decisions that ultimately impact your computing resources. Think of the worst shared-hosting experience, but on a massively larger scale.

Perhaps an example would help illustrate my point. An outage that occurred in this time frame and which I later became aware of involved a customer who had instantiated a set of public cloud servers running an unpatched version of Windows. The customer set their firewall ruleset to any-any, and within fifteen minutes the servers were comprised and began launching a series of DDoS attacks. The firewall gear, which was virtualized and shared across a large number of this hosting provider's customers, was never designed to address an internal threat like this. Within the matter of a few minutes their internal network was saturated and two-thirds of their customers' websites were offline. This egregious example is only one of many that I could share over the course of the last few years, and the  impacts of events like this and the Amazon outage have far reaching implications for enterprises looking to take advantage of the economies of scale afforded by cloud computing.

Where should enterprises begin? The good news is that there is much in terms of strategies, tactics and procedures that exist today that can be leveraged. One shouldn't throw out the IT playbook just because it's happens to be cloud that we're talking about. Here's a short list of guidelines to think about as you strategize on cloud-enabling your enterprise:

1. Get close to your business. This may seem readily apparent to most of you, but it's still worth saying. Understanding your business, your market and your competition and how they drive shifts in your business strategy is crucially important to developing a realistic and robust cloud enablement strategy.

2. Map existing IT workloads to your business strategy. This step is challenging, but crucial. The inventory you develop and assessments that you make here will help guide and speed you along later in the process. Rate each workload that you identify on a scale of 1 to 3, where 3 means the workload is a core component of your business strategy and delivers medium to high value, 2 means the workload is a core component to your business strategy and delivers low value, and 1 means the workload provides needed context for your business strategy (email is a good example of a context activity, which is often referred to as a "lights on" activity). It goes without saying that any IT workloads that are not aligned with your business strategy are good candidates for resource reclamation.

3. Develop a cloud return/risk quotient for your IT workloads. When it comes to prioritizing IT workloads, I favor calculating a return/risk quotient. Take the business-aligned IT workload inventory that you've just developed and for each item on that list, rate it on a scale of 1 to 10 in terms of the ROI that you expect to get by moving it to the cloud, with 1 meaning "low return" and 10 meaning "high return." Then go back and rate each workload on a scale of 1 to 10 based on the perceived risk to the enterprise should that workload become unavailable or its data become compromised, with 1 meaning "low risk" and 10 meaning "high risk."  Then divide the return score by the risk score and sort the list from highest to lowest. By the way, at this stage of the process don't be overly concerned just yet with the details of how you came to your scores. You can always drill down on these details later in the process, which will serve as a good checkpoint for you. If any specific criteria do occur to you as you are putting your scores together, just jot them down for future reference.

4. Learn about the variety of cloud computing options that are available. Cloud computing offers several options, and these options come in two flavors, namely public clouds (i.e., hosted outside of your data center) and private clouds (hosted inside your data center). Mapping the right workload to the right type and flavor of cloud offering is part science and part art. A complete analysis of these offerings is beyond the scope of this post, but here's a list and short description of what's available today:

  • Infrastructure as a Service Clouds (IaaS). Amazon is the best known example in the public arena, whereas private clouds like our own Quest Automation Platform are common within enterprises. In both flavors, the paradigm of the server is maintained. Infrastructure resources are consumed as virtual servers that are instantiated, scaled up and scaled down as needed and directly consumed by infrastructure end-users in real-time. These types of clouds offer a great deal of flexibility in terms of tuning the application stack and are popular with demanding workloads that require a great deal of customization to deliver performance.
  • Platform as a Service Clouds (PaaS). Platforms like Microsoft's Azure and Rackspace's Cloud Sites offering are the best known public flavors of this type of cloud, and VMware's Cloud Foundry is a good example of a private flavor. This type of cloud computing is in many respects reminiscent of budget shared hosting plans from a consumption perspective. Gone is the concept of a server. You simply upload your application code to a folder on these platforms, and they simply run. The comparisons end there, however. The infrastructure on these platforms is designed to be extremely redundant and automatically scale to meet demand. These clouds offer less flexibility in terms of customizing the application stack, offer much faster time to market and are popular with less demanding workloads like static web content or less-complex dynamic web applications.
  • Software as a Service (SaaS). This is perhaps the most recognizable form of cloud computing to end-users and is only offered in a public flavor. Platforms like and Webex are the best known examples of this type of cloud computing, where you simply login to a website and begin consuming applications that are hosted outside of your data center. It is the least flexible of the cloud computing options, the easiest by far to consume, and offers the shortest time to market. For these reason it is a popular option for well-understood context workloads like email, sales force automation and customer relationship management.

Based on these descriptions you can see that, generally speaking, solutions like IaaS clouds are best suited to supporting demanding, core enabling computing workloads; PaaS clouds are best suited to less demanding, core enabling computing workloads; and SaaS clouds are best suited to context-supporting workloads. This conceptual framework lines up very nicely with the business strategy measure that you applied to your workloads earlier. The return/risk quotient will also serve as an effective guide to determine the right flavor cloud computing (i.e., private versus public).

5.  Map your workloads to the right flavor and type of cloud computing. This step in the process is actually much easier than you might expect because of the earlier steps you've conducted, but it still requires a bit of art to make it relevant for your enterprise. The art comes into play as you begin to formulate the proper alignment between your return/risk quotients and the demarcation between private cloud and public cloud implementations. Below are two examples of this mapping matrix definition. In the first example, Enterprise A has placed their demarcation for private versus public cloud implementations farther right on the return/risk quotient axis. This is representative of an enterprise with above average risk sensitivities. In the second example, Enterprise B has placed the demarcation line farther to the left, denoting lower than average risk sensitivity.

Figure 1: Mapping matrix for an Enterprise A with above-average risk sensitivities

Figure 2: Mapping matrix for Enterprise B with below average risk sensitivities

As an example of how this mapping works in practice, let's say that Enterprise A is a healthcare provider with extremely high sensitivities to risk because of their regulatory climate. They have identified a workload for corporate email that represents a context activity within their business strategy. On the surface this would seem like a likely candidate for a SaaS cloud. The project has a modest return on investment for migration to the cloud (return = 5) and a medium risk of exposure to the enterprise (risk = 5), for a return/risk quotient of 1, which puts them squarely within the guidelines for a private cloud solution. Since there are no private SaaS or private PaaS offerings available for this type of a workload, they decide to implement their solution on a private IaaS cloud. Figure 3 reflects this decision.

Figure 3: Mapping exercise in action for Enterprise A

6. Use common sense. It probably goes without saying, but you should always apply common sense to these types of exercises. The guidelines laid here are just that, guidelines. You may decide, for example, that 1 to 10 is too broad a range of measurement for your return and risk analyses and decide instead on a scale of 1 to 3. You may summarily decide to discount SaaS clouds from consideration altogether because of the context of your enterprise. You may decide that no matter what your mapping matrix says workload X needs to go on a private IaaS cloud. In the end you when it comes down to assigning workloads to the right cloud solutions you should listen to your instincts and do what feels right for your enterprise.

Dwight D. Eisenhower was famously quoted as saying that "In preparing for battle I have always found that plans are useless, but planning is indispensable." Remember that the guidelines presented here are meant only to steer you on a journey of discovery that will better prepare you to measure the value and risks associated with the various types of cloud computing, and establish a cloud enablement strategy that's right for your enterprise. Ultimately the success or failure of this exercise will largely depend not on how rigidly you followed these guidelines, but instead on how well the process has informed your thinking and leveraged your unique expertise and insights.

More Stories By Dave Geada

Dave Geada is the CEO of Buzzoink, a mobile search SaaS start-up that delivers advertising solutions to food retailers by enhancing the in-store shopping experience and building brand loyalty. He has over 15 years of experience in technology marketing, working for name brand companies like Computer Associates, Network Solutions and VeriSign. For the last seven years Dave has been marketing cloud computing solutions to both SMB and Fortune 5000 customers at companies like Quest Software, Rackspace and StrataScale.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.