Sidenote: If you’re curious what I’m actually working on, tune in to the ExchangeDefender Executive Podcast series. It’s me and my upper management talking about the projects we’re working on this day/week/month/year. Vladville articles are for the most part my general takes mixed in with some humor and other commercially inadequate concepts.
Before I explain what I’m up to allow me to put the whole consumerization concept into perspective. There is a reason big box manufacturers are struggling and that reason is often not discussed because it’s not commercially viable to a lot of people. It’s not just the cloud that is exterminating the dinosaurs of the IT age, or Apple alone for that matter. It’s not only Microsoft’s mismanagement and lack of focus, nor simply the workload shifting onto mobile devices at a more rapid pace. It’s that the design parameters have changed:
Over time every point of the server grade equipment became mission critical. It also became so expensive that the tollerance for failure in a single box almost vanished. At the same time, the old .NET development model (who cares about the bloat, just tell them they need more resources) got displaced by something else.
Instead of buying a monster server with monster storage and a monster Oracle or Microsoft database that was licensed per processor, folks started using open source databases and spreading stuff over multiple systems once we didn’t have to design a single point of failure for the sake of hardware and software pricing savings.
If all of this makes no sense at all you’re understanding this perfectly!
For example, a storage server used to be a very beefy high end server with high end storage controller, storage controller battery backup, high end server case with redundant power connections and high end drives. And while we’re spending all this money, whats a few hundred or even thousand more to get high end drives – we can never afford for this stuff to crash! But then boom, up in smoke it all goes and we end up looking like idiots. To an extent, we are, because there are different ways to design storage when you focus on replication and plan for failure instead of hoping that the redundancy will make the failure go unnoticed with fast failover.
When you look at companies like Amazon, RackSpace, Facebook and even some of Microsoft’s public designs, there is no high end hardware in sight. It’s all commodity gear all constantly replicating and completely disposable at any point in time. It’s not turnkey by any means though, design of the software – from access to storage to backups and replication – all has to fit and be designed to deal with less than 99.999% and deliver even better results than that: with spikes in demand to boot!
Designing Shockey Monkey RMM Backends
Note: The title is highly misleading; We’re not making anything nearly as sophisticated as Level Platforms or Kaseya because we business owners aren’t going to start writing scripts – but they are going to want to know when the hard drive is about to blow up.
In order for Shockey Monkey RMM to work and for our RMM partners to fit into the Shockey Monkey model perfectly we need to be capable of processing an insane amount of data. Which ain’t gonna happen because Shockey Monkey is free. Just because it can be monitored doesn’t mean it needs to be logged and reported, just because it can be logged and reported doesn’t mean it’s relevant to anyone and just because it might be relevant doesn’t mean it needs to be accessible quickly.
Moderm RDBMS (SQL stuff like Microsoft, Oracle, MySQL, etc) are designed with the old school servers in mind – fast, redundant and fat. All the data you wish to keep gets recorded and accessed at roughly the same speed and similar medium which can be related, indexed and cross-referenced as necessary. Except.. well, read the paragraph above – there is far too much useless crap which may under certain circumstances become mission critical.
How do you design for something like that? Even if you go cheap and use free software like MySQL you have a limitation of roughly 10,000 tables under ext3 and performance tends to drop off well before that.
Event Proxy – Event proxy is a simple load balanced application that will look at all the data that is being fed from an RMM. Some of that data is relational (devices, alerts) and some is junk (software updates, application notifications, error context/data). The job of the event proxy is to look at the kind of data it’s being sent to it over the network and dump it to the correct data storage medium – some nodb, some mysql, some into plain text files. Yeah, we’re partying like it’s 1999.
Report Proxy – The reverse of the above. Once someone asks for relevant vs. junk data reassemble it back together.
Reverse Configuration – If you look at the RMM agents they tend to be pretty dumb and lightweight, most of the data intelligence and manipulation happens on the server. In order to make something free we’ll have to turn the tables on this. First, the agent will have to become a lot smarter in terms of interpreting the rules of what needs to be saved on the server and what could be saved on the client itself. By contrast, servers need to get better at tracking their agents and start pulling some data instead of just waiting for it. After all, the agents aren’t dumb by accident, you can’t make them be the biggest resource hog on the workstation, they need to stay lean.
What about the consumer?
Most people misunderstand the concept of consumerization.
It’s not about something being free, that’s a marketing gimmick.
It’s not about something being basic, that’s why there are so many apps that nobody ever downloads.
It’s all about what the consumer wants: Which is simplicity.
If the user has to think, follow directions and steps, calculate tradeoffs or consider alternatives.. all you’re doing is giving them reasons not to use your app.
This overcrowded, overpriced and overcomplicated industry can survive and thrive.
But in order to do so it must build the bridge between the users expectations (free and simple) and business demands (redundant and accountable).
Obviously, we’ve built Shockey Monkey to be that bridge. And it’s working.
For the less coherent, more grammatically correct realtime insight, follow me on Twitter at