Sysadmin ancien d'hier
There's a bit of redundancy there, Mr Pott - kinda like saying an ancient old-timer sysadmin. He's an old-timer already, how much more do you want his back to be bent ? ;)
I am emphatically not a sysadmin, but I am clearly on the old-timer side of the path (and retirement is now barely perceptible in the haze of time), so I will jauntily assume the mantel of ye old mountain yokel and defend that "just someone else's server" position that you seem to dismiss out-of-hand.
Yes, I understand that IT is once again undergoing a sea change, what with broadband being more prevalent and data centers being something everyone apparently has these days. Someone might point out that this was inevitable. Fine.
I also readily accept that there are SLAs and contractual obligations and so on and so forth. Great.
Finally, I will not bring in to the debate the issues of security and governmental snooping. I will accept to put those aside to focus on the issue of in-house, or not in-house, which is the question (and yes, I know the article is about hybrid ; that just means that you're managing both sets of issues).
Now, for starters, don't bother me with the cost argument. It has been said in these very hallowed articles that going cloud is just displacing the cost center, there is no diminution of costs. With that out of the way, we can concentrate on five nines, functionality and performance.
When you go to the cloud, you get a rosy picture, a nice contract with a bunch of promises, and then you start finding out what actually works and how well. You might be able to do some special things, but if the Cloud is not compatible, you won't be able to do it, however much you ask and plead for it to happen. That's because you're just a drop in the cloud, and only if there are many, many more drops asking the same thing will the cloud change to you. So, in this configuration, it is you who are tied to the cloud, not the reverse.
When you go in-house, it's up to you to get the expertise and it's your money that is invested in the infrastructure. That can get quite expensive, I agree. Especially if, like RBS, you get rid of the expertise and hand over daily management to some external company that proceeds to royally screw everything up. Companies need to learn to keep expertise at hand - sometimes high salaries are worth paying.
Of course, in-house failures can and will happen. The cloud goes down for various reasons, in-house can go down as well. The difference being that you can, when in-house, identify issues beforehand, prepare mitigation procedures and, hopefully, implement them quickly when things go pear-shaped.
And if things really go pear-shaped, well you have your personnel at hand and are also there to "encourage" them to get it working again.
When things go bad in the cloud, your mitigation procedure is store the data until the connection comes back. You have only one course of action : call and find out when things will be coming back. Then you just might find out that they won't, because the cloud has been zapped by hackers, or because there were no backups, or because the datacenter is under water, etc. At that point, supposing you do have backups, you're still stuck with having to find another cloud provider, then having to set everything up there, then finding out just how hard it is to get your data on that new cloud.
You will note I have not made mention of connectivity. If your connection goes down, it doesn't matter where the servers are, you're disconnected and you'll have to wait until the connection returns.
So what I'm saying is that the cloud is not a better solution than in-house. It is just a solution with a different set of constraints. Use your server, you get one set of problems. Use someone else's server, you get another set of problems.
The real issue is understanding why you choose which set.
But it's still someone else's server.
Biting the hand that feeds IT
