DevOps is like Building Sand Castles
November 5, 2020 / 4 minute read
Share this:
How can less-technical people understand what DevOps (short for Development Operations) people do? Welcome to my childish attempt to explain.
The Analogy
Doing DevOps work is like building sand castles!
First, I'm not a real DevOps person, but bear with me. When you build sand castles at the beach, you are aiming to:
- build something architecturally sound
- build it on a decently realistic timeline (or else the tides will eat it for lunch)
- build something that is close to destructive forces (waves). Or for extra points, involves them (i.e. fill an epic moat)
- do something productive (after all, you could just lie down in the sun instead)
- defend yourself from an imaginary invader
DevOps is similar to these things! Of course, the primary component in DevOps is enabling others (Developers) and making their work more productive. That part of the job is more like holding a ladder (more on that another day). I am concerned here with mostly what a DevOps person does or builds.
The High Points
- DevOps involves building and maintaining digital architecture (i.e. sand castles). Whether using virtual machines, containers, or "infrastructure-as-code", the end goal is a castle.
- DevOps engineers often work hard and work quickly, as their work is in high demand by the teams that depend on them. Timeliness is important
- Although a system without any users would be easier to maintain, the destructive force that is "users" will assault the DevOps engineers' well-architected fortress.
- Not any sand castle will do. DevOps engineers often care about building things correctly. Like mathematicians, they also do not want to do the same thing over and over again ("toil").
- Often times DevOps engineers are concerned about actual invaders... but to prepare, they will load test their architecture with imaginary invaders (to be sure it will work) or get their coworkers to test it out.
Some of these connections are very helpful. For instance, a load test becomes "simultaneously building a sand-castle and trying to throw waves at it, to make sure it is strong." Or deploying an update to a cluster is "automatically reconfiguring 40 sand-castles and hoping all of them keep standing." Perhaps in a moment of deep thought, "I can't figure out why my sand-castles keep crashing. The waves aren't even that big today, and they did just fine yesterday."
A Docker container is a sand castle, let's say, and a docker image is a template that allows me to build new sand castles super fast when I need them! The explanatory power is wonderful!
The Breakdown
The most dangerous thing about this analogy is that it is quaint and accessible, and could therefore easily be used to over-simplify or demean the work of DevOps engineers. However, these engineers are building incredibly intricate architectures that run some of the most lucrative businesses on the face of the planet. It is work that should not be taken lightly! Just because sand-castles rarely have a lucrative or serious purpose does not mean that DevOps work shares that trait.
A related breakdown: the imaginative childishness of sandcastles coupled with "digital" architecture that cannot be objectively seen can lead down a similar path suggesting that DevOps work is not productive. It is worth remembering that these engineers are actively building, maintaining, and improving the foundation that the entirety of most technology careers are standing upon. The twenty-first century would not look the same without these contributors!
As such, I think this analogy is most productive when an engineer describes their own work this way. An observer proposing the analogy could come across as demeaning.
Perhaps a better way to think of it as an external observer:
Wow. This person is building and maintaining multi-dimensional real castles
in another universe that I cannot see with my eyes, or even understand, but which I am dependent on for my twenty-first century lifestyle. Thank you
Closing
I have tremendous respect for the Operations team that I work with. They do amazing work and really keep the rest of the teams rolling smoothly! As someone who occasionally dabbles in their area of expertise, I have seen that it can be hard to explain the topic to others. This is my feeble attempt at explaining the idea to those outside the field.
I have to say, it has been a recurring analogy in discussions with my wife, who does an amazing job being interested in my digital playground. If you need me, I'll be building sandcastles with the kiddos.