When I wrote the four-step prescription for an Intelligent Data Center, the first step, the most important step, was “applications first.”
Applications are what makes your company money.
A surprisingly big challenge to an “applications first” mentality is the “DevOps in AWS” culture. I know, DevOps is a great way to bring out new applications fast. But that’s only the most basic element of “applications first.” As everyone in IT operations knows, applications are forever. Or at least it seems that way. And long after the flush of excitement of a new application wears off, IT operations has to keep it running.
And so we need to integrate those DevOps-in-AWS applications into our IT processes. We need to detect faults, build performance baselines, alert on problems, create tickets, incorporate changes, track usage. How?
Many organizations have tried, over and over again, to force application development teams to think about monitoring while building their applications. Command and control has failed for years and is much of what gave ITIL a bad name. Adding requirements just slowed everybody down. Is there a better way?
Yes, there is a better way. And I’ve seen it work in some very different environments.
Give DevOps Teams Something for Nothing
Make it drop-dead simple for development teams to build monitoring into their applications. Give them the tools to publish their data and look at how their applications are running.
I watched it work at Microsoft after they acquired Operations Manager from NetIQ, and all Microsoft apps could suddenly have monitoring just by publishing performance counters and using message DLLs. Within a few years, every Microsoft server app used the same standards. Zenoss and other software companies now find it quite easy to help Microsoft customers.
In May at our GalaxZ customer conference, Shani Mashhood shared how BBC implemented a solution. BBC runs one of the largest media websites in the world, hosting events like the Olympics, Wimbledon, and the World Cup. Over half of the applications supporting the website run on Amazon servers, and they’re all custom applications. As head of monitoring, Ms. Mashhood realized that her operations team needed help from the developers.
“The best way to get buy-in was to provide something for free,” Ms. Mashhood explained. “It didn’t make sense for every single product group to reinvent the wheel. So we created a ZenPack for monitoring applications.”
The ZenPack was designed so that developers could write data in a simple format, create thresholds against metrics, and quickly define graphs. This gave the developers a self-service tool that provided value during development as well as to operations afterwards. “They decided how many metrics, on what servers, on what applications, how they want,” said Ms. Mashhood. “It was a really big win.”
Developers got the data they wanted, but they needed more.
What is the Frequency, Kenneth? Faster, Faster!
The other part of engaging application developers is to give them useful data. They’ve defined the data, sure, but they want it more frequently. The five-minute collection intervals we’ve all used for years just aren’t enough for a DevOps team to see what’s going on in the application.
Set the default collection interval to 30 seconds as a first step. For a second step, kick down the interval to one second during problem times. That extra data will give developers the ability to really understand what’s happening in their application.
That’s actually one of the new features in Zenoss Version 5. You can more easily set different standard collection intervals for different devices and applications and adjust the intervals dynamically.
Chet Luther, one of our senior developers, has shared a change-datasource-interval script on GitHub to make this easy. Call it from the standard trigger-and-notification system as shown here:
Flexibility is a Zenoss Strength – Apply it for Applications First
At GalaxZ, from our customer advisory board and from individual customers, we’ve heard the message that a core strength of the Zenoss product is flexibility. When we ask “Why?” it always comes back to the ability to adapt the product to meet individual needs.
That flexibility can be a key tool for you as you think applications first. I’ve shown you two ways to use the flexibility in this article - supporting custom application development and providing data to developers on a variable frequency.
If you’ve got questions or comments, tweet to @Zenoss!
