From being a pet owner to becoming a Herdsman
So we’ve finally got our own little golden retriever pup back home. Her name is Barfi. It has been a roller coaster of a month so far. Life is changing and changing rapidly with every passing day having its own adventure and mishaps. Being an IT-systems-guy-turned-Cloud-Architect and with an obvious and blatant intent to draw comparisons between my everyday life and the IT world, I was able to draw some uncanny similarities between treating our pets and our IT systems.
Here are a few characteristics of Barfi
· Needs continuous personal attention
· Wakes up at 6.30 AM sharp and wakes us up as well
· Plays only with specific toys (she doesn’t like all the toys)
· Responds only to handcrafted methods to control her temper, mood, and apetitie
· Potty training (of course!)
· Habituation with outside world (So that she doesn’t jump on you when visit my place)
Now, the important point here is that our neighbour’s dog is completely different. He is a Beagle and he’s much more demanding. He has his own schedule, routine, habits, liking for food, temper, and athletic, mental and emotional quotients. It’s true that no two pets are similar. The methods and techniques that we apply to control and pet Barfi don’t apply to Bruno, the Beagle.
So I can say that Barfi is a reasonably good dog. When I say good, I mean that she’s not too demanding. She behaves herself and she is doing well with her training activities. Bruno, on the other hand, is a dog that has got separation anxiety, temper and biting issues, and misbehaves quite a lot.
It turns out that my neighbour was living with a bunch of other flatmates and each of them had their own agenda for training and style of petting. Apparently, this got Bruno confused and has made him to be an un-trainable dog. A pet needs a single owner and training needs to be homogeneous and consistent. As a result of this problem, an expert dog-trainer has been hired by my neighbour now under the hope that it will eventually help Bruno behave himself. Fingers crossed!
The worst case scenario will be giving Bruno off to a shelter home, but I know that my neighbour is already emotionally invested in Bruno. This is going to be a tough call!
Now, I’m going to have to ask you to park your thought just there and shift your focus to the traditional way of running, operating and maintaining IT systems.
The characteristics of a typical IT system
· Needs continuous monitoring
· Needs specific bug fixes, software versions and other dependencies
· Handcrafted scripts and tools to fix issues as and when they arise (E.g. a script to restart the service when the memory utilization peaks on a particular machine)
· Has its own scheduled jobs, tasks and operations
· Continuous dumping of logs to an external storage
· Need to create specific rules and policies (E.g. Security rules for communication between a Web Server and App server, different subnets, Internet access etc.)
· Destroying an old or problematic server and getting a new server or VM is layered with a number of processes and has its own channels and teams. E.g. DB team, Middleware team, Front-end team, Infra team etc.
When you treat your IT systems as pets
When you treat your systems as pets, you are basically running manually built and changed systems. You are putting in a huge amount of work by handcrafting and attending to each server’s unique needs or issues. The resulting systems are special snowflakes that aren’t truly identical. The differences between test and production environments plague application quality. The unexpected and un-reviewed changes, just like the ‘un-reviewed’ training that Bruno was put through by my neighbours’ flatmates, have been proven to be the leading cause of downtime. The worst part being, you can’t give your server to a shelter home if it misbehaves frequently. Heavy investment!
So, the idea is simple — Stop treating your IT systems as PETS and start treating them as CATTLE!
You do not have to handcraft them and cater to their unique needs. Rather, you mass produce them using a standard mechanism, kill them and get more!
What does treating systems as cattle really mean?
· Creating a model-driven system to create and operate your systems
· Treating your infrastructure like a piece of code. Just like fixing a code bug, you will change the code, build it, test it, and then deploy it
· Selecting the right set of tools to help you implement this system
In other words, you need “Infrastructure as Code”!
General IaaC Misconceptions
First things first, let’s put some of the common misconceptions away —
· You don’t need to learn Java to practise IaaC or do DevOps.
· You won’t be fired or don’t have to fire the Operations Team that take care of provisioning, maintaining and operating your infrastructure currently
· You don’t need to discard the existing automation that is already running. You just need to realise that these are code and we need to apply coding best practices to them E.g. shell scripts, Apache config files, build definitions or OS files.
· IaaC is not DevOps. It’s one of the practices of DevOps. We will see more about this part later
There are several number of ways to implement Infrastructure as Code. We will discuss the workflow, methodologies and tools available to implement IaaC in my next post (Part-2). Stay tuned!