A question I get asked fairly often is “How is the Assimilation Suite different from orchestration tools like Chef, Puppet, Ansible, or SaltStack?” The short answer is that we complement them. This article explains how we do this in some detail.
CMDBs have a bad reputation in many circles. They are seen as expensive, have been associated with costly IT failures, high overhead clumsy processes, are reviled by some, and are thought to be incompatible with DevOps. In my opinion, they don’t have to be that way. The idea of a database that knows everything about your IT environment, replaces manual documentation and springboards automation is incredibly attractive. What would a CMDB look like that is easy to install, and easier to maintain – one that followed the DevOps mantra of automating everything? This post explores that question.
Although this article and title are a bit tongue-in-cheek, the reality behind the title is serious. In the average data center, 30% of their servers are mainly space heaters [they had their brains eaten ;-)]. Given that many data centers are strictly limited on power, cooling and floor space, and that power and maintenance are significant costs, this is a big deal. This happens primarily because the staff managing those servers have don’t have a clear idea of what all their servers are doing.
We fill our lives with things designed to make them easier… In many cases, these things we get to make our lives easier wind up making it more complex. Nowhere is this more apparent than in IT. We have so many choices of ways to create services, to deploy them, and to manage them. I’ve been extensively involved with high-availability work since 1998. One of my mantras in high-availability is “Complexity is the Enemy of Reliability” – and so it is. If you add parts to a thing, more things will fail – period. In high-availability, we add high-availability software – which makes it more complex, and hence less reliable. But we get something back instead – improved availability.
