OK, I have a few study plans up my sleeve. In fact I have a lot of things I wish to learn. I have used Puppet, Chef, Ansible and Salt. I have used LXD and Docker, Kubernetes; KVM, VMWare and Citrix - it’s a horrible mess of information, what are the best solutions to my problems? All of the above are great tools, but the selection needs to be appropriate.
If you have mastered one software then what is to say there is a change of modus operandi and you find yourself limited due to hardware, time and money but expectations are for you to dive in and rebuild your entire infrastructure.
Well, there is no magic wand. If you are like me, you’ll want the knowledge downloaded directly in to the brain in a way that is not too dis-similar to Neo learning Kung-Fu in The Matrix. Sadly, it requires dedicated time, hairloss and practice to be able to wield the tools… Oh and possibly more hairloss depending on external factors such as software features. The real problem is when you have a very poor attention span and are bad when it comes to committing to an idea to follow it through.
The only guidance I can give is to keep it simple and ask your self what you wish to achieve.
What do you want to acheive?
List it down.
What software will do the job well?
From experience, I write this. This is probably the most important decision you’ll have to make. Don’t just wade in to the first software because it is trendy. It might not be appropriate for various reasons. Looking at your list conduct some research and take your time doing so. Use the Internet, ask Twitter, Redit, Slack, Github. Even if you are introverted, you could do well to go to meetups, conferences and participate in webinars. Then finally get the opinions of your colleagues - They might know something you don’t. Be sure to ask about scalability. Five years down the line, the budget you blew on the platform may not be available to you and the finance folks might just point and laugh instead of giving you some room to wiggle. At the end of it all, look at your list and write down the software that ticks the boxes and a pros & cons list. It might be that the solution you had set your heart on is missing a few tricks.
Once the research has been conducted you can make an informed decision, if you can’t, then prepare to download and run some labs… This should help you get your proof of concept. Creating your lab and can slow down your progress a lot of the time as other day to day tasks get in the way. Meetings, faults, projects etc. Look in to blocking some time in your calendar where you can sit in a comms room somewhere you wont be disturbed. I try and for two hours a day but what ever works for you. You could also use the Pomodoro technique if you find your attention span waivers a lot. Most software has some freely available documentation online. From official documentation to blogs and man pages. Build your lab in an isolated network - this way you wont shaft anything. Document your labs especially any difficulties or stumbling blocks. I sometimes use my bash history to retrace my steps and put it all in to a shell script which will allow me to recreate the desired state. Use snapshots if available regularly. Think of it like gaming and reaching a save point. This way - if it goes wrong you can reset.
Build a business case for approval
Building a business case is not easy. I hail from the county of North Yorkshire in the UK and Yorkshire folks are known to be very tight fisted with their money. So working here, the chances are you’ll have to convince to part with money. For the rest of the world you’ll probably at the mercy of the finance department ultimately. The key thing to remember is that it’s in the companies best interest to get a return of investment (ROI). If you tell them you want something, they are going to want it to pay for itself or work out cheaper than your current solution. With the savings made, it is possible you might be able to crowbar an extra ‘nice to have’ feature. From an a enterprise plugin to a brand new coffee machine.
Design, document & buy and build
Let’s face it. You did your research and it paid off. Now the rest should be easy if you documented your labs. Copy and paste your lab work (that worked) in to a nice corporate template document and tidy it up to make it legible enough for someone else to understand. Draw a diagram, submit your change request. If you got knocked back you need to understand the reasons for the declined business case and see if the finance department are willing to meet in the middle somewhere. Let’s face it, you did your research, there maybe a plan B you haven’t considered. Look at the other software that didn’t make the number one choice. Is it cheaper and less feature rich? Does it work? If you have a viable compromise then you are on the path to winning.
Conclusion
At the end of the day, when the whistle blows and you slide down that proverbial dinosaur tail nothing may change, but you have spent your time learning new software and solutions which can only make you a better engineer.