In a previous blog post, I outlined the characteristics of a CMDB for the DevOps era. In this one I give my somewhat-biased view of how well the Assimilation System Management Suite CMDB meets those needs.

How does the Assimilation CMDB Stack Up?

Those of you who know me, are completely unsurprised that I’d want to compare it against the criteria in my previous article. So, here’s my personal take on how it matches the CMDB characteristics outlined previously. In the next two sections, I use two different symbols: ✔ is used to mean full compliance with the modern criteria, and ✓is used to mean falling slightly short of full compliance with the modern criteria.

Assimilation CMDB Versus DevOps CMDB Primary Characteristics

1. ✔ Discovery-based – everything in the Assimilation CMDB is discovered, nothing is entered manually. This reduces complexity in the IT environment.
2. ✔ The Assimilation CMDB is automatically maintained within seconds or minutes.
3. ✓Support bare metal, virtual and cloud environments. The most information is available on bare metal, the least in the cloud. It is desirable that we add capabilities to be aware of destroying cloud instances (as opposed to stopping them). This integration will necessarily be different in different cloud environments. In addition, we also now have support for Docker environments which is easily extensible to other container types.
4. ✔ Highly extensible. Customers can easily discover unique information, integrate it into their environment, and extensions don’t require database upgrades or schema changes. If you need even more extensibility, it is available as open source.
5. ✔ We currently collect highly detailed data – far more detailed than old-school CMDBs.
6. ✔ Highly scalable. It is architected to scale into the 100K server range. We have designed a secure custom protocol to support this goal. A nice side-effect of making it scalable is that it is extremely light on the network and does not create any central-server network hot spots.
7. ✓We discover servers, services, switches, switch ports, configuration details, and IP and MAC addresses. We don’t yet do anything with containers.
8. ✔ Based on Neo4j – which supports relationships as first-class citizens.
9. ✔ Cannot set off security alarms. Agents perform all discovery locally.
10. ✔ Currently provide integrated monitoring, network management and security services. We have several open APIs which make integrating with other tools easy.
11. ✔ We use the schemaless Neo4j database.
12. ✓We work well across multiple sites, and have plans to work even better across multiple sites. The main criteria here is that the software should not put an undue burden on inter-site networking.

Assimilation CMDB Versus DevOps CMDB Secondary Characteristics

Below is how we stack up on the secondary characteristics:

1. ✔ Based on the Neo4j graph database.
2. ✔ We are based on lightweight agents which run in servers, and in many pieces of modern network gear. We wrote an earlier blog article explaining in more detail the benefits of agents. Having agents that run in both servers and network gear gives unprecedented level of detail of everything across the enterprise.
3. ✔ Our commercial CMDB code is also available as open source – which is the ultimate in openness.

Conclusion

Although my biases in evaluating the Assimilation Suite simply can’t be gotten rid of, I believe the previous article was a reasonable set of criteria, which quite a few people resonated with. Since these modern DevOps-aware critera went into the design of the Assimilation CMDB and its features, it is not surprising that it meets those characteristics well.