Patternal Conflict

No, this post isn't about parental difficulties and I didn't spell "paternal" wrong in the title, although I admit it is about problems with relationships. More specifically, the relationship between design patterns and pretty much everything else. And, based on previous experience of dabbling in this area, how I hate design patterns.

For more years than I care to remember I've been driven by situation to describe, document, present, and generally discuss software design patterns. Initially it was just patterns related directly to ASP.NET where common ones such as Factory, Singleton, MVP/MVC, and Publish/Subscribe were obvious - and generally built-in to the framework, or easy to implement. We could never agree on a structure for documenting patterns, never mind the actual defintion of the pattern. Or which implementions to show, and in what programming languages.

Then I got involved in Enterprise Library, and more design patterns surfaced in my world: Builder, Adapter, Decorator, and Lazy Initialization. All good solid patterns that are well documented and easy to use in Enterprise Library. I even write code samples to demonstrate how, together with some tenuously humorous descriptions that attempted to relate the guy who comes to paint your house with the way the Decorator pattern works. Needless to say, those documents never saw the light of day.

But now I'm back in the mire of design patterns again, paddling furiously to try and stay afloat at the same time as writing semi-comprehensible verbiage around patterns in Windows Azure. Some of which seem so vague and newly invented that you might think they were giving out prizes for finding new ones. I've reached the state of wondering what design patterns really are, and if many of the new examples I'm trying to document are just techniques, guidance, general advice for implementation, or made-up stuff that sounds like it might be useful.

According to most reputable resources, a software design pattern is "... a general reusable solution to a commonly occurring problem within a given context in software design" and "... a description or template for how to solve a problem, which can be used in many different situations." But then the definition typically continues with "... they are formalized best practices that guide a programmer on the implementation, not complete designs or solutions that can be transformed directly into code."

So is something that's Windows Azure specific, such as how you perform health verification checking for an application, a design pattern? Or is it just a technique? Or guidance? It certainly doesn't fit the idea of a generally reusable solution or template that can be used in many different situations - it's pretty specifically a technique for checking if an application is alive. But it is, I guess, formalized best practice and definitely not a complete design.

In fact there's nothing I can find on the web that seems to relate to "Health Verification Pattern". Or anything related around "probe" or "ping" that fits with the scenario. Yet it doesn't seem like something that somebody just made up for fun either. There's features in Windows Azure Traffic Manager and Windows Azure Management Services to do health verification, even if it is just a simple probe on a specified URL and port.

Of course, what's clever is that you can have the target of the probe do some internal checking of the operation and availability of the resources the application uses, and maybe some validation of the internal state, then decide whether to send back a "200 OK" or a "500 Internal Error" status code (or some other error code). Though you do need to do it in a timely way so that the probing service doesn't think you've gone away altogether, and flag your application as "failed."

For example, with Traffic Manager you get just ten seconds, including network latency while the request and response traverse the Internet, before it gets fed up waiting. So there's no point is doing things like checking a dozen database connections, or validating checksums of every order in your system, because you probably won't have time. And is there any point in sending back a detailed error message if something has gone wrong in the application? You'll need a custom client in this case to handle it. But surely the application will already contain instrumentation such as error handlers and performance counters that will flag up any failed connections or errant behavior within the code at runtime?

Maybe it really is similar to a paternal relationship after all. Whenever I probe our son to ask if he's OK, all I ever get back is "yeah, cool". The real-world equivalent of "200 OK" I suppose...