The appeal of cloud computing is financial: rather than buying infrastructure, rent it. The problem with this financial solution is it distracts the cloud user from the responsibilities that remain after moving the applications out of the enterprise – responsibilities called systems management comprise IT Infrastructure and Operations, or I&O. This article reviews some of those functions in light of a cloud migration.
The Pillars of IT Infrastructure and Operations
IT Operations perform many tasks to keep things running smoothly in the data center, whether it is local, remote, virtual, or cloud-based. Organizations focusing on efficiency drove two major theories for improving the quality of IT Operations: ISACA’s Cobit model, and the IT Infrastructure Library (ITIL).
Cobit (Control Objectives for IT and related Technologies) arose from the Information System Audit and Control Association (ISACA) which built a process model for IT Operations. For each process the Cobit model defined its goals, inputs, functions, outputs, and appropriate validation techniques. This had many useful – but unexpected – consequences. It allowed organizations to model the job role of the individual(s) doing the work, so HR could develop job specifications for open positions consistently. It also let organizations define the functions of supervisors and managers in objective, business-relevant terms, eliminating organizational fiefdoms and data hiding (lowering the level of politicization). Most importantly, organizations could use the process model to assess their performance, develop KPIs, and establish a maturity level description of each position.
The Cobit model shows the principal functions and how they relate.
The IT Infrastructure Library (ITIL) defines roles and responsibilities by focusing on critical processes within I&O. ITIL evolved over time, at one point proposing a Configuration Management Database (CMDB) which turned out to be useful as a concept but not implementable.
Performance management has a long history in computing. Early machines were constrained in every dimension – processing power, addressable memory, I/O speed, storage space, and cooling capacity (due to electricity consumption). Although cloud significantly increased available resources, services and applications still require monitoring to sustain acceptable levels of performance. These include response time, startup (initialization) time, recovery time, and resource consumption.
In the cloud, applications can use far more resources than they need – but that elasticity is not free. Performance management tracks real-time resource use to alert the business to wasteful design or faulty implementation.
Capacity planning projects future consumption to guide future spending. When dealing with physical infrastructure, the cost of capacity planning (training, tools, and monitoring) is offset by the savings in future technology acquisitions. A leased amount of capacity locks the buyer in to a particular set of terms and conditions. The appeal of the lease is the low cost of technology, compared with current open market price. But the lease runs for five years, by which time the technology’s price has dropped significantly due to Moore’s Law. If the buyer needs more gear, the price will be as it was four years ago – and the great deal looks a lot less interesting. So, the error in overestimating capacity requirements was small compared with the financial penalty for underestimating.
The same rule applies to cloud. Be wary of “too good to be true” deals on capacity that cover multi-year acquisitions. Getting more than you need up front may save you from expensive elasticity later.
The capacity planning analysis only makes sense if you have sufficient historical data on utilization, and if your organization uses that data to improve capacity planning accuracy over time.
Whether following waterfall, agile, or DevSecOps, organizations need to know what programs and services are in production at any point in time. Well-managed IT organizations have effective processes to introduce new functionality and fixes into their production environment. Traditional release management procedures may have been unresponsive to business time requirements, but DevSecOps does not mean abandoning controls. As long as the path code taken to get into production is adequately monitored, it need not introduce unreasonable delay. The classic Change Review Board approach made sense when releases were scheduled months in advance. As the SDLC evolves, appropriate controls must also evolve to preserve the integrity of the production environment. When a problem occurs, troubleshooting will require a snapshot of the environment; correcting the defect will require reasonable audit controls and a reliable process for updates.
Cloud is very easy to buy, and so inexpensive that users can purchase it without going through any procurement oversight. That can introduce unknown attack surfaces into the environment. Enterprise leadership should develop a policy stating that cloud acquisitions should be vetted and enable the information security team to support such vetting so that the exercise doesn’t become meaningless. An understaffed effort will lead to one of two outcomes: Either the review is trivial and approved, or it is trivial and is disallowed. In the former case, the information security posture of the organization is weakened; in the latter, the employee will simply proceed without approval – and the information security posture of the organization is weakened.
Configuration management governs the arrangement and planning of IT infrastructure components, both physical and logical. This discipline has grown more important as organizations use distributed resources supporting business initiatives. Maintaining an effective software asset management database provides three key benefits: First, you will know what your current and planned spending are. Second, you will know if an insecure production component is installed in your environment. Third, is the ability to assess the unused capabilities in the current production suite when considering acquiring a new product. Studies consistently show that most organizations use less than 1/3 of the capabilities of their currently installed software.
The more than two dozen systems management disciplines are especially relevant to organizations moving to cloud. Review the ISACA or ITIL process guides to see which are most relevant to your environment.