> ...just the architectural diagram of how it works scares the shit out of me. When you need 7 arrow colours to describe where data is going in a monitoring system, I’m starting to fear it slightly.
This strikes me as a pretty lazy argument. Admittedly, that diagram is not the best. But that you can separate the components of Sensu isn't a bug, it's a feature. No one says you have to do it this way. In fact, you can exactly replicate the architecture of Nagios by having a single server. The point is you have choices, choices which are dependent not on the monitoring software (which is very lightweight by design in the case of Sensu), but on the other open source software it relies on (Redis, RMQ).
So I would argue that the "server instance" scope is way too broad a category to measure complexity. If you attempted to diagram the workflow Nagios uses (ignoring for a moment what server instance each component is on), you would come up with something equally bad (if not worse). That's if you even understood anything at all about how Nagios works to know what to diagram.
So let's replace one crude measure with another. The Sensu core repo is ~3MB total. Nagios core is about 10x that (30MB). NRPE is about 1MB all by itself. Mod_gearman (to pick out an add-on) comes in at a whopping 6MB. Suffice it to say, but for something that's basically a glorified exit code validator, this seems like a lot of complexity. Sure, Nagios has a lot of features that Sensu doesn't have, and that accounts for some of this. But there's a lot to be said for modular systems vs. monolithic ones.
Puppet definitely has its own pains, but I feel like I'd quickly reach a block trying to use this tool, and end up either writing more outside of Slaughter than in it or just forking it outright. I think these are the killer Puppet features for me:
* Ability to define resources and their dependencies declaratively
* Facter and its API, the ability to add custom facts that get deployed with my modules
* TLS encryption and certificate management for client communications
* Reporting/metrics for each run
* Exported resources
I agree entirely, as the author one of the goals was to be "serverless". That means there is no handling for TLS/certs - it is delegated to the transports.
(So you can get security by using SSL-protected git repository which allows the SSL to prevent MITM attacks, and git itself to avoid corruption.)
The metrics and exported things are almost certainly never going to get done, but having custom facts on a per-host basis is something that is minimally available right now, and will probably be expanded in the future.
The declarative notion is interesting but down that path lies madness - as an implementor - I don't want to go down the DSL route which makes procedural style definitions the simplest option.
This strikes me as a pretty lazy argument. Admittedly, that diagram is not the best. But that you can separate the components of Sensu isn't a bug, it's a feature. No one says you have to do it this way. In fact, you can exactly replicate the architecture of Nagios by having a single server. The point is you have choices, choices which are dependent not on the monitoring software (which is very lightweight by design in the case of Sensu), but on the other open source software it relies on (Redis, RMQ).
So I would argue that the "server instance" scope is way too broad a category to measure complexity. If you attempted to diagram the workflow Nagios uses (ignoring for a moment what server instance each component is on), you would come up with something equally bad (if not worse). That's if you even understood anything at all about how Nagios works to know what to diagram.
So let's replace one crude measure with another. The Sensu core repo is ~3MB total. Nagios core is about 10x that (30MB). NRPE is about 1MB all by itself. Mod_gearman (to pick out an add-on) comes in at a whopping 6MB. Suffice it to say, but for something that's basically a glorified exit code validator, this seems like a lot of complexity. Sure, Nagios has a lot of features that Sensu doesn't have, and that accounts for some of this. But there's a lot to be said for modular systems vs. monolithic ones.