With the continuing rise of "infrastructure as code", we are automating services to operate at large scale. While there are clear benefits to business and commerce for doing so, I believe there is a much larger reason for continuing to push for systems automation. This talk is about that secret - nay, the necessary! - ingredient for making systems automation successful.
12. Organizations which design systems ... are
constrained to produce designs which are
copies of the communication structures of
these organizations.
-MELVIN CONWAY
Source: http://bit.ly/1ujIDLK
15. The true essence of DevOps is empathy.
Empathy allows software makers and
operators to help each other deliver the best
possible functionality+operability on behalf of
their customers.
- JEF F SUSSNA
Source: http://bit.ly/19p4Yy1
23. The goal of automating a system is to
enhance safety, contentment, knowledge,
and freedom of both the authors and the
users of the system.
- ADAM JACOB
24. Read Rands in Repose! Source: http://violasong.com/portfolio/
How many people are familiar with this saying? It is now part of the system administrator’s tome alongside “sudo make me a sandwich” and “pimply faced youth”. (BTW, if you don’t know that last one you don’t know your lore. Look it up.) This oldie-but-goodie has been repeated by sysadmins for years. Granted, it’s often delivered with a certain amount of snark, usually targeting someone from accounting or HR. But at its core is systems automation.
As SysAdmins, we’ve been doing automation a long time. Another often heard mantra goes something along the lines of “if I have to do it more than once, it’s going into a script”. And if you’re paying close attention, you’ll realize I’ve already told you about the secret ingredient to automating systems.
Consider this example of an old bash script which automates the backup process of a MySQL database. It’s fairly straightforward in how it gets the job done. More or less, it follows the steps similar to those a DBA or SysAdmin would take if they were to make a manual backup. The creation of this script meant a DBA or SysAdmin no longer had to manually execute the steps necessary to create a backup of their database. No more middle-of-the-night manual executions or taking the database down in the middle of the day interrupting users. This could be scheduled to run and became a trusted tool. Now, instead of spending time thinking about backup itself, the DBAs and SysAdmins could turn their attention to other parts of the system that required their attention.
In this particular example, they may want to be spending time thinking about the inclusion of a user password in their backup script and whether that’s a good idea or not. (Hint: it’s not a good idea.)
As the number of servers we’ve been asked to build and maintain has increased with time, our tools have advanced. We rely on tools such as Chef, Puppet, or CFengine to help us scale beyond those bash scripts that use to be so helpful to us.
Here’s a view of that same backup process, this time in the form of a Chef recipe.
And while the tools have changed, the goals are roughly the same, are they not? Still automated. Still giving DBAs and SysAdmins more time to think about other problems in need of being solved.
I’m thinking about the SysAdmin who can’t keep their eyes open at 3AM restarting failed applications that could just as easily be restarted by a monitoring service.
I’m thinking about the developer who needs to get that app out the door in three days and doesn’t care about the server it runs on.
I think about people trying to assemble the other parts of their business who don’t have time to think about their infrastructure.
I think about the customers who only wants to complete their purchase instead of waiting for the page to load because servers aren’t scaling effectively.
I think about the customers who only wants to complete their purchase instead of waiting for the page to load because servers aren’t scaling effectively.
When we talk about system automation, we should be thinking about the people we’re automating to help. The sysadmin, the DBA, the developer, the business owner, each of their (and our own) customers. We aren’t automating for the sake of automating; we’re doing it to help solve problems for people.
We must empathize if we are to help.
If you haven’t zeroed in on it just yet… The secret ingredient to systems automation - much like Soylent Green - is people.
When I talk about systems automation, the benefits it brings, I’m thinking about people.
Empathy is a core theme of the DevOps movement.
When we talk about system automation, we should be thinking about the people we’re automating to help. The sysadmin, the DBA, the developer, the business owner, each of their (and our own) customers. We aren’t automating for the sake of automating; we’re doing it to help solve problems for people.
We must empathize if we are to help.