text: As a Red Hat technology evangelist, Gordon Haff is a frequent and highly acclaimed speaker at customer and industry events and helps develop strategy across Red Hat’s full portfolio of cloud solutions. He is the author of From Pots and Vats to Programs and Apps: How Software Learned to Package Itself in addition to numerous other publications. Prior to Red Hat, Gordon wrote hundreds of research notes, was frequently quoted in publications like The New York Times on a wide range of IT topics, and advised clients on product and marketing strategies. Earlier in his career, he was responsible for bringing a wide range of computer systems, from minicomputers to large UNIX servers, to market while at Data General. Gordon has engineering degrees from MIT and Dartmouth and an MBA from Cornell’s Johnson School.
  This is the second in a series of posts that delves deeper into the questions that IDC’s Mary Johnston Turner and Gary Chen considered in a recent IDC Analyst Connection. The second question asked:
  In their response, Mary and Gary note the challenges associated with “having to integrate with conventional systems can slow down the entire process and work against the agile, continuous integration/continuous delivery methodologies these DevOps teams often employ.” At the same time, this integration can’t be dispensed with; they add that “IDC expects cloud-native and conventional applications to become more connected and interdependent over time.” (Check out the recent webinar discussing this and other topics: Next-generation IT strategies: Mixing conventional and cloud-native infrastructure–based on a recent IDC survey.)
  So, where does that leave us? Is traditional IT destined to just be a boat anchor when it’s integrated with cloud-native IT? (And make no mistake, integration is an inevitability.)
  This is the first in a series of posts that delves deeper into the questions that IDC’s Mary Johnston Turner and Gary Chen considered in a recent IDC Analyst Connection. The first question asked:
  As Mary and Gary write, there are indeed “cost and performance benefits of greenfield, extreme scale cloud-native applications running on highly standardized, automated infrastructure.” However, as they also note, bringing in the bulldozers to replace all existing infrastructure and applications isn’t an option for very many businesses. There’s too much investment and, even if it were an option financially, the disruption involved in wholesale replacement would likely offset any efficiency gains.
  75 percent of the respondents in a recent survey [1] conducted for Red Hat said that being able to move OpenStack workloads to different providers or platforms was important (ranked 4 or 5 out of 5)–and a mere 5 percent said that this question was of least importance. This was just one of the answers that highlighted a general desire to avoid proprietary solutions and lock-in.
  For example, a minority (47 percent) said that differentiated vendor-specific management and other tooling was important while a full 75 percent said that support for complementary open source cloud management, operating system, and development tools was. With respect to management specifically, only 22 percent plan to use vendor-specific tools to manage their OpenStack environments. By contrast, a majority (51 percent) plan to use the tools built into OpenStack–in many cases complemented by open source configuration management (31 percent) and cloud management platforms (21 percent). It’s worth noting though that 42 percent of those asked about OpenStack management tools said that they were unsure/undecided, indicating that there’s still a lot of learning to go on with respect to cloud implementations in general.
  This last point was reinforced by the fact that 68 percent said that the availability of training and services from the vendor to on-ramp their OpenStack project was important. (Red Hat offers a Certified System Administrator in Red Hat OpenStack certification as well as a variety of solutions to build clouds through eNovance by Red Hat.) 45 percent also cited lack of internal IT skills as a barrier to adopting OpenStack. Other aspects of commercial support were valued as well. For example, 60 percent said that hardware and software certifications are important and a full 82 percent said that production-level technical support was.
  In spite of its considerable momentum, there are still skeptics about whether OpenStack will ultimately succeed. My colleague Bryan Che tackled some of that skepticism in a blog post late last year and I’m not going to rehash his arguments here. Rather, I’m going to make some observations about how OpenStack is paralleling and will likely continue to parallel the adoption of another open source project that I think we can all agree has become popular and successful—namely Linux.[1]
  Linux came about at a time when computing was changing. It had become distributed and the rise of the Web was leading to new functions and new requirements. Much of Linux’ early-on growth came from powering new Internet infrastructure. It was from that beachhead that Linux branched out into more traditional enterprise operating system roles. Similarly, OpenStack is part of the cloud computing wave which is characterized by new levels of standardization and automation combined with an on-demand and self-service approach to delivering computing resources to users.
  Cloud infrastructure and cloud management. As an industry, we conflate these two things far too often.
  This is understandable up to a point. Cloud computing architectures are relatively new and new architectural approaches often involve figuring out how functions are best partitioned and how they relate to each other. The process tends to be pragmatic; that’s how the networking stack first developed. That terminology is often morphing and inconsistently applied (innocently or otherwise) doesn’t help matters.
  The overall building blocks of the private and hybrid cloud stack have now crystallized to a significant degree. The boundaries of these blocks aren’t hard-edged of course; there’s always overlap in the management space given that basic functions tend to come built-in even if they’re superseded at scale or for more complex requirements. But we’re at a point where we can describe the relationship of a cloud platform such as OpenStack to cloud management platforms (CMP)s like CloudForms that shouldn’t be too controversial.