The #monitoringsucks meme appears to be a response to outdated systems that, according to Jason Dixon, DevOps engineer at Heroku:
…do a lot of #@?!, sometimes poorly. And almost always, in a disjointed manner, caused by years of feature creep and parity. Too many moving parts, layers upon layers of antiquated code (and bugs), and an inflexibility towards newer engineering methodologies (e.g. infrastructure as code, aka operational automation).
In a conversation I had with her late last year, Molly Stamos, director of product management at Boundary, concurred that current monitoring tools don’t meet the needs of the DevOps style and environment, where developers are inclined to write applications to solve whatever problems they may have:
These operations folks have development skills, and they can write applications [and] know how to set up a scaleable infrastructure. As a result, what happens oftentimes is you get a “not invented here” complex. If the solution doesn’t exactly match what they’re looking for, they think, “I’ll just build it myself!”
This mentality is a big change from the way “typical greybeard operations folks” tended to “look for a solution that solves their problems before they think about building it,” Stamos said.
But what happens if your developers don’t have the old-school ops experience?
According to Stamos:
These people often overlook more fundamental issues with operations when they build these solutions. They haven’t looked at operational things they need to implement. And that actually further drives and fuels the DevOps movement. Now we really do need those operations people to come in and write the operational frameworks around these bleeding-edge technologies to give you the stablity, monitoring and management insights you need.
Stamos calls this mindset the “Dark Side” of DevOps because this mindset goes against what DevOps is about, which is ultimately solving business problems rather than technology ones:
Writing the tools themselves is a significant investment of time, and you think about how much of that [investment] is contributing to the bottom line of the business.
In other words, does it make sense to spend so many resources, both in developing and managing home-grown monitoring apps that can only be used in that specific environment?
Granted, Stamos represents a company that is building solutions that hope to make #monitoringsucks a thing of the past. But that shouldn’t disqualify her thoughts, as Brandon Burton points out in his response to a GigaOM story written by Boundary co-founder Cliff Moon back in February:
…the idea that just because someone is trying to make money in something, automatically discredits them due to bias or whatever, is crap, especially in this case, where if you spend even 15 minutes see what #monitoringsucks is about, you'll see it's from the community. Quite frankly, I think a lot of the resistance things like #monitoringsucks or DevOps get from certain people is just those people trying to push their own brand by being a thought leader, but that's a topic for another post.
