The past 4-5 years have forced IT organizations to go through some significant changes as the pace of technology has accelerated greater than ever before. Virtualized resources, converged infrastructures, advanced automation tools, new development frameworks and business users that are smarter and willing to consider new consumption models.
But as the pace of business need have increased, the common thinking is that more and more IT tasks need to be automated in order to keep up. And hence begins the challenge for IT organizations. For years, the device-specific GUI was the interface of choice for many IT professionals (or CLI for the networking crowd), often augmented by various types of scripts. GUIs worked fine, aside from browser headaches, but they limited the ability to scale operations. Scripts increased the pace, slightly, but script maintenance often became a full-time job. Far too often, IT organizations collected a mountain of GUI + Script debt as they added various products to their environments, each with a different preferred operations model.
Modern IT operations tools, Git / Razor / Chef / Puppet / Ansible / Jenkins / Vagrant / Nagios – are now built around modern programing languages and assume that users will have more advanced skills in programing the tools to drive advanced levels of automation. They replace the traditional GUI with a set of APIs (typically based on REST). And herein begins the challenges for IT organizations: Continued »
This past week, at the Structure 2013 conference, I had the opportunity to be part of a panel with Ben Kepes (@benkepes) and Rodney Rogers (@rjrogers87) entitled “Mission Possible: Moving Business-Critical Apps to the Cloud”. The focus of the discussion was real-life examples of Enterprise companies that had migrated their mission-critical applications (eg. ERP, CRM, HCM, SQL Databases, Unified Communications) to public clouds.
One of the topics that we covered, based on a question from the audience, was about the bifurcation of existing applications and new applications, specifically in migration scenarios. The question was “Will this lead to faster adoption of ‘DevOps’?”
While I’m a believer that DevOps and have discussed it quite a few times on the podcast (here, here, here, here), I thought it was important to highlight that there is a non-technical element that is critical to the success of migrating business-critical applications. DevOps is a fundamental operational requirement for anyone building modern, scale-out web applications, but those applications are typically very different than existing (legacy) applications. And in most cases, those existing applications make up 80%+ of the IT portfolio in terms of resource usage and on-going costs.
Just as DevOps is ultimately about providing greater transparency between Developers and Operations, I believe that application migration is ultimately about something I call “BizOps“. Far too often, Cloud Providers talk about the simplicity of migrating applications to their Cloud, focusing primarily on the transition of a VM from on-premise to off-premise. But where problems arise is when that off-premise cloud is fundamentally a black-box to the business (or existing IT staff). Unless a business is migrating to a SaaS application or completely outsourcing the business-critical application, it can’t be overstated how important it is to maintain a level of transparency between the Cloud Provider, the Business and IT. This is “BizOps”. Continued »
A few weeks ago, Dell acquired Enstratius. They make excellent software for managing and governing multiple cloud environments (via the APIs), and we’ve had their leadership team on the podcast a few times (here, here). They primarily delivered their software as a SaaS application, although it could also be run on-premise. Since the acquisition, Dell has shifted their Public Cloud strategy and now Enstratius products are the core of a plan to let customers leverage resources from multiple cloud platforms. And I believe the fact that it can be delivered as a SaaS application was key to making that shift. It made it much simpler for customers to begin the process of consuming cloud resources, instead of having to setup tons of equipment (hardware/software/security) on-premise.
Last week, a friend that works quite a bit with VMware environments sent me this “BOM” (Bill of Materials) for a reasonable sized setup to create the full vCloud Suite (vCenter, vCloud Director, vChargeback, vCAC, vCNS, vCO). What jumped out at me was the breadth of things that had to be in place to get a Cloud environment up and running. Windows, Linux, Web Servers, multiple Databases. This isn’t uncommon for any Cloud Management Platform (CMP) – OpenStack, CloudStack, etc. – and would typically require teams with a variety of skills to coordinate putting getting this configured properly.
- 20 Management servers: 2x vCenter, 2x DB servers for vCenter/vCloud/vChargeback, 2x vCloud Cells, 2x vCNS Manager, 2x DB for vCAC, 2x WebServers for vCAC, 2x vCAC DEM Orchestrators, 2x vCAC DEM Workers, 2x vCAC Agent Machines, 1x vChargeback server, 1x vCO
- 8 Databases: 2x vCenter Update Service, 2x vCenter, 1 vCloud, 1 vCAC, 1 vChargeback, 1x vCO
- 7 Management Interfaces: 2x vCenter, vCloud, vCNS, vChargeback, vCAC, vCO
And again last week, Gartner analyst Alessandro Perilli (@a_perilli) tweeted:
Cloud management platform vendors should seriously consider a SaaS delivery model. Today’s solutions too complex to deploy, scale, expand.
— Alessandro Perilli (@a_perilli) June 3, 2013
Perilli is one of many people at Gartner that covers the Cloud Management Platform space, so he gets to see the breadth of offerings in the market from many vendors.
So this ultimately begs the question, “Should Cloud Management be delivered as a SaaS application?” Continued »
Remember “Cloud in a Box”? It has come in various iterations over the past 4-5 years:
- “Pre-Defined” or “Pre-Validated” all-in-one racks of equipment
- Hardware Reference Architectures
- Hardware + Software Reference Architectures
- Software-Only Design Docs that are “hardware agnostic”
Lots of vendors or systems integrators have promised to deliver a cloud to their customers in a pre-defined package, but it is typically missing one critical component – OPERATIONS. And when you think about it, the operational model is cloud computing, so it begs the question – are cloud operations transferable?
Recently GigaOm wrote about the latest round of Cloud Providers trying to bring their version of cloud to a new set of customers. Others have tried this or are currently using a similar strategy for both IaaS or PaaS platforms, including Apprenda, Joyent, Rackspace, Virtustream, and VMware (both CloudFoundry and vCloud).
While operations does include elements of technology, the vast majority is driven by people skills and company specific processes. This is why you’ll see cloud pioneers like Netflix open-source many of their internal tools, or Rackspace give up leadership in OpenStack to the OpenStack Community, because their expertise and learning-curve advantages are in the operations of their cloud environments. The AWS APIs are open (documented), but they don’t expose much of their internal operations.
But what makes the operations so difficult to transfer? Continued »
An interesting discussion took place on Twitter yesterday, spurred by one of my favorite industry analysts (Simon Wardley, @swardley). I’ve written about his ideas, analysis and outstanding blog before.
While it was an excellent discussion and did surface a few fringe industries that might fall into this category (undertaker, local hair-salon, etc.), the general consensus was that every business today is essentially a tech business. While it’s fairly easy to highlight this with companies where technology is their core product (eg. Netflix, Facebook, etc.), it’s also not difficult to see how technology is core to businesses that don’t make technology-centric products (eg. tractors or farm equipment).
For example, if you’re John Deere (just an example, don’t have insider information on their operations), you obviously have a complex supply-chain in place to be able to pull together all the elements that make up a tractor. They also need sophisticated analytics systems to be able to forecast sales, costs of raw materials, currency exchanges and other macro-level things that could be effected by the economy, government policy, etc. Then within the tractors, there is an ecosystem building around tools and applications that can help farmers better manage their fields. Somewhere all the data being collected could be creating new “big data” knowledge that could be improving crop yields, fuel efficiency of tractors, etc.
When I think about “transforming IT”, I tend to think about the adoption of new technologies, reducing costs and improving worker productivity.
When I think about “transforming the product/ecosystem”, I tend to think about making data accessible to open APIs, or expanding areas where value can be added to a product (customization, etc.).
When I think about “transforming the business”, I tend to think about using technology to eliminate an element of the existing supply chain. Netflix is a great example of this (remove the need to obtain physical media at a store or kiosk). iTunes is another great example (remember record stores??). Sports has been going through this for the last 10-15 years. But it’s harder to think of examples of these types of transformations where the business isn’t entirely based around technology. It does create some blurred likes, such as how Bechtel is using technology to enhance how they manage contractor relationships and project management.
So this is one of those areas where definitions might actually be more of a hinderance than a structure to help companies understand how to plan for transitions or transformations. Regardless of what definitions people use, I’d suggest that there are a few areas that need serious consideration:
- Do you understand your supply chain and have you gone back and examined it lately with an eye towards how technology (or technology partners) might be able to help reduce links? Have you looked at how new technology could enhance the existing portfolio? [Example: With airlines struggling so much, why haven’t any of them leveraged their footprint at major airports + telepresence technologies to create augmentations for the output of a large percentage of travel – business meetings?]
- Do you understand the potential ecosystem that could be created around your business, your product or (most importantly) your data? We explored the data element on the podcast. This is actually another variant of the supply-chain discussion, but it involves thinking about the value-chain for the business and considering the opening of new doors and some loss of control of the outcome.
- Can you build a better mousetrap? Most people thought Apple was crazy to begin building physical stores when the Internet had proven that brick & mortar business was dead. But they just did retail better than everyone else on the planet. They drew a direct line from the customer’s experience (which involved convenience, repair, physical touch/feel) and aligned it to their goals (don’t sell as massive discounts). Zappos took a similar approach with low-margin shoes – focus on the experience and inconvenience of the past and leverage technology to solve those customer pain points.
- Can you measure every element of the business, not just the things that are reported on the financial reports? Do you understand the things that influence the direct results or the buying process or satisfaction levels? Given that every aspect of our lives is now recorded digitally, there is an extremely good chance that the information is available (directly or through external services).
- The underlying technology is obviously important, but as we’ve seen time and time again, it’s the process and people that need to embrace the change more than the technology. Technology change/transformation is a given. It might take 5yrs or 10yrs, but it’ll happen. Process and business model change doesn’t have EoL dates, it has Chapter 11.
So as usual, Simon Wardley is right about this. But the question becomes, are you transforming technology or transforming how the business leverages technology. They aren’t the same, no matter how many times companies tell you the CIO deserves a table with the decision makers in the company.
I’ve written before that I’m not entirely convinced that the “Build Your Own Cloud” movement is going to be entirely successful, especially if the goal is to enable IT as a Service instead of just virtualizing applications (or the network, or storage, or whatever is the newest Software-Defined *). The amount of change needed to get to the operational state of IT as a Service is just massive, and the majority of it has very little to do with new technology. It breaks ITIL. It breaks existing technology silos in IT. It breaks the current IT budgeting models. And it involves the intersection of change and people, which we all know an have a few challenges.
But as a good disciple of Cloud Computing, I went and read Gene Kim’s excellent book on DevOps, The Phoenix Project. We also had him on the podcast. Travel permitting, I attend the excellent sessions at the Triangle DevOps meetups, run by a bunch of people that do DevOps stuff everyday (operationally or developing products like Chef, Ansible, etc.). When possible, we grab some of them for the podcast as well.
So here’s where I keep seeing the disconnect. For a while, the discussion about Enterprise Cloud was always focused around Private Cloud, which often times meant something using VMware vSphere (and maybe vCloud Director). But when I listen to all the people doing DevOps today, it’s rarely on VMware (or even VM-based) environments, it’s almost entirely using various Linux-based tools and packages. and it’s primarily for web-based or web-facing applications. Not the things you’d typically associate with IT-supplied applications. We explored this a while ago, but I don’t know if it’s changed much, even with things like Windows support being added to tools like Puppet. Continued »
Back in 2007-2008, when the concept of “Private Cloud” began to emerge as a DIY model for evolving IT, there was concern that companies would be locked into a Public-Only or Private-Only decision. Given the maturity of the technologies and IT skills at the time, this created a strategic problem. But then, like a double rainbow made of Skittles and fruity drinks, the concept of “Hybrid Cloud” magically appeared as the unicorn that would provide “the best of both worlds” for long-term IT strategy.
- “Own the Base and Rent the Spike”
- “Application migration”
- “Application Portability”
- “Avoid Lock-in’
Pick your favorite slogan, they were all there. Throw in the ability to dynamically migrate workloads between physical locations and there was a frenzy of excitement over the possibilities of a Hybrid environment.
And then reality set in and people began to realize that the limitations far outweighed the possibilities. Limited Bandwidth. Security Concerns. Ownership Issues. Consistency of Operations. Early offerings such as Amazon AWS could provide a VPC (Virtual Private Cloud), but it had limitations (or “wish-lists“). CloudSwitch did some cool things (since acquired by Verizon/Terremark), but it was cloaked in a security story and hence didn’t get as much visibility as it could have from “Cloud Architects” at the time.
It also led to an explosion of definitions of Hybrid Cloud, mostly to match the needs of a vendor selling their HW/SW, or an Enterprise Architect trying to justify their design to their CIO. Either way, it’s evolved to where Hybrid Cloud can mean any mix of offerings or architectures where the resources and applications are both on-premise and off-premise. And if I squint my eyes just right, my borrowed concept of “Cloud Concierge” might even fit one of these definitions.
Fast forward to 2013 and we’re beginning to see a new set of Hybrid Cloud offerings emerge that are backed by both evolving technology and vendors large and small. They tend to fall into these categories: Continued »
The OpenStack Summit took place a couple weeks ago in Portland to announce the “Grizzly” (G) release and to begin the design activities for the “Havana” (H) release (due in Fall 2013). Much has been written about the technology and vendor trends, including a few from my colleagues Aaron Delp and Jeramiah Dooley, which I believe do a good job of highlighting the transition that’s happening in the community and the technology.
Since then, I’ve had a number of business leaders and financial analysis reach out to ask, “What is OpenStack?”. My first reaction is to give them a little bit of history and overview of the technology landscape. But then I’ve quickly come to realize that this isn’t what they are looking for. From their perspective, they want to really understand where OpenStack fits into the broader IT hierarchy and if it should become part of their strategic thinking. Here’s a sampling of the follow-up questions they tend to ask:
What does OpenStack actually do?
In the most basic sense, OpenStack is a software framework that coordinates the services needed to provide on-demand computing/storage resources for applications. Those services include computing, hypervisors, storage, networking and security. From a user perspective, if OpenStack is implemented correctly, it should just look like a few menus and clicks that let the application owner say, “I need this many resources to start, then I’ll want to grow or shrink that number over time, and I’d also like a few other services to augment my application (backup, geographic resiliency, load-balancing, etc.” If OpenStack is used as part of a more complex system, those menu items would be replaced with programmable APIs. [NOTE: This same description could be used for almost all “cloud management platforms” in the market today.]
OpenStack is not a company (eg. Rackspace), although some companies are using OpenStack as part of their commercial services, and some companies are trying to sell packaged version of OpenStack.
In the fall of 2012, VMware announced their “Software Defined Data Center” strategy. It articulated a new plan to help IT organizations become more <agile, nimble, responsive, frugal, insert buzzword> and evolve to delivering “IT-as-a-Service”, with software-elements playing the critical building blocks for infrastructure (VMs, Storage, Networking, Security). It is being targeted at the same buyers that made VMware vSphere purchases in the past – centralized IT organizations and IT infrastructure teams. It’s a strategy that plays to their existing installed base of hypervisors, but it leaves several VMware experts asking “Does VMware know Cloud is all about Developers?“. The “Software-Defined” mantra has since been picked up by many companies in the IT industry as a way to refresh their products or align to their potential buyers.
In 2006, Amazon launched the first of their AWS (Amazon Web Services) services, EC2 (compute) and S3 (storage). AWS was targeted at development organizations looking to change the pace and economics of how applications were developed for the web. Since then, they have rapidly grown the number of services to include databases, long-term storage, DNS, CDN, queuing and many other capabilities. The quantity of services have grown to a point where many people ask if AWS is still an IaaS (Infrastructure as a Service) service or moved up to become a PaaS (Platform as a Service) service. Where it fits into the NIST definition seems to be irrelevant to the architects of AWS, who are focused on delivering a set of scalable services for developers looking to build next-generation applications (web, mobile, analytics, etc.). It’s this structure that recently had Jeff Sussna (@jeffsussna) writing “Services-Dominant Logic: Why AWS is So Far Ahead“.
While both of these approaches are being marketed under the umbrella term “cloud computing”, it’s becoming increasingly clear that they are targeting very different groups and they are targeting very different value propositions.
As OpenStack has begun to mature over the past 18 months, there has been some debate amongst the leading developers about the focus of the projects. On one side are those that believe that OpenStack is competing with VMware. On another side are those that believe that OpenStack is an alternative to Amazon’s AWS. Still others focus on a group of services that could create an open system of interconnecting many clouds.
One of the powerful aspects of an open source project is that developers or companies can take the code and use it any way they choose. Target a certain market. Target certain use cases. Target certain business models.
And in return, users of the software can decide what they want the software to do. They can modify the software if they have a specific need. They can buy packaged versions and use the embedded functionality.
For a project like OpenStack, which is maturing during a time when the market is already full of competing offers, it will often be compared to an existing expectation (or experience) that users have of other products/services.
An example of this is a simple question I posted on Twitter yesterday. In the “Grizzly” release, support for VMware ESXi hypervisor has been added. So I asked:
The reason for my question is that I’ve heard a number of Enterprise IT organizations say that they are planning to explore OpenStack in the coming year for their Private Cloud (or Virtualized Data Center) environments. Given that VMware vSphere has 60-80% marketshare in that market segment, many of them are also curious about reusing existing investments in hypervisor licenses, and Live Migration has become a standard capability for Enterprise IT organizations and legacy applications. Continued »