When is it too early to think about monitoring?

In a word, “NEVER.”

I’ve heard people say that they are super busy with production deployments and fast-moving projects. They haven’t had much time to think about a performance monitoring strategy for their new applications.

But waiting until your applications are already in production is a mistake. However, it’s one that you can avoid.

Develop, test and deploy your applications with monitoring already in place and save yourself a lot of headaches. Let me count the ways:

1. Using the same monitoring tools for both pre- and post-production

Obviously, you will be doing performance testing during development and QA. But if you use different tools before and after, you might get inconsistent results. And you’ll have to retrain the people that did the original testing on the new performance monitoring tools. After they’ve moved on to other projects.

Having a monitoring strategy in place ensures that people are using the same tools throughout the lifecycle. .So that you can expect consistent measurements and more efficient troubleshooting and response if necessary.

2. Monitoring – independent from administration – eases access and alleviates concerns

Many developers need access to performance metrics during testing and often that means providing administrative access to middleware platforms to get those metrics.

When you’ve implemented an independent monitoring solution then developers can self-service their performance monitoring needs without worrying about providing administrative access.

3. Monitoring best practices implemented at design-time means less effort at run-time

Correlation of metrics between related technologies is what allows you to see things in context. For instance, show me all the servers that support a particular application. That's significantly easier than wading through 1000’s of servers trying to figure out which ones support my “banking” application. This is especially helpful when time is of the essence. But how does your monitoring system know which instances are related?

Well, you could map it manually, often using naming conventions for your services and engines. The better you stick to well-defined naming conventions, the easier it is. This is another reason why including monitoring requirements in your application building process will pay dividends down the road. Because “automatically” is so much easier than “manually”.

4. Capacity Planning is easier if you’ve been collecting performance data all along

If your business is successful, your apps will get busier and you’ll need to ask yourself if you have enough capacity for future growth? Of course, it’s hard to answer that question if you have no baseline data.

However, capturing performance data from the start enables you to see the resource usage trends over time. Correlate that to expected traffic growth for your application and you'll be on stable ground as you analyze your resource requirements for the next 6-12 months.

5. You don’t have to worry about running out of steam

For a lot of companies, once an application is written, people celebrate and move on. Things that you promise you’ll get to later – never seem to be a priority anymore. Unless, of course, you are hit with a severity one outage and then all heck breaks loose. Then people start panicking because there is no visibility into what is breaking down and where.

Building monitoring requirements into the application development cycle ensure that these things are not forgotten in the hustle and bustle of the next project. In fact, some of our customers will not sign off on a project unless monitoring is ready to go BEFORE moving into production. They make it a priority from the start so that they don’t have to struggle for resources AFTER everybody thinks they are done and move on to something else.

So, the next time somebody asks you about your monitoring strategy for your new apps, instead of saying “I’m too busy to think about it right now,” you should say, “I’m way ahead of you”.

David Hickman is in Product Marketing at SL Corporation.