Let’s start the new year right with one of my current favorite topics for discussion: automation. In this article, I concentrate on the second-day operations type of automation. Second-day operations is quite a different beast from build and decommission automation, in that it incorporates several different approaches to automation.
Articles Tagged with Automation
Bringing about change. One of the hardest things to bring about is change, and there is no place where that is truer than in the world of IT. When anything happens in the environment, the most common response from IT professionals is, “What changed?” That almost sounds like a Family Feud question, but I digress. The irony of that response is that most of the work that happens in the data center is driven by changes, change tasks, or incidents. Resistance to change has to do with the method and procedure involved with completing the changes or closing the incidents.
In my opinion, three main areas, or segments, are established for automation in the modern-day data center. The first segment is provisioning, the next is second-day operations, and the last, to complete lifecycle management, is the decommissioning process. Every data center is similar to others, but what makes each different is the choice of technologies used in its environment. In this article, I focus on philosophies of automation used in data centers.
Container technologies and developers work with applications. End users use applications. Yet, administrators think about the systems that make up the applications with tools that are not application-centric but rather system-, VM-, or container-focused. Because the tools are not focused on the application, the definition of the application is unknown by those who support the application. This is in serious need of changing. In fact, until this changes, a business cannot transform into the next generation of cloud-native applications. It just will not be ready. So, then, how do we get ready?
There is a huge disconnect between the DevOps world and most current enterprise IT organizations. One element in the gap is that developers do not want to know about infrastructure. Another is that the operations team does not trust developers to make changes to the production infrastructure. Developers want to focus on their application and the value it delivers to the organization. Developers want to know the characteristics of the infrastructure but do not want to build it or operate it. As a result, DevOps does not mean the end of the operations team. In fact, I see the reverse as being essential. The operations team is absolutely critical to the success of DevOps methodologies. The developers must be able to trust that the infrastructure has specific characteristics: characteristics like performance, connectivity, availability, and uniformity. To enable this trust, I believe that the operations teams are going to need to become more like developers. I call this OpsDev.
Strategy for cloud automation: there are a lot of articles about the cloud and cloud computing, but I have not seen too many that discuss different strategies to consider when it comes to the automation in your environment. I did come across a nice post called “Legacy Job Schedulers: 3 Effective Exit Strategies to Consider,”1 by Jim Manias from Advanced Systems Concepts, Inc., that had some interesting points and thought it would be a great topic for discussion.