Cloud Computing and Plato

My college philosophy is admittedly very rusty, but I was talking to a colleague recently and explaining why I'm doing and planning to do more of a particular in the AWS environment for Ekho that introduces instability on purpose. I was inspired in part of course by what Netflix did ages ago with Chaos Monkey.

 Soon, the conversation strayed to configuration management. Systems automation tools like Chef, Puppet, and AWS Cloud Formation, and others allow you to express infrastructure as code. This is critical to a complex systems survival in an inherently unstable environment (like most data centers). Things in a cloud native deployment environment are always changing. How to you keep up or get a handle on it all? How do you even reason about this when you try to explain it to people? This is where Plato came into play. I wanted a non-technical analogy.

In college I studied some Philosophy. But, only enough to be dangerous at parties where the beer flowed freely and pontification abounded more-so.  However, one particular set of lessons from my studies about Plato in a class on Gnosis at Bellarmin University has stuck with me over the years. That was Plato's Theory of Forms. From Wikipedia today, the theory states: 

Platos's theory of Forms or theory of Ideas asserts that non-material abstract (but) forms (or ideas), and not the material world of change, possess the highest and most fundamental kind of reality.

Source : https://en.wikipedia.org/wiki/Theory_of_Forms

It turns out, this applies very much to my thinking about how cloud infrastructure is instantiated using tools like Chef and Puppet. The code part of infrastructure as code is the abstract form as a representation of the idea of what could be. The deployment itself once instantiated is just a copy. Or, in the terms of Plato, the material. It is the form itself that possesses the most fundamental reality. Or, in this case is the configuration of record.

If you use tools like Chef to design, manage, build, and maintain your infrastructure the perhaps you are espousing philosophy daily. What you instantiate on a cloud like AWS is certainly by its very nature, ephemeral. Yes, even if you use EBS volumes. Eventally, it'll all go away or be replaced by the next revision leaving nothing but the code it was spawned from. But then... eventually, that will fade away as well. This is the part where beer is needed because you then wonder what happens with the idea that spawned the code that spawned the server is forgotten by the original person. We'll probably need some heavy duty graph analysis to go from there to all the possible permutations.