DaedTech

Stories about Software

By

Software Monitoring: The Things that Might Interest You

Editorial note: I originally wrote this post for the Monitis blog.  You can check out the original here, at their site.  While you’re there, have a look at the different sorts of production concerns that you can keep an eye on with their offering, some of which I address in this post.

If you have responsibility for software in production, I bet you’d like to know more about it.  I don’t mean that you’d like an extra peek into the bowels of the source code or to understand its philosophical place in the universe.  Rather, I bet you’d like to know more about how it behaves in the wild.

After all, from this opaque vantage point comes the overwhelming majority of maddening defects.  “But it doesn’t do that in our environment,” you cry.  “How can we even begin to track down a user report of, ‘sometimes that button doesn’t work right?'”

To combat this situation we have, since programmer time immemorial, turned to the log file.  In that file, we find answers.  Except, we find them the way an archaeologist finds answers about ancient civilizations.  We assemble cryptic, incomplete fragments and try to use them to deduce what happened long after the fact.  Better than nothing, but not great.

Because of the incompleteness and the lag, we seek other solutions.  With the rise in sophistication of tooling and the growth of the DevOps movement, we close the timing gap via monitoring.  Rather than wait for a user to report an error and asking for a log file, we get out in front of the matter.  When something flies off the rails, our monitoring tools quickly alert us, and we begin triage immediately.

Common Monitoring Use Cases

Later in this post, I will get imaginative.  In writing this, I intend to expose you to some less common monitoring ideas that you might at least contemplate, if not outright implement.  But for now, let’s consider some relative blue chip monitoring scenarios.  These will transcend even the basic nature of the application and apply equally well to web, mobile, or desktop apps.

Monitis offers a huge variety of monitoring services, as the name implies.  You can get your bearings about the full offering here.  This means that if you want to do it, you can probably find an offering of theirs to do it, unless you’re really out there.  Then you might want to supplement their offering with some customized functionality for your own situation.

But let’s say you’d just signed up for the service and wanted to test drive it.  I can think of nothing simpler than “is this thing on?”  Wherever it runs, you’d love some information about whether it runs when it should.  On top of that, you’d probably also like to know whether it dies unexpectedly and ignobly.  When your app crashes embarrassingly, you want to know about it.

Once you’ve buttoned up the real basics, you might start to monitor for somewhat more nuanced situations.  Does your code gobble up too many hardware resources, causing poor experience or added expense?  Does it interact with services or databases that fail or go offline?  In short, does your application wobble into sub-optimal states?

But what if we look beyond those basics?  Let’s explore some things you may never have contemplated monitoring about your software.

Read More

By

What DevOps Means for Static Analysis

Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  While you’re there, have a look at NDepend’s static analysis offering.

For most of my career, software development has, in a very specific way, resembled mailing a letter.  You write the thing, and then you go through the standard mail piece rigmarole.  This involves putting it into an envelope, addressing the envelope, putting a stamp on, it and then walking it over to the mailbox.  From there, you stuff it into the mailbox.

At this point, you might as well have dropped the thing into some kind of rip in space-time for all you understand what comes next.  Off it goes into the ether, and you hope that it arrives at its destination through some kind of logistical magic.  So it has generally gone with software.

We design it, architect, and lovingly write it.  We package it up, test it, correct defects in it, and then we call it done.  From there, we fire it into the mailbox-black-hole of the software world: operations.  They take it and deploy it, or whatever, and then, by some magic we don’t concern ourselves about, it runs in the real world.  Or so it has generally gone.

Problems with the Traditional Approach

With the benefit of hindsight, you can probably guess the main problem with this state of affairs.  So rather than enumerate it dryly in a series of bullet points, let me offer it up in story format.

You work as an application developer in some very large enterprise.  There, you build web apps.  And you take pride in your work.  You write clean code, you maintain the unit test suite, you collaborate dutifully with QA, and you generally do your best.

In fact, this effort even extends beyond your own dev environment and into as many environment as you can see.  You run load, smoke, and integration tests in QA and sandbox environment.  And, as a whole unit, your team does everything it can to ensure the integrity of the work.  But beyond the pre-prod environment, the fate of your application becomes an utter mystery.  Some group of folks located in a different timezone take it from there.  You wish it well as it heads to production.

And then, one day, six months later, you get some incident report.  Apparently, some guy in Hungary or somewhere was doing something when somehow he get a null reference exception.  But don’t worry, here’s a brief description of what he said and a few thousand lines of some random log file.  Good luck with your repro!

Read More

By

How to Write Code that Operations Will Like

Editorial Note: I originally wrote this post for the Monitis blog.  You can check out the original here, at their site.  While you’re there, take a look around at the options you have for monitoring your production site and all of its supporting infrastructure.

In recent years, the DevOps movement has gained a significant amount of steam.  Historically, organizations approached software creation and maintenance in the same way that they might with physical, mechanical process such as manufacturing.  This meant carving the work into discrete components and then asking people to specialize in those components.

If you picture a factory floor, it becomes easy to picture.  One person screws two components together over and over, while another person operates a drill press over and over.  When you specialize this way, the entire process gains in efficiency.  At least, so it goes with mechanical processes.

With knowledge work, we haven’t realized the same kind of benefit.  In retrospect, this makes sense.  It makes sense because, unlike mechanical work, knowledge work involves little true repeatability.  It continually presents us with problems that differ at least somewhat.

As we’ve come to recognize that fact, we’ve begun to blend concerns together.  Scrum teams blur the lines among QA, developers, and business analysts.  And DevOps does the same with initial development and production operation of software.  If you can, I wholeheartedly encourage you to embrace DevOps and to blend these concerns.  Your entire work product will improve.

Unfortunately, not every shop can do this — at least not immediately.  Progress goes slowly in these places because of regulatory and compliance concerns or perhaps because change can come slowly in the enterprise.  But that shouldn’t stop you from making strides.

Even if development and operations remain separate, they can at least communicate and help each other.  Today, I’d like to talk about how developers can write code that makes life easier for ops folks.

Read More