Those of you who’ve been following my blog for a while know something about the Assimilation System Management Suite – how it provides an always up-to-date CMDB, integrated monitoring, continuous security monitoring, and an up-to-date network map – in an incredibly scalable way with near-zero configuration – and how it does all this without setting of network security alarms.
If you haven’t given it a try yet, now is the perfect time – because we just announced version 1.1.0 of the Assimilation Suite, and to celebrate we’re offering a limited number of supported free trials.
I just got an email from Bernd Erk, saying that the 2015 Open Source Monitoring Conference is filling up. From my perspective, that’s a good thing, because we have a great talk and demo to give there and are excited to be speaking there again. From your perspective, this may be a good thing only if you hurry up and register – since this is the only conference we’ve spoken at outside the US this year.
The three pillars of IT security are confidentiality, integrity, and availability. Most of the press coverage is all about confidentiality – at least until we have an airline or two or three have trouble with availability ;-). Of course, availability is also a key dimension of server management with significant operational dimensions. Those of you who know me, know I have a deep expertise in availability. Unsurprisingly, in this post, I’m going to concentrate on availability – and the necessity of monitoring everything, and knowing that you’re monitoring everything.
Last weekend, I had the honor of giving the opening keynote on Friday at the 2015 Ohio LinuxFest and a session presentation on the Assimilation project the next day. Both talks were very well-received, but the reception the Assimilation project talk received from the standing-room audience was extraordinary. So it seems good to give a summary of the talk and why I think they resonated so strongly to it.
Over time I’ve had a number of people ask me why I wrote the Assimilation System Management Suite. I wrote this blog post to answer that question. Since I’m a techie at heart, this is a story told through a technical lens.
In a previous blog post, I outlined the characteristics of a CMDB for the DevOps era. In this post I give my somewhat-biased view of how well the Assimilation System Management Suite CMDB meets those needs.
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.
One of the key things that make DevOps deployments possible is more automation to make things more reliable. These tools include things like Jenkins, Ansible, Chef, Puppet, SaltStack, and even tools like Hubot, and concepts like Infrastructure as Code, Test Automation, and Test Driven Development, Continuous Integration, Continuous Delivery, and ChatOps. These tools have changed the face of system administration in the last decade. Unfortunately, security automation has lagged significantly behind the DevOps movement.
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.
In this article, we talk in more detail about the Assimilation Project’s reliable UDP protocol, our decision to avoid session keys, factors influencing our initial choice of crypto libraries, and touch on key revocation. So, like before we’re looking forward to your comments on our design choices. Like before, grab your thinking cap, sit down with your crypto buddies and think hard about what we’ve done.