Cloud, Security, and Automation

Cloud, Security, and Automation are like three peas in a pod. They go together like peanut butter & chocolate, syrup & pancakes, or cheese & well… everything.

There is a lot of debate over what cloud means. To business leaders it tends to mean agility, intelligent frameworks, and business process automation. When they say “Cloud” they mean the fully realized promise of DevOps. Most often well tenured technologist hear “Cloud” and they think “Managed Services” or “Hyper-scale Infrastructure as a Service.”

I can think of quite a few organizations where leadership has asked for “Cloud” and what their teams are building, while technically “Cloud” are not what was asked for. Those projects tend to fail with nobody really understanding why. That’s why it can be really helpful to work with somebody who understands not only what “Cloud” is, but what different people mean when they say the word cloud. Perhaps we need a new cloud vocabulary. Like the Greek language, having something upward of 20 words for love (so there is no ambiguity), perhaps we should all be much more specific about what cloud means to us.

Why Automate?

While the DevOps model and philosophy may not work for everyone, the hallmark of a successful cloud project is Automation. Automation allows us to create tooling that is free from understanding what lies beneath. So instead of a queue of tasks waiting for one person with one skill set, that person templatizes their work and builds policies around the execution. The result is that anybody can now do this work pragmatically and the person who wrote the task can now focus on other things. This is the concept of agility through eliminating toil. Organizations that don’t have to wait for routine tasks to complete are much more efficient, not to mention freeing up the time of somebody who is able to do high-value work.

Automation is Security?

Automation also brings compliance through policy. An automated task is completed the same way every time with no missed steps or type-o’s. Updating the automation tooling is also a good time to update process documentation. This all leads to a much more consistent and supportable environment.

Automation ideally eliminates the need for privileged access. Often routine infrastructure tasks involve sensitive processes or sensitive information. This means they need to be completed by a qualified person and that person is one of few with the privileged access needed to complete the tasks. Typically these people share common administrative passwords that are tightly guarded. Part of the problem here is that they become the gatekeepers and simple things can get delayed by their lack of availability. Also the sharing of admin / root passwords makes for a security auditing nightmare. Sure Role-based access control can usually be configured but that is a significant time and maintenance investment.

A good middle ground is to use one password, but not allow any one at all access to it. The password is securely stored in your automation infrastructure. Users are allowed to request processes (possibly triggering an approval workflow) and then the automation tool executes the task while logging who requested it. No need to wait on or provide privileged access.

On-Prem, Off-Prem, DevOps, As-a-Service?

The short answer is that it doesn’t matter. The value of the “Cloud” is realized through automating tasks and providing services at a layer which abstracts the underlying platform from the end user. You can pay all of the monthly fees you want but you aren’t really going to have “Cloud” until the way those resources are consumed is programmatic.

I can help with tools that simplify some of the hyperscaler and hybrid complexities, automate tasks on or off prem, and can even help with getting an on-prem infrastructure under a subscription service model. Want to know more, please contact me.

Create a free website or blog at

Up ↑

Create your website at
Get started