Have you ever heard the term “code abstraction”? The word means creating an interface of sorts around another piece of code that compartmentalizes that code. Think of it as an action or task that bundles a bunch of code up into a package which could then be used later.
The concept is like a function. In PowerShell, we have the Get-Content command. When you run the Get-Content, it doesn’t just inherently know how to read a file. There’s code inside of Get-Content that finds the file on the disk, reads the file, open an object, close an object, runs a method, and so on. But for you and I, we can just run Get-Content by providing a file path, and it just works. That’s one of the great things about PowerShell. PowerShell abstracts away a lot of the things that you don’t need.
That same concept can be thought of as tool-making but to a higher level. It’s a similar concept, where you don’t think about writing codes regarding just writing one big piece of code. In its place, you think of writing code by writing little tools that you can reuse later on. A tool could be a function, but it could also be a script as well. The tool “abstracts” away from the stuff you don’t need to know about to get the job done.
Let’s say every time I want to deploy a virtual machine, I install Windows from scratch and apply a bunch of configuration items to it. I’m repeating this over and over when I don’t need to. I don’t need to know how to do all of this stuff. Instead, I just need a tool like
New-CompanyVirtualMachine -Name 'SRV1'. When I do that, I can just run one command, and it does all that stuff for me. I don’t have to worry about those steps. I’m abstracting away the task of creating a company-specific virtual machine into a single function or script.
Ready to stop reading and start learning about PowerShell, DSC, Windows Server, Sharepoint, IIS and dozens of other categories? If so, check out the hundreds of free technical demo screencasts available on the new, IT career development platform TechSnips.
This abstraction concept can be applied to other automation areas as well. For example, I use a service called Zapier. Zapier is similar to the IFTTT service. Zapier has all of these components/tools that allow me to hook into hundreds of different services. Zapier then provides an interface for me to link them together. Zapier is abstracting away all of the various ways these services allow API access and gives me an easy to understand interface. I don’t have to craft my own HTTP POST request, figure out what the body is and so on. I don’t have to do any of that because the tool always knows. All of those things are abstracted away.
This is the kind of concept that you need to get into not only when writing code but thinking about IT automation. It’s all about building yourself a level playing field that all components in a workflow design can adhere to.
Another excellent example that I like is around PowerShell module design. Whenever you build a module, it’s always good to create a module around a specific concept. Every functional module has a few core commands with the same noun. For instance, maybe I’m building a module for an application called Foo. To make a module that accounts for the complete lifecycle of this application, I would use the CRUD method (create, read, update, delete) to create functions like
New-Foo. All of these commands have the same noun but different verbs.
I have abstracted away all of the underlying stuff that’s required to manage Foo. One command could be running a command-line utility, one command could be calling a REST API, and one command could be just running a Windows installer. It doesn’t matter to me. I’ve created a standard way to manage Foo.
As you’re building a tool, notice when you’re repeating yourself. Notice when one script or function is consistently being called by other functions. Standardize as much as possible. Compartmentalize as much code as possible and prevent yourself from writing the same line of code over and over.
If you can grasp the concept of compartmentalizing, standardizing and automating tasks to execute one action at a time, that’s key. That kind of general mindset will allow you to design and build some awesome scripts and automation worflows.
This post has been brought to you by a #CarTalks YouTube video. Be sure to check out the Adam the Automator YouTube channel for the rest of the #CarTalks videos as well as many others!