Digital transformation is the zeitgeist of the moment for many businesses: this year most are transforming themselves digitally in some way or form. What does that mean? Well, a reasonable assumption is that they are developing a program to move a good deal of their infrastructure and applications to a cloud platform.
So that’s great, right? Instead of having to deal with today’s legacy IT smorgasbord of equipment, the new world will be homogeneous, automated and run by someone else. As a configuration manager, my life is going to get a lot easier. Or is it?
In the new world, the control and governance within a data centre environment – like the lock on the door that you probably took for granted – may not exist. Purchasing hardware in the cloud can be done by any member of staff using a credit card: this could make things harder rather than easier.
So, to avoid a proliferation of cloud products and to ensure resources are effectively managed, most organisations look to build process around the CMDB. The challenge is that the CMDB itself is going to have to change too. With greater opportunity comes greater challenge.
These challenges need to be overcome. Let’s look at a few:
- Cloud delivery and governance
Ideally all your cloud products would be consumed and managed through a single service catalog. However, cloud vendors each provide their own toolkit of products and tools to support their different offerings. The challenge of creating a single Cloud Management Platform is that effectively orchestrating the lifecycle of these products is not an exact science. The best practice is using a tool like ServiceNow to abstract the user from the complexity of the environment while maximising the features each vendor provides.
- Cost control
As IT moves from physical to virtual to cloud, charging models have become far more granular with resources being paid-for based on usage. The promise of big savings on operating costs makes this an attractive model for many businesses. However this model does come with risk; you may not have the process and governance in place to ensure that services are taken out of action when they are not in use.
- Complexity, scale and rate-of-change
Legacy physical systems require configuration details to be entered in the CMDB after the fact (as part of a process to keep the configuration in sync with the actual configuration). In contrast, for cloud systems it is the configuration information that is used to build and update the resource. Part of this configuration sets the boundaries within the resource can change: this allows the system to scale as required, quiesce itself if not needed, or keep running after a failure.
As cloud evolves these configurations – that represent Configuration Items (CIs) – will become more dynamic and complex, especially as container and microservice architectures become more common. How do you control a CMDB that changes every second? Is there value in doing so? It requires a new approach.
As companies progress their migration to the cloud, the CMDB is more important than ever. It is important to drive the provisioning and management of the many cloud services, to promote a service-based approach and allow the consumerisation of IT. It is also essential to maintain control and governance of cloud-based systems using Incident, Problem and Change management. There is more data to achieve this than ever before but you need to make sure you aren’t overwhelmed by it.
