Maven deals with dependencies related to application builds. If I understand the article correctly, the author is suggesting a way of sanely managing dependencies related to deployment configurations. This might include subgraphs that represent the application builds on several nodes, but would also reference configuration files from app servers, web servers, etc.
A first step might be to simply visualize the relationships in question. I have used GraphViz (http://graphviz.org/) to this end for a number of situations (internal corporate projects).
I think the challenge is that the relationships (edges) of the graph do not all necessarily represent the same types of dependencies. Some would result in compile time errors, some run time errors, some would cripple a system, and some have little practical effect. I do like the idea of a simple declarative system representing a dependencies between components as a graph though.
This is actually an active area of research in the theory of computation, and computational semantics. Researchers have been hard at work trying to formulate an algebra of ubiquitous computation that can encapsulate the spatial and temporal arrangement of mobile processes (which in this case includes computer processes, physical processes, chemical processes, etc). Graphs (or variants) are the structure that is being used to model these systems. Processes are nodes (or sets of nodes) with an algebraic structure that permits composition and formal reasoning.
For an easy-ish overview, check out: -- edit -- this was the wrong set of slides... These are dense.
Its something that we're thinking a lot about at Verelo.com
I've personally been very big on trend graphs myself, how are we doing today v's yesterday, this week v's last week. I find you learn a lot more from these than you do any other type of monitoring (unless the issue is dead simple, like something is down)
We've been focused right now on making great monitoring systems, however we're just starting to get the chance to step into prevention. Prevention is a fun area because it starts to include trending.
My hope is that within the next month or two we have a few things. Firstly a means of providing a great downtime prevention tool, but also an end point where data can be sent (or we can pull it on your schedule) and then provide a graph and notifications based on changes in the trending data. Think of it like stock alerts...
So yep...i agree with you, we need graphing and more of it.
The article isn't about graphs-as-in-charts, but graphs as in the mathematical concept. In this case, expressing dependencies between different pieces of operational infrastructure, such that changes to one piece of infrastructure trigger automatic changes to other pieces.
Unfortunately, the author is pretty vague about exactly what pieces of infrastructure they imagine defining relationships between, and what triggers they might use. On the smaller side, they mention 'I changed a config, I must restart nginx' (micro level dependency between nginx and its config) and 'something changed in my app tier, need to tell my load balancer' (macro-level dependency between a service and its front-end). What kind of dependencies would be useful to define between services in a service oriented architecture, which are usually designed so as to minimize dependencies?
as stated in a comment on the original blog, work on things like these are done using rules engines ( based off rete algorithm http://en.wikipedia.org/wiki/Rete_algorithm )
This article was more about DAG than shiny 'how are our servers' graphs. Sounds a lot like you just posted to a story acting like you read it so you could advertise, than that you are contributing to this topic :-\
A first step might be to simply visualize the relationships in question. I have used GraphViz (http://graphviz.org/) to this end for a number of situations (internal corporate projects).
I think the challenge is that the relationships (edges) of the graph do not all necessarily represent the same types of dependencies. Some would result in compile time errors, some run time errors, some would cripple a system, and some have little practical effect. I do like the idea of a simple declarative system representing a dependencies between components as a graph though.