Devops and the Art of Being Lazy


My job title is “Senior Engineer, Devops”, no one ever understands what it is that I actually do.  So here we go down the rabbit hole of what devops is.  The short answer is nothing, really it is a buzzword that people use to describe and formalize something that a handful of us have been doing for years.  The long answer is so much longer.

It all began in the 1970’s when a couple of very nice (by all accounts) gentlemen working at Bell Labs invented a new operating system called Unix.  It was an entirely new system that literally turned the computing world around.  Well these nice gentlemen Ken Thompson and Dennis Ritchie had created a new programming language called C, then they decided to write Unix and the world was a happy place.  Later Ken Thompson decided it would be nice to interact with the new operating system and wrote something called Thompson Shell which was a command line interface to the operating system, you could type an instruction and the shell would interpret it as a function or a command.  The world was still a happy a nice place, over the years there were many innovations in this entire arena, without going into to much detail if you want to know the history of Unix and what came afterward there is an amazing diagram here.  Many improvements to the shell were created until eventually we had something that could be considered the modern shell things like, bashKorn shell, and zsh.  The remarkable thing about these new shells was the ability to script for them.  You could create a file with a whole list of things that should be executed and it would execute them.  At the time same there were programming languages being written which had similar goals, perlpython and ruby.  Whilst the programming languages could do so much more they still had the ability to run on the operating system and execute a bunch of commands, and functions.

 

devops loop

https://aws.amazon.com/autoscaling/

Now imagine you are a system administrator, your job is to look after the systems on a daily basis, keep them running smoothly.  The worst part of your job is to have give users access to the system, everyday you get given a list of new users to add and a list of old users to remove.  It is frustrating it takes at least a minute to add or remove a user, and you get given a list of 100 a day, this is 100 minutes of your day wasted everyday.  Well just imagine you could write a script to do it for you.  An email comes in your script grabs the email pulls the list of users to be removed and removes them for you, it also grabs the list of users to be added and adds them for you.  You just managed to save yourself 100 minutes a day.  Now what else do you have to do all the time, checking log files!  Ok lets write a script to go to the logs on all your systems and put it in one place.  Still takes to long, fine lets remove everything we know we don’t care about.  Before you know it you have pretty much scripted a huge amount of your job.  This process is call automation.  You are using scripts to automate the boring and repetitive jobs, there is a little system administrators mantra, “If you have to do it more than once write a script to do it for you”.

Now we have half of the story about devops, it requires automation.  What about the rest?  Well lets approach this from the other side of the house, if you look at the ‘ops’ part of devops as operations, what is the ‘dev’ part?  Enter the developers. historically there has been a tense relationship between developers and system administrators, something I can personally attest to having been on both sides of this fence. So traditionally a developer would go to a system admin and say, “Hey I just did x and I need y resources to make it a reality”, to which the admin (after laughing) would say ok, it will say me a week to order after approval 4 weeks for it to arrive and 2 weeks for me to configure (in a quick company).  Then came the cloud…..

Now is the perfect time to take a break from all this historical stuff to talk about two things that happened during this period. The first was Configuration management which began (argumentatively) with cfengine and culminated (equally argumentatively) with puppetchefansible, and salt (the cf management I won’t even link to).  Configuration management is amazing it takes the description of a system and ensures state.  Let me very briefly explain this, say you want a computer to look like you write a little configuration on the platform of your choice and hey presto this computer always looks like x. To expand slightly say you want a particular 5 users to always exist along with a particular 10 packages, and a specific configuration file you simply write them into your configuration management software, ensure there is a communication method between your configuration software and for your system, and presto chango you have the configuration you want on the system you want.  Almost like magic.

The second thing that started happening during this period was cloud computing, and if you thought configuration management was difficult to wrap your brain around get ready to get a migraine.  Cloud computing is simple in concept and far to complex in reality, the simple side is you have a company that will provide your exact requirements for computing for a monthly fee, without having to buy the system yourself.  This is literally a bean counters dream come true.  You need x resources on y systems during z amount of time then go for it (sorry for the algebra) but lets break it down.

  • Your need 5 web servers a day to handle your clients for 8 hours a day
  • Your need 2 databases a day to handle your clients and the data computations a day for 10 hours a day
  • You need a way to distribute the traffic between these resources

Traditionally you had 2 choices buy crazy expensive systems to handle the maximum load 24/7 plus one extra (if you work in IT you will learn N+1 means what I need plus one more just in case). Or you needed even more crazy expensive systems running virtual environments (vmware) 24/7 using n+1.  This was very expensive, I mean stupidly expensive, but cloud computing means this doesn’t need to be the case.  Once again and aside I will use AWS for all future examples for 2 reasons firstly they have a stupidly large market share (like 5 times their nearest 14 competitors) and secondly it is what I am most familiar with (sorry no link here).  With cloud computing you can use what you need and pay for just that.  For example our earlier example you need 5 web servers and 2 database servers and a load balancer for a maximum for 10 hours a day (using dell and F5 for typical numbers I come up with over $150,000 for a fairly basic setup), using aws with autoscaling the number is closer to $5,000 a month.  Cloud computing in a nutshell means a company has made a very large amount of computer resources available to the general public on a pay as your go scheme.  You pay for what you need when you need it.

Devops

https://aws.amazon.com/autoscaling/

Now lets go back to the developers and the system administrators, a developer one day decided (most likely) I know what I know what I need and I know enough about systems to stand up my own systems and make sure they look like what I need using configuration management and the cloud, and I don’t even need that bastard system admin to come in,  At about the same time a system administrator (most likely) said you know what I can give these damn developers exactly what they need on the cloud without the need for going through our usual order processing system.

Thus was born a beautiful new thing the marriage of developers and system administrators (development and  operations devops for short) the literal marriage between a developer mindset and a system administrator mindset. The best of both worlds.  A person that was lazy and wanted to avoid repeating the same thing multiple times and a person that wanted to produce the coolest yet cheapest product in the shortest amount of time.

Long story short or tl;dr; marriage between developers and systems administrators = devops.

Of course management was unusually quick, as opposed to when asking them to write a check, to dub this new thing…. “devops” and thus a story that was happening for years became new and hip.

Now there is obviously much more to this and I would encourage everyone to learn about AWS, Puppet and Devops using Google which is obviously your friend to get the unabridged version.

So long story short, people that do devops are lazy by nature, this is simply a fact and I work with a team of them not to mention being one of them.  Our job it to make your life easer by automating literally everything, we automate the crap out of everything so that in an ideal world we don’t ever have to touch your environment ever again.  We take pride in this, it is hubris at it’s very best. Which ties very nicely into the perl mantra Laziness, Impatience and hubris.

Questions?

Leave a comment