Contributed Article from SiliconAngle by Alan Conley, CIO at Zenoss
Both DevOps and Cloud are high on the hype curve right now and for good reason. DevOps is popular because it promotes agility by moving application responsibility closer to the business need. Cloud, whether public or private, also promotes agility by providing standard services through automation. At Zenoss, we’ve noticed that these are two sides of the same coin – success in one drives success with the other.
So what is happening with cloud adoption in most enterprises? Aren’t organizations mostly moving to public cloud? It’s not what we’re seeing. We think most organizations will eventually use both private and public clouds. Private cloud because some things just shouldn’t move offsite for performance, privacy, and control. And public cloud because no one wants to pay for unused peak capacity all the time. Although lagging public cloud, we are seeing enterprises currently building out private clouds.
Leading IT organizations, many of them our customers, are moving to the DevOps/CloudOps model. They’re moving away from the traditional IT model, where systems analysts develop requirements, application teams pick hardware and software, and operations teams run it. The model makes sense, but the delivery of application needs was lagging, there were over- and under- bought servers, and operations teams struggled with complexity.
The emerging IT model of DevOps/CloudOps often starts when a business unit begins using public cloud for a project. As they achieve success others follow until someone in accounting notices that they’re spending tens of thousands of dollars a month on IT services. And then the CEO/CFO asks the CIO, “Why are people buying public cloud compute cycles when the average server in our datacenter is busy less than 10% of the time?”
Now IT gets serious about the private cloud.
Experience with the first round of virtualization guides them. They simplify hardware by choosing a few compute, network and storage platforms and integrate them in standard configurations. Or they may even purchase pre-integrated solutions such as vBlocks or Flexpods. Integrated platforms offer assured end-to-end optimized usage, performance, and long-term operational savings.
Simplifying what’s running is the next step. First generation virtualization was often accomplished with physical-to-virtual migration tools. Each virtual machine ended up being a little different, making for complex management. In a private cloud, the tenant users start by choosing one of several standard packages from a service catalog. Behind the scenes, cloud automation software creates and customizes the virtual machine according todefined provisioning rules. With fewer basic operating systems and well-defined customization, private clouds have lower complexity and reduce operational expenses accordingly.
The final step in moving to private cloud is adding a layer of tenant service-aware assurance. Service assurance helps with failure awareness and understanding service and tenant impact. In a shared infrastructure system a single failure can affect many tenant applications and generate a large number of sympathetic problemnotifications. Determining the problem’s root cause and identifying which tenants are affected quickly is extremely difficult to do manually.
For example, if a server blade had an issue, you’d need to know which virtual host was running on it, which VMs were enabled on that server, the tenant each of the VMs were associated with, and whether the VMs were part of redundant design or not. With tenant-aware service assurance this is all automated. In a DevOps environment you would even have a high likelihood of automatically knowing which applications, were deployed on which virtual infrastructure. This is actually one of the things that IT can do with a private cloud that’s an operational plus over public cloud providers.
IT Organizations are also creating a CloudOps team whose goal is to provide standard services at a known cost in accordance with corporate security standards. One of the key differences is that a CloudOps group is an integrated team that supports compute, storage, networking, andvirtualization technology so that IT can focus on achieving tenant goals instead of technology goals. Another key difference is the assignment of specific business owners to every application.
One of our customers told us they’re moving applications into this model as fast as they can using something they call the “Scream Test.” If you don’t know who cares about a server, turn it off and see who screams. Since business units are where expenses and value come together, that’s where the application ownership needs to live.
CloudOps and DevOps work together on meeting business needs. Uptime is a key example. When IT was paying for the equipment and running the application, it was easy to say that 100% uptime was a requirement. When the business unit participates in the budget discussion, their DevOps developers can discuss what the cloud can actually provide and intelligently discuss alternatives to achieving goals.
Best of all, CloudOps and DevOps can both work with the business to figure out how to achieve objectives without needing to worry about getting the initial capacity projection for an application correct. A key characteristic of a cloud is elasticity. That is, the ability to scale out automatically.
Not everything falls into a cloud model, but the number of things that don’t is getting lower by the day and the benefits are huge.
