Automation Without a Plan

Why tools alone won’t help you reach automation Nirvana.

DevOps consulting and implementation at the basest levels have been revolving around implementation and enablement for quite a number of years now. You reach out to a vendor, either buy a product or use an Open Source offering and have a consultant come in, setup the product, and train your staff on how to use it.

However when the consultant goes home, the hard work begins, and it is questionable just how much success your team will have since the majority of the experience they’ve had so far is just learning the syntax of this new automation language. They’ve not yet learned their stride.

Automation is good. There’s tons of products to automate with… Ansible, Puppet, Chef, SALT… there’s no lack of tools to use on your infrastructure. Perhaps you’re just instrumenting configuration… Perhaps more! Maybe you’re placing elements of an application stack, and maybe you’ve gotten to a level where you can deploy a new application in a mostly automated fashion. Many sites will stop there. They will proceed along automating redundant tasks and help to increase efficiency while reducing the error rate.

Indeed, this is the promise of automation, but in actuality your team is still thinking like operational personnel with a shiny new tool. “I used to do thing X in a segmented or serial fashion, but now I can let a tool do it the precise same way.”

This is not the promise of the automated infrastructure.

While you’ve increased efficiency and likely emboldened your team to do more with less, there’s one small component of this that breaks you free to crush your old methods, and that’s one of stepping into a paradigm shift of site and infrastructure management wherein you begin to think like a developer. Instead of seeing your environment as thousands of little components you are automating the configuration and operation of, now you have the power and the tools to see your entire infrastructure as major components of a larger operating whole.

Instead of thinking of your systems in components — ssh, httpd, named, etc., you can think of collected components expressed as the system configuration. That system configuration is an abstraction of the whole that makes up that system’s identity in your site. Seeing the site in abstractions that when collected together for higher-order abstractions, and even higher order abstractions make your infrastructure more into a collection of abstractions than individualistic configurations.

Raising your vision to one of modular components like building blocks allowed you to model your site on a much higher level, and to change the way you consider configuration, deployment, security, and even operations.

Stop looking at the tools and the individual operations of the tool on an atomic level, and consider how you may build larger abstractions to divide your site into modular segmentations and then grouping of those into larger building blocks that are then grouped together again to model very specific outcomes.

By moving to a more holistic view from above predicated on such an abstraction model puts power into your hands to speed buildouts, deploy quickly, and take your provisioning and automation to higher levels with the same tools you’ve always used.