Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
My encounters with commercial clients in the DevOps space have been exciting, curious, political, and challenging. What most don’t realize is that DevOps is not just about infusing tool automation into a delivery pipeline, but it also has to do with re-mobilizing and challenging the status quo when it comes to “who does what”. As teams become more tightly integrated, functional lines blur, and uncertainty may set in.
I find more and more, that clients and colleagues want to know:
- What happens to the operations/run tower people if tools like UrbanCode Deploy automate the promotion of applications and releases to run-time environments?
- What happens to our system administrators and “build out” teams, if tools like Chef, Puppet, Vagrant and pattern-based provisioning systems like IBM Cloud Orchestrator and UrbanCode Deploy with Patterns can perform solution stack build outs with minimal custom network, hardware, software, and middleware configurations?
- If developers can provision and deploy their own apps, what do the sys admins do?
- Will Operations Staff be replaced by tool automation?
The truth is, now, more than ever, a savvy, astute, and innovative operations staff is essential to successfully execute effective DevOps within the enterprise.
As development and test teams are being empowered to deploy their own applications with tool automation, Operations will need to shift the focus to enabling and empowering these teams with standardized, reusable automation assets. Design, development, maintenance and management of these automation assets will be the core foundation of DevOps success within the enterprise. A corollary to this is a set of standards and policies must be clearly defined and adopted as a framework for implementation.
Standardization is paramount to making DevOps successful on a wide scale in the enterprise. If we were to think of our applications as a “solution stack” of network, hardware/virtual machine, operating system, middleware, and custom application components, standardized assets in each of the solution layers would enable faster assembly, development, test and delivery of a solution.
When it comes to effectively enabling the enterprise for DevOps, you must become a hater of snowflakes. Snowflakes can be elegant, but they are unique and difficult to automate with tools. Examine applications and systems for uniqueness…and ask, can it be standardized? Typically, snowflakes occur higher up on the solution stack at the Application or Middleware layers. Network teams are not likely to implement new security policies for each application. However, moving up to OS and middleware, uniqueness is more likely to occur (OS release versions, MW versions and packages and so on).
Once opportunities have been identified for standardized assets, operations teams must mobilize to enable the enterprise for automation:
- Encapsulate enterprise policies in standardized automation assets (which can be reused across the enterprise).
- Centrally manage and maintain automation assets within the enterprise (to maintain standard and policy compliance).
- Evangelize, encourage, and incentivize the use of automation assets in delivery of applications.
- Provide a continuous delivery pipeline tool set (preferable, as a service) providing an infrastructure to enable the automation assets for development and test teams
Automation assets can occur at every layer in the solution stack, providing an opportunity for the new Operations team to inject enterprise influence and compliance at every level. This approach ensures standards and compliance, but also relieves application development and test teams from worrying about whether their application violates any corporate policies.
Examples of automation assets and some enabling technologies are shown below, but this is obviously not an all-inclusive list (even a hardened shell script can be an asset). The point is, for each layer in the solution stack, assets and corresponding enabling technologies can be chosen to invest in. Some technologies can address multiple layers in the solution stack.
There is clearly a lot of good, solid, critically important work for the new age Operations team to manage and maintain. Interfacing with enterprise architecture and corporate standards groups are essential. However, the focus remains largely around empowering and enabling delivery using standardized assets.
You can also watch this short video that I recorded recently. Please do share your feedback on this blog and how you see the evolving role of IT Operations in a DevOps Era.
About the author
Andrea Martinez is the DevOps Solution Leader for Cloud Services in IBM. Andrea’s mission is focused on delivery of DevOps solutions in cloud and traditionally hosted environments. Andrea has lead the solution architecture, implementation and initial adoption of one of IBM’s first DevOps Deployment Offerings. As a member of the IBM Academy of Technology, and a certified Thought Leader in application architecture, Andrea is keenly interested in enabling and empowering practitioners with innovation and technology to deliver solutions faster.
