Trevor Pott is a guest writer with Catalogic Software. This is the first in a series of blogs around DevOps and other topics.
InterConnect 2016 is upon us. The conference, billed by host IBM as "the premier cloud and mobile conference," runs from Feb 21-25 at the MGM Grand and Mandalay Bay in Las Vegas, Nevada, USA. In addition to IBM, numerous IBM partners will have booths and be doing presentations at the conference. Among those partners will be Catalogic, and we'll be talking about the unofficial topic of InterConnect: DevOps.
Unless you've been living under a rock for some time, you've heard of DevOps by now. Maybe someone has shoved a copy of The Phoenix Project at you, or evangelized ad nauseam about how DevOps will transform your business. Phrases like "agile,” "responsive," "continuous delivery" and "requires a complete culture change" will no doubt have been part of such discussions.
Catalogic cannot promise you that you'll escape that at InterConnect. DevOps is the tech topic of 2016 and promises to become as important, overhyped, muddled and abused as "cloud." Fortunately, Catalogic isn't here to sell you on culture change, buzzwords or hype. We're here to sell you a piece of software that makes a practical difference in building bridges between the all too frequently warring tribes of developers and operations.
What is DevOps? Everyone has an answer, and each consultant will charge you a lovely fee to explain to you why you need to use their specific methodology in order to "guarantee" success. Catalogic has a secret to tell everyone: DevOps is an idea. Nothing more and nothing less.
The goal of DevOps, at least according to most accounts, is to meld operations and developer teams into a single cohesive unit working in concert with other parts of the business in order to reduce or eliminate delays due to change management or related to the provisioning of new IT resources.
In other words: IT has become to be seen as the "department of no." Every time someone wants something done – especially if they want it done right now – IT says "no." This has been a problem for so long that an entire international movement has arisen to change how businesses do IT.
When done properly, copy data management software, such as Catalogic ECX, is the key to making this work. With ECX, operations teams live in a world of role-based administration, policies and templates. Developers live in a world of self-service IT and infrastructure as code.
Whether the idea of DevOps benefits your organization depends on innumerable factors ranging from the aforementioned "culture" to the tools, business processes and even politics chosen. Catalogic can't guarantee you DevOps success, but we're confident that if you use ECX you'll be choosing a tool that makes the culture shock and politics changes of DevOps a lot easier for IT practitioners to bear.
ECX has traditionally been billed as copy data management software and more or less does what it says on the tin. ECX identifies, tracks, creates and destroys copies of data. We know that this doesn't sound particularly ground-breaking, or related to DevOps in any way. The neat bit is that when you look at it in practice (as opposed to the traditional marketing buzzwordology) ECX and copy data management are, in fact, at the very heart of enabling DevOps.
Let's consider some real world issues facing developers. Developers – or the good ones, at least – do a lot of testing. They create workloads to run their test code that match the environments that run their production code. In a perfect world, every time there was a new patch or other change to the environment that needed to be made, developers would create an entirely new workload with the changes and perform testing against it.
Once an environment was known to be good, that environment would be pushed up to production, data moved into it and life continues apace. This works fine if you're using public cloud providers like IBM's SoftLayer which is the big reason public cloud providers have such a smash hit. Where this falls apart is when workloads exist on premises, or are part of a hybrid cloud solution, in instances where some form of DevOps hasn't already been put in place.
With traditional on-premises IT, operations teams are involved in everything to do with workload lifecycles. That means going through a human. It doesn't work so well when developers have to go back to operations teams to request the creation of new environments, changes to be applied to those environments and environments to be moved into production.
There are very good reasons for this. Operations is responsible for ensuring that developers use infrastructure responsibly. They need to ensure that old or unused workloads are archived or deleted, that idle workloads are consuming expensive all-flash storage and that data sprawl from abandoned workload instances doesn't consume all the available storage...and the budget along with it.
This is where ECX comes in. ECX allows operations teams to create templates from existing workloads and copy them wherever they need to be. It allows operations teams to create policies around workloads that include items such as replication, snapshotting, backups, storage tier usage and even in which cluster or datacenter a workload runs.
Operations teams can define different policies and, through role based administration, give individual (or groups of) developers access to various policies. Developers can then create, copy, move, and otherwise manipulate their workloads as they choose, but only within the boundaries set by operations. In other words, they have the freedom needed to do their jobs, but not enough power to ruin things for everyone else.
In addition to manipulating workloads, operations and developers can both pull various reports and analytics off the system, helping them understand infrastructure usage, trends and uncover real time performance bottlenecks.
Both developers and systems administrators have choices in how they interact with their workloads. An HTML5-based GUI exists for those who prefer the point-and-click approach. The real magic, however, is in the API.
Everything you can do in the main GUI can be done from a script by calling the ECX API. This means that all aspects of workload lifecycle can be scripted, allowing for powerful automated testing setups, triggerable snapshots and backups ahead of major rollouts and automated reporting built into everyday workflows.
ECX is the bridge between developers and operations. The core copy data management functionality allows operations and developers to solve the biggest pain point DevOps seeks to address and does so in a way that doesn't require disruptive changes to either team.
ECX can serve as a starting point for rapprochement, the first baby steps towards the much sought after culture change...one API call and script at a time.
Trevor Pott is a guest writer with Catalogic Software. Trevor is a full-time nerd from Edmonton, Alberta, Canada. He splits his time between systems administration, technology writing, and consulting. As a consultant he helps Silicon Valley start-ups better understand systems administrators and how to sell to them. He currently pens a weekly column for The Register; one of the world’s largest online science and technology magazines, with monthly readership of 7.2 mil. people worldwide.Trevor can be found at http://www.egeek.ca/ for those looking to engage his jedi-like guidance.