How much private cloud do you really need? A private cloud is all about the IT department getting out of the way of its internal customers, enabling business units and individual developers to provision their own VMs and get on with doing their jobs. But building and operating a private cloud is a complex, and therefore expensive, task. There needs to be a large payoff before there is a real business benefit. Some businesses don’t really need a private cloud platform. Often, their business processes will prevent real self-service on their private cloud. For these organizations, there may be simpler ways to achieve their desired business outcomes.
Articles Tagged with Automation
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.
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.