Pets, Cattle, Ants and a Lone Wolf

Pets, Cattle, Ants

Pets vs cattle as an analogy to manage IT assets and cloud infrastructure is a decade old.  Even before this observation became commonplace, this is something that I’d seen first-hand.  When I came into the IT industry, I was often supporting assets named after Knights of the Round Table, Lord of the Rings or Star Wars. Over the past two decades that’s changed to devices named after site locations and functions to devices that are ephemeral and named and tagged with serials and references.

For those unfamiliar with the analogy, it roughly is as follows.  Is the estate looked after as you would a beloved family pet, do individual servers and devices have a pet name, when they break are they nursed back to health? Are services supported by the pet down until it is nursed back to health. Or is infrastructure managed like a heard of animals, are they given a serial number, tagged and when they break are they put down and replaced?  The herd continues to support services as designed.

The analogy can also be pushed further to include Ants, especially when we think about Kubernetes, containers, pods and how they operate in a deployment.  Deployment in that context being the definition of a pod’s desired behaviour or characteristics.  If pets require intervention and to be nursed back to health and if cattle are resilient and replaceable, then what are ants?  Ants are both resilient and the colony is self-healing based on the desired state of the deployment.

Pets, Cattle, Ants and a Lone Wolf

So why the title?  Why the Lone Wolf?

What’s a lone wolf in this context?  If pets require intervention to be nursed back to health, cattle are resilient and replaceable, and ants are both resilient and the colony is self-healing based on the desired state of the deployment.  Then the lone wolf requires intervention to be nursed back to health by a specialist who was there at its birth. Services might be designed as resilient and even self-healing, but only the specialists that built them fully understand how to maintain that. A lone wolf is effectively a way of framing a specialist pet, maybe a bearded dragon or a chinchilla rather than a cat or a dog.

Agile teams are empowered to define, build, test, and deliver an increment of value in a short time box or sprint, of say a two-week duration.  That increment of value includes a defined scope that could cover building solutions and services, fixing problems and infrastructure platforms incrementally.  This agility is great when pivoting to meet the requirements, demands and scope changes.  When it comes to the platform elements there is an intended focus on the problem at hand, usability, maintenance, and sustainability.

However, how does that align with items being delivered in a different sprint, project, or line of business.  How do these platform iterations relate to the overall supportability in the context of the entire infrastructure platform, and is that a problem? What drives consistency in toolchain selection in the confines of a two-week sprint cycle?

I’m hearing more cases of teams delivering what we could define as lone wolf applications, that are effectively time boxed out of being able to select consistent platforms.  What might take precedence? Working through a procurement process to gain a quote and purchase an extension to licensing for the solution in use across the whole estate or even proposing a new solution for the whole estate, or jumping directly to building and value delivery based on an open-source tool chain, public repositories, GitHub and Stack Overflow? As agile teams try to develop faster, they are sometimes forced to ‘go it alone’ to make use of technologies which they need in a timescale that delivery demands.

So, is there a ‘right’ way to do this? It’s natural and healthy to have diverse environment but extending the metaphor the trick is not to create an invasive species that chokes creativity.  IT estates will perhaps contain all the above and the trick is managing things correctly and creating a healthy mix, too many pets or lone wolves and perhaps creative energy is being redirected to operational tasks. You can and perhaps should have a few lone wolf applications, that are being used to strategically push boundaries and the art of the possible.  However, the art of the possible needs to have a path to return to the pack.

Lone Wolf to Wolfpack

Providing a return path to the pack, perhaps unfashionably starts by building a platform that brings together a collection of tools and resources to manage, observe, and automate. Enabling flexibility and ease of access whilst providing key elements like governance, metrics, tracing, observability, operations, auditing, automation and security for multiple run-time infrastructures.  The platform that is created will depend on the scope and scale of modernisation works in an organisation, if an organisation is only touching one or two applications then the benefit to building a wolfpack platform is probably minimal.  If, however, an organisation is seeking to or is already modernising on an industrial scale then there should be a bias for building this core wolfpack platform.

What is being provided then, is an infrastructure that can manage highly customised lone wolf applications that might have a requirement for specific resources and metrics together with customised off the shelf and third party developed applications and services.

What that breakpoint looks like in terms of pure cost savings will vary dependant on several factors ranging from staff to procurement costs. However, there will be a point where an organisation with a mature application modernisation programme that didn’t build a wolfpack platform, may run into a few problems, not only just pure costs of supporting lone wolves but also through the opportunity cost of diverting creative talent to operational activities.

Summary

The innovation and efforts made by teams that are building lone wolf applications, push the boundaries of what is possible and provide huge benefits to organisations.  However, if every application evolves into a lone wolf, then the innovation benefits are lost as energy is diverted from innovation and creativity to the operational and mundane.  An upfront assessment and honest evaluation of the goals and benefits of digital and application transformation within an organisation, that define if the aim is an industrial scale modernisation or focused development of critical growth assets, will help that organisation understand the need and scope of a wolfpack platform.  Once understood the value to an organisation should be evident and any such platform will pay for itself many times over.

Thanks to Dean Lewis and Stephen Midgley for their contributions and open discussion on this topic.

Hopefully this is useful and interesting to some.

Simon