Practical Problems with CMDBs
…And How Device42 Addresses Them
Ask around, and you are sure to hear that there exist more than a few “insurmountable” and “unsolvable” problems with CMDBs; or specifically, the philosophy behind the CMDB. At Device42, we agree that the traditional approach to CMDBs makes them very difficult and expensive to implement and even harder to maintain.
Below we’ll discuss why the traditional approach usually fails and why the Device42 approach always succeeds.
[separator headline=”h3″ title=”Do you really need a CMDB?“]
“Layers and layers of systems that pile up over time create … suddenly the whole thing comes crashing down.” — CNN’s analysis of the August 2016 Delta computer crash that stranded numerous passengers
Sometimes you don’t realize you have a problem until a crisis strikes. The bigger your site, and the more machines and instances you manage, the more benefit you will garner implementing a CMDB. That’s not to say small shops will not benefit; quite to the contrary. It’s just that it’s possible for a very small shop to get by without one. When you can see all of your infrastructure without turning your head, and a full audit takes 15 minutes, you can likely skate by without a CMDB.
That said, it’s best to set up a CMDB in the beginning, allowing it to grow organically as you do. Then, as you grow larger, you’ll incrementally reap more benefit from your CMDB. You will also avoid spending the extra time and effort you’d need to invest in setting one up from scratch after you realized you were large enough to warrant one (or too large to live without one!).
What about the many very successful companies out there who are surviving, and even thriving without a CMDB? I think you’ll find these fall into one of three categories. The first are ones who spent a lot of time and effort implementing and maintaining, have developed a CMDB internally, and haven’t labeled it as such. The second has shopped for a CMDB in the past, but been turned off by the bad offerings available on the market at the time, or even lived through a bad experience having actually attempted the undertaking, and possibly abandoned the idea. The third are companies that may not even be aware that they’re working a lot harder than they have to be. They might say “this is the way it’s always been done, and it works, so this is how it has to be,” unaware of the benefits and therefore time and effort a CMDB could save them.
[separator headline=”h3″ title=”Why are CMDBs so expensive to implement?“]
Getting the CMDB of days past up and running was a large undertaking, and often proved laborious, took longer than estimated, and under-delivered. This was the result of many players in the market offering “uni-taskers”, or “point products”, which solved a small, focused portion of the problem, rather than the entire problem. Some offered a CMDB, but not IPAM; while others offered CMDB and IPAM, but no ITAM (Asset Management). Commonly, offerings were spread across multiple products, resulting in further confusion with regards to which modules were necessary to address the problem. There was often a lot of hype and many promises, while the solutions ultimately under-delivered at great expense. This resulted in confused, dissatisfied, and regretful customers.
Living through this experience was part of the reason our CEO founded Device42! He was brought in as an IT consultant to bring up a backup data center 5 days before Hurricane Irene struck. They got the data center up and running just in time but, much to his chagrin, only about half the applications came up because they were unaware of what was running where, and all the interdependencies. He knew there had to be a better way and, after looking at the existing offerings on the market, that nobody had yet gotten it right, and worse, existing solutions were charging way too much for the privilege! He finally understood the reason for all the “CMDB is dead” articles and the reports of no or poor ROI, long implementations, and unsatisfactory results. The market needed an all-in-one product designed by data-center engineers, for data-center engineers.
At Device42, we’ve had happy customers that were able to document most of their IT infrastructure in just a few hours! And they receive a positive ROI from just small parts of the solution. For example, just uncovering software over-licensing and truing up to the number of instances actually in use, many companies are able to more than cover the cost of Device42.
More importantly, however, most companies report significant reduction in risk and significant improvement in IT efficiency.
Another customer was able to reduce their audit time to 1/7th of what was previously required, from 7 days to a single day after setting up Device42. Depending on how big your shop is, and how many people you have to dedicate to an audit effort, those savings alone can be quite significant, as they were for our example customer.
[separator headline=”h3″ title=”Why are CMDBs nearly impossible to maintain?“]
CMDB’s can be hard to maintain because, by design, they are attempting to track and deliver an accurate picture of what is ultimately a moving target. Your data-center infrastructure is likely being updated regularly. You might be adding machines or instances to scale, migrating physical machines to virtual, containerizing applications, or undertaking all of these things at the same time, as regular day-to-day business. On top of this, vendors may be logging in to make changes remotely, and employees are constantly installing and updating software. It’s usually virtually impossible just to track IP assignments.
The old method of Excel spreadsheets and Visio Diagrams quickly falls short, being obsolete shortly after creation. These methods never really addressed the problem: The rate of change in the modern data center is unmanageable when approached with traditional solutions. A manual effort can’t efficiently track the automated, moving target that is the modern data-center, no matter how many employees you throw at it.
A modern problem requires a modern solution, developed with the problem in mind. Device42 was written around the idea of a “Self-Documenting” CMDB. The problem is both a timing problem, in that the best time to document is when you are doing the changes, as well as a technological problem, in that if there are no documentation standards or tools with which to document, documentation can seem optional.
Device42 responds in three main ways. Powerful auto-discovery, integrations with your tools, and deep application analysis. Much development has been undertaken and continues to be done with auto-discovery, ensuring Device42 can automatically discover as much of the infrastructure as possible. When combined with Device42’s powerful integrations, the documentation of changes as they happen becomes part of the process, and thus “bad process” never has a chance to manifest itself. Last, Device42 makes the most out of every bit of data the system has. With advanced matching algorithms, we are able to discover IP to MAC relationships, switch / router / FW inventory, MAC address to switch port relationships, VLAN’s & Subnets, CDP/LLDP neighbors, and recently improved with our Deep Application Mapping Module’s release, very detailed application to application/services dependency chains.
This not only simplifies getting up and running, but ensures your CMDB is an up-to-date, single source of truth that you can rely on. Day to day operational information is always available and to automation, an API call away, while come Audit time you can produce accurate reports faster than ever before.
The CMDB is far from dead — Long live the CMDB, indeed!
Our flexible, scalable design, powerful API, and innovative feature set will provide the tools you need both to document the data-center you’re using today, and the data-center of tomorrow.
Download Device42 — Get your 30-day free trial today!
