Chris Boos on Automation

When discussion comes to clouds, there are some arguments, that are often repeated by skeptics: data privacy and security but also the availability of data.

These points are aiming the spine of IT, touching the most valuable IT-assets, data. From private photo collections to enterprise data warehouses, loosing data is usually worst that could happen and is often not an option. This is true, independent which computing paradigm you follow: if you keep your hardware under your table, in the closet, in a (On-Premise)-Data Center or if you store it in the clouds, that means in data centers of the computing-service provider of your choice somewhere in the world.

And this is the point: Why is it, that with any new technological invention these discussions are brought up? I remember these 25 years ago, when RAID-systems came up, starting to conquer the later on so called SLED (Single Large Expensive Disks). Rember that Fujitsu Super Eagle, 19″, 8 Units, 150 pounds and 600MB Storage? How is it possible to securely store a single file by splitting it up and store it on 5 disperate, cheap SCSI-Disks? And years later, you might say, skeptics where right – I save raids dying for some reasons and we had to restore data from logically corrupted tape backup – **it happens.

Human Nature?

I guess it is human nature to bring up these arguments. Security and steadiness are human needs that follow directly after basic needs like food, shelter or clothing.  Because I understand that this is an important issue, I’m willing to have a candid discussion on this topic.

Living in Germany I’m not only looking human needs, but also have to keep Law and order in mind. Laws that influence not only public life, but we also have certain laws aiming at handling, storing, processing of data, trying to protect any indivual person from harm by loss or misuse of their personal data and also putting regulations on any institution that handles any kind of person-related data. Other countries have similar laws or regulations, eg. HIPAA in the healthcare sector.

Holiday Photographs

I assume, that anybody in the past, storing his/her personal holiday photographs, didn’t waste a thought nor a dime on keeping redundant copies. Possibly the most important images of the first day in school were duplicated. Nobody asked about redundancy or data security. Ok. Privacy was not the issue, keeping them in the locked drawer. But when it comes to personal photo cloud-storage, eg. Smugmug, based on Amazon S3, people start asking questions. My personal opinion is, that Smugmug’s business model is based on the fact that you pay money for a secure and reliable data storage (“All that was left after a twister struck my house are my holiday photographs” <LINK>), so the will take every measure, that this won’t happen.

Talking about Risks

If I still feel uncomfortable with the situation, it’s up to me to develop my private data protection strategy and keep files stored on my local harddrive. So I still can use the cool, new community and sharing features and still have a local copy of my photographs. Same point applies for enterprise computing. Just bigger databases and more users. Repeat after me: Security is just a matter of personal needs and money.

I don’t want to start a case in favor or against Cloud Computing like others, but instead I suggest to openly discuss risks and their management <See Bernard Golden>. But this discussion is not related or limited to cloud computing. Any data processing or management, regardless if paper/pencil based, server-based or cloud-based imposes risks that have to be assessed and hopefully mitigated or maybe not, so you have to bear or share them.

So What?

The cloud-vendors have to face the enterprise grade security discussion and need to offer concepts and architectures that provide the personally or even statutory relvant level of security. Maybe in the past the they didn’t do enought to help cloud computing to come out of beta state and enter the enterprises. In the mean time we should be looking for new ideas like RAIC described be Storage Architect Chris M. Evans <HERE> and Enterprise Architect Mark Masterson <HERE>.

I’m sure there are more people and companies working on concepts and products addressing these issues, so let’s find solutions and look forward to new opportunities, rather than only whining about dangers and risks. Trying to keep the status quo also bears risks. Especially in these times.

Roland

Well, what a very basic question… Should we be discussing automation engines, when we should not have trust in them automatically taking action? Surely not, and obviously we are discussing automation engines.

So why do I hear so much about the lack of trust towards automated actions? It may be a stunning change in the field of system administration, that some entity takes automatic action where normally a system administrator would have typed in a couple of commands up to now. And change always induces fear and prejudice. Questions like “do you really trust the engine to restart this business critical service?” are not really uncommon. Well why should the machine not do that? After all the only action a system administrator would have taken is to restart the whole machine instead of just the service?

This simple every day example shows the real problem: Trust

We seem to have a problem when faced with the necessity to trust a machine or some lower level of reactive “intelligence”. Maybe this is just due to the many science fiction books we have read on robots and machines gone mad. In the end we are the ones who gave the engine the rule set by which it acts.

Actually we trust in automation every day we step into a lift. Much more than that, we rely on hard wired automation when we breathe or when our heart beats. I think none of us would be too happy about the idea of having to think and act out every breath and heartbeat consciously and willingly. Not much difference in automated actions in IT administration – and just like you can hold your breath automated actions can be overridden at any time.

This sounds very logical, doesn´t it? But logic is not the drink for “unsinkable rubber ducks” (the term true believer nowadays it too closely connected to politics – and besides much less enjoyable). So a good argument usually does not help much. In order to get on with automation either management uses force or try to employ man´s oldest habit – laziness (maybe we could get entangled in a discussion on greed or laziness being around first). And do not get me wrong, great things like the wheel were invented because of laziness. And on the way, we build trust towards automation in a non intrusive way – i.e. everyone involved can discover for himself that automation helps and is not evil. So this is how it is done:

1. Setup the automation engine in full
2. Disable all automated commands and redirect them to a trouble ticket or service management tool.
3. Have administrators use this tool and hence make them see what the engine would have done.
4. After a while people will start to copy and past the commands form the trouble ticket or service management tool into the various command lines.
5. This is the time to enable automatic command execution. The connection to the service management or trouble ticket system stays as it is. So the commands executed are not in any way “block boxed”.
6. There will not be mistrust and all the discussions, bad feelings and politics attached to it.