The centerpiece of modern IT management has long been the configuration management database.

CMDB, or configuration management databases, appeared as the original unique source of truth on the IT environment. IT experts rely on this source to manage change management; maintain security and compliance; manage IT costs and performance; and tackle troubleshooting and incident management.

But CMDBs are far from perfect.

For example, CMDBs can require tedious manual work. They are as useful as the timeliness, accuracy and completeness of the data they contain. Data in a non-cloud-based CMDB can become inaccurate or incomplete as IT professionals grapple with other pressing tasks. This causes a gradual erosion of the quality of asset and configuration data.

As the pace of IT accelerates and the IT environment becomes more accessible to DevOps developers and non-IT users, the challenges of CMDBs are impossible to ignore. How can a developer quickly deliver resources and services for an inbound application build if the CMDB is out of date or inaccurate, or even missing? Practices like DevOps require more flexibility than the standard CMDB can provide, which begs the question: Under DevOps, is CMDB obsolete?

IT organizations need to review CMDBs and consider alternative practices and tools to fill the knowledge gap.

What is a CMDB?

Simply put, a configuration management database is a repository that stores lists of information and dependencies on a wide range of IT assets – called configuration items (CI). CIs include hardware, software, networks, physical location details, documents, and other media.

Early CMDBs were little more than lists or real database / spreadsheet tools that required manual data entry and updating. As CMDBs matured, additional data discovery and import features made it easier and faster to enter data by collecting details directly from CIs or other sources, such as another database. data.

Ideally, a CMDB has a complete set of details about every CI in the corporate IT environment. The CMDB can accompany tools that query, sort, filter, plot (visualize) and report on the content of the CMDB. These interactions provide visibility into the IT environment. IT administrators make sure everything works as installed or as expected.

DevOps poses challenges for the CMDB

How do CMDBs and DevOps interact?

Agile development paradigms such as DevOps have sparked a revolution in the creation and delivery of applications and services. Activation collaboration between developers and operations teams facilitates more adaptable, efficient and better quality software. CMDBs have been instrumental in this revolution, as the data and information they contain enables faster deployments, faster troubleshooting and incident response, and enhanced compliance and change management. . As with business leaders and IT administrators, DevOps is simply another “user” of the data and information in the CMDB.

But CMDB tools and platforms are giving way under increasing pressure from the proliferation of resources, demands for faster change, and the rise of more relevant platforms and management practices. In these environments, the CMDB conflicts with DevOps activities in two main ways:

  1. Increase in types and volumes of resources.

The initial focus of the CMDB was primarily to track physical hardware i.e. asset management. CMDBs have expanded to accommodate intangible assets, including software and services. Today, most businesses routinely support a range of virtual assets, such as virtual machines, containers, and cloud resources, which DevOps uses for deployments. Now the CMDB must track the 10 VMs running on a physical server and track the dependencies between the VMs and the physical server. The ever increasing complexity is difficult for CMDBs to manage.

  1. Faster change.

Not only do CMDBs grapple with many more CIs in the environment, these things also appear and change faster than some CMDBs can handle.

For example, a traditional physical server is installed in the data center and, once configured, operates without modification for up to five years. But a virtual machine created for assessment and testing only lasts a few months, only to be removed and destroyed after the assessment is complete. And a virtual container can deploy, run, and shut down in minutes or even seconds. Even with well-thought-out automation and workflows, the rate of data creation and modification pushes CMDB technologies to their limits.

As with business leaders and IT administrators, DevOps is simply another “user” of the data and information in the CMDB.

DevOps compatible CMDB alternatives

CMDBs are called upon to hold and return huge amounts of data, including financial details of each asset, performance and configuration profiles, upgrade and change histories, and other details that may be required. completely independent of the actual use of the asset. So CMDBs are sometimes supposed to do too much and expand their capabilities. Some IT organizations are looking to replace the CMDB with a faster, simpler alternative, such as application lifecycle management, to focus on the applications and services, rather than the underlying resources.

Ultimately, the modern IT environment is changing faster than the average CMDB can handle. This leaves gaps and missed updates in CMDB data and allows unwanted configuration drift, which threatens resource availability, performance, security, and compliance.

It’s time to modernize the DevOps CMDB

IT and DevOps teams still need strong systems and change management, but CMDBs alone might not be enough to meet the scale and operational tempo of modern IT infrastructures. Fortunately, there are some simple strategies that help overcome the limitations of CMDB.

Reassess and refocus the CMDBs. Determine if a business needs the scope and content of a CMDB. CMDBs arose when data centers were relatively small and static. A single source of truth with limited scope and rarely changed in content was a practical goal, even when managed manually. The demands of today’s computing can mean that it is impractical, if not impossible, to reliably establish and maintain this single source of truth.

Determine if a CMDB should really contain such complete details for the entire environment. IT departments can shrink and refocus CMDBs to meet specific attributes or goals, such as tracking only critical components and resources.

Improve CMDBs. Advanced CMDBs can include enhanced discovery features that make it easier to find and query physical and virtual entities. From a process or workflow perspective, updates to the CMDB are linked to authorization, provisioning and lifecycle management, ensuring that all changes to the environment, such as the lifecycle of the virtual machine, are captured in the CMDB.

Look for other tools that populate and audit CMDBs. These tools often include machine learning and AI capabilities, which allow the tool to learn how the environment works and to autonomously deliver data to CMDBs and other services.

Remove and replace the CMDBs. Weigh if other management and monitoring tools are more relevant. Today, IT is mainly focused on the maintenance of applications and services. The underlying infrastructure – what is deployed, where it is located and who owns it, for example – is often a secondary consideration. A final alternative is to depreciate and remove CMDBs for the benefit of other highly automated tools that provide the discovery, reporting, auditing, and change management capabilities the business needs.

For example, today’s focus on application and service management is leading to the adoption of more application lifecycle management platforms or more IT operations management and IT service management frameworks. complete. Look for automated tools, such as Chef or Ansible, to make it easier to discover, deploy, and manage configuration.

Look beyond CMDBs to DevOps

As more developers manage operations-related tasks, it is essential to understand the resources and services present in the business, as well as how those assets are configured. This type of information helps IT professionals deliver new resources and deploy new versions of software accurately and securely. CMDBs have long been a bulwark of these efforts, but CMDBs may no longer be the best single source of truth in dynamic and busy computing environments. DevOps organizations are looking beyond CMDBs to adopt lighter, more versatile platforms, such as ServiceNow, Now Platform, CloudBees CI, Red Hat Ansible Automation Platform, SaltStack, TeamCity, and others.



Source link

Leave a Reply

Your email address will not be published.