Coding is not an option. It’s here. We’ve arrived to the point that code rules the world. The success of the organizations, today, is measured by how much coding talent they can attract. The driving factor is the economies of scale, need in automation and shrinking budgets.
But you should not be alarmed – the automation of the Ops doesn’t lead to the eradication of Ops. It merely means that the Ops should transform to support the new ways of the world. It means that you, as an Ops expert, have to slightly expand your skills horizon by picking up some of the best/better Development patterns and practices and learn how to work in a larger collaborative environments and teams.
If you’d like to know what Ops needs to know about Dev – read further.
Although you may feel today that you’re alone on a sinking ship with danger circling around (sharks, hackers and system failures) and product organization pooping on your head, going forward things look brighter. DevOps has arrived and is here to stay. Unfortunately not everyone yet accepts this new culture or interprets it properly and knows how to apply and use it. It’ll all change in time. We’ve already experienced similar transformation with Agile.
There are a lot of things you can start doing on your “ship” to make things better and, at the end, bring those “flying ones” down to earth and make them realize that we’re all on the same island. And, if we’d like to survive, we all need to work together.
At the moment, you’ll invite others to join your small “ship”, it’ll get crowded. You can accomplish more things together faster and with better quality, but it will require more discipline. A different kind of discipline than you’ve experienced before that will demand a different set of behavioral patterns.
I’m referring to the “best practices” – the patterns that development community has devised over many last years in order to put some safety nets and allow many people to work together without sacrificing on quality while not stepping on each other.
In simple words, all the mambo-jambo above means, that from this moment on you can’t continue hacking scripts left and right and leaving them to be unattended. The code that left unattended tends to rot very quickly and, after some time, you’ll be afraid to use it yourself because you’ll loose confidence in what this piece of code will be doing in ever-changing world.
The most fundamental principle in software development is DRY – Don’t Repeat Yourself. It’s not about being lazy, what some of people think, but it’s about making sure that, if a piece of code has an issue, it can be fixed in one place instead of hundreds of different places.
The next, not less important pattern, is the one that you’re mostly familiar with from your day-to-day life: a single responsibility principle. It’s familiar to you from the way you’ve been using utilities that are coming with an Operating System (ex: ls, sed, awk, …). Each one of these utilities is created to do one thing only and do it really well and you’re chaining them using “pipes” to create a variety of useful activities (ex: ls -al | awk …). By using these atomic commands/utilities and chaining them in a specific order you’ve been able to execute very complex workflows. Success of xNix operating systems can be partially attributed to the enormous power and flexibility this approach provided.
So next time you start writing any automation code (and I mean any, including shell scripts) think about use and reuse of that piece of code. It shouldn’t be a spaghetti of functionality but a “small lego” piece that will/can be reused in a bigger composition. Think about making your “lego pieces” small and simple to reduce complexity of your code. These components later are composed together into bigger components and even bigger ones (modules, libraries, applications …). Like “Turtles all the way down” …
While you’re doing your coding, make sure that you can collaborate with other members of your team and organization by using source control (ex: Git). Source control will provide you with a tremendous help by keeping all of the history of your changes in case you’ll need to recall what you’ve done and tried before. It can preserve your sanity when you’d like to try a couple of different things without managing a ton of different copies of different flavors of your code. Versioning of your components can help to preserve your sanity even more.
The last pattern I’ll point your attention to, in my view, is the hardest one to master. It’ll require a lot of discipline and practice, but, in a long term, will make your code stable, resilient and trustworthy. This pattern is TESTING. Everything that you’ll write, from the smallest “lego” piece to the largest complex application, should have it’s tests that should “pass” and prove the code “correctness”. This called a “safety net”. This “safety net” gives you assurance that anything that you can later change anywhere in the code didn’t break anything else in the code somewhere else. Tests – is the code that checks your code. Tests should be repeatable and reliable. Examples of such tests can be: if your newly created a script configures a machine, a test can validate that the machine’s final state has all the attributes your script was supposed to configure (tool ex: Test Kitchen), if your code provisioning a cluster, a test can validate that the cluster, in fact, was created and all the nodes are in the expected state (tool ex: RSpec), etc…
After you have your code with appropriate tests, you can think about applying Continuous Integration (CI) practice. Continuous Integration will ensure to run all your tests on your code each time it’ll detect that the code was modified. The result of this run would be either a “pass” or a “fail” indicator that will point your attention to the fact that your code is either “working” or “not working” based on the results of your tests. Now if you’ll hook everything into the CI Server (tool ex: Jenkins) you can get very nice visualizations that can continuously tell you at any moment of time the state of all of your scripts and automations if they are in a working and a trustworthy condition or not.
I’ll stop here and will let you to try these things in practice first before you’ll feel ready to start looking for more patters (ex: SOLID, etc…).
If you’ve reached this point, you may’ve noticed that I didn’t mention any specific language that you should use. The reason is that all these patterns apply to ALL coding/automation languages/technologies you’ll decide to use during your career. The language doesn’t matter at all – you can be proficient in achieving your goals in almost any language you’ll choose, although such choice should be done carefully because some of the languages have a very narrow/specialized use and others may have a very small community and tooling ecosystems making your life harder.
Feel free to reach out to your friends and teammates and ask questions. There is a lot more interesting stuff to learn going forward and be excited about all the new discoveries that are waiting for us in the future.
Feel free to share with us what other patterns you find helpful in your carrier.
Post image: The creator of the Geek and Poke cartoon series is Oliver Widder.