I have heard the term swimlane used in the context of group of servers. It can be a rack that houses all the parts of a particular application. Everything from database to load balances. Or maybe for a particular client.
Is this an industry standard term? Any ideas on the origin of the term? Do others use it as well?
Well google found it:
Swim Lanes AKF uses the term “swim lane” to describe a failure domain or fault isolation architecture. A failure domain is a group of services within a boundary such that any failure within that boundary is contained and failures do not propagate outside. The benefit of such a failure domain is two-fold:
Fault Detection: Given a granular enough approach, the component of availability associated with the time to identify the failure is significantly reduced. This is because all effort to find the root cause or failed component is isolated to the section of the product or platform associated with the failure domain. Fault Isolation: As stated previously, the failure does not propagate or cause a deterioration of other services within the platform. As such, and depending upon approach only a portion of users or a portion of functionality of the product is affected.
Between swim lanes synchronous calls are absolutely forbidden because any synchronous call between failure domains, even with appropriate timeout and detection mechanisms, is very likely to cause a cascading series of failures. An example of how this happens is in your database when one long running query slows down all the other queries competing for locks or resources.
AFK Partners | Defining Pids, Shards and Swim Lanes http://akfpartners.com/techblog/2010/10/26/defining-pods-shards-and-swim-lanes/
Just like TheCleaner, neither I have heard the term used like this. Nevertheless I'll venture a guess on how a bunch of hardware belonging to a single application may have come to be called 'a Swimlane'. This "answer" is of course all pure guesswork, right into the unknown blue and nothing else.
I have sen the Swimlane term used on KanBan boards to depict the task lifecycle, as a task flows through different states such as {"planning","in progress","waiting","on hold","done"}. Here is a short description of an incorrect use of Swimlanes which I find to be a quite effective way of understanding what they are.
As Agile becomes more pervasive and Devops exploration takes firmer foothold (in some places), a challenge for Operations teams is how to relate and adapt to Agile methods and terminology. The challenge lies in that these have been worked out to describe development practices but not, for instance, IT Operations lifecycle management or routine maintenance procedures. Like many others, I have been subjected to this challenge too.
Whilst I am perfectly willing to see the benefits of Agile methods when intelligently pursued, even to the point of encouraging adoption, fact remains that Agile terminology and methodology does not lend themselves especially well to for example routine maintenance tasks. Method conversion and terminology is an ongoing challenge as far as I am concerned. With Operations projects or troubleshooting it is easier, in general I find those Ops missions to be closer to what Devs do. Easiest I find it to be when one is an Operations part of a Devs team during a project, where these issues largely and naturally cease to exist.
So my guess is that a bunch of Ops people have been subjected to a KanBan board or KanBan practices requirement and somehow come to the conclusion that the KanBan board Swimlane term, intended for following the progress of relatively small tasks or groups of tasks, could also be used for the macrotask of infrastructure lifecycle management.
If this guess in fact should hold true, I wish to be respectfully clear with not at all having an opinion as to of how this circumstance came to be. Perhaps it was:
I have no idea if I'm even close, but it was fun to explore this thought.
