Cloud unicorns are extinct so DiData cloud mess was YOUR fault Last July, Dimension Data's Australian cloud went down for over 24 hours. Now the company says its assessment of the incident found those who suffered the most had themselves to blame, to a degree. Speaking today at the launch of the company's new government cloud, cloud general manager David Hanrahan said those impacted by …
... to pronounce the company's name, even if mentally, as "die-day-ta?" Be that as it may, he's exactly correct. Whether loosely or tightly coupled, you've got a real problem when part of your system goes missing. Come now, we have a restore strategy for our data, we may (must) have a restore strategy when a machine or virtual machine goes missing. Right? So why the frag is it so hard to realize that you need an instance restoration strategy in place when some remote piece of the architecture goes missing.
I'd, at the very least, have a zone migration scripting in place for the day when you lose the zone. Heck, I'd even see how hard it would be to have another service on tap for the time (Azure anyone?) a service goes south. I'd say this isn't "rocket science" except for the fact that it really is rocket science. "At NASA, we have a backup for everything." [Armageddon] That's just taking loosely coupled to the next level. And I really like to have things set up to take care of themselves. Much easier to select and fire the scripts to reallocate our system(s) dynamically.
As for the cost, just remember that it's somebody else's hardware service you are renting. Disaster Recovery (DR) is a necessity, and it sure ain't just your on premise system that has to be taken into account. Oh, and as to the cost, well y'all need to look at the extra expense as an insurance policy, just like DR. You really have a DR setup, right? Duh.
For nearly five damned years, I've been saying exactly this about "cloud computing" on these here Register pages. Oh, no, Trevor, you're mad! The cloud doesn't need backups! The cloud doesn't need DR to another cloud or locally! The cloud provides! The cloud is immeasurably cheaper! The cloud, the cloud, the cloud!
Well, dear "on message" sycophants: I told you so. And, immature as it is, it do feel good. That goes double for the Microsoft ones that keep banging on about Azure. I doubly hate the lot of you because Microsoft's obsession with Azure is kicking the shit out of the channel as they try to drive all their partners out of business.
And why? So that we can put everything into the cloud and provide our clients with worse service than they had when they ran in a "local + backed up to the MSP's datacenter" setup?
Roar! Microsoft's "CloudOS" crap is a fucking lie. Their desperate attempt to kill off the "third pillar" of that marketing malarkey - the third party service provider - will result in more companies getting bitten by this single-source cloud failure garbage.
Anyone who thinks "the cloud" is the be-all and end-all solution to IT is doing everyone they advise a disservice. The public cloud is just one tool in the toolbox. One tool amongst many. And you need to know how to use them all before you can advise people on using them wisely.
Yeah. Unfortunately you haven't been able to say it to the people who make the decisions and they don't really want to hear it.
My take on this is that web applications are relatively mature in the cloud and are particularly well suited due to the peaky nature of the traffic pattern. Disasters still occur when things are poorly coded or put with poor providers (and Azure's bizarre global outages are rapidly and ominously moving them into the latter category) but cloud feels like a best fit with the right planning.
Enterprise applications, which are a much bigger and more complicated part of the overall IT market, are much less of a fit for cloud and so the risk/reward metrics need to be weighed much more carefully. Newly written enterprise apps may (may) be a good fit if they're built from the ground up, but there are still significant data security/sovereignty concerns which are a long way from resolved for anyone outside the US considering the big providers.
I really hate this absurd idea that's STILL floating around that computing resource will ever be a utility the way electricity is. It's rotting the brains of people who would have known better before they did an MBA which made them feel more competent while making them less.
>Their desperate attempt to kill off the "third pillar" of that marketing malarkey - the third party service provider - will result in more companies getting bitten by this single-source cloud failure garbage.
It isn't even that sophisticated. The whole idea of the cloud is that you don't need to know about the underlying IT, which is simply untrue as DiData are pointing out. You have to know your applications and your infrastructure if you want it to function in a particular way.
That leaves the cloud useful for non-critical things but not the basis for your business. The bottom has fallen out of the IT industry because we've completed the computerisation/networking of business. There's little raw kit/software left to sell. Cloud is basically outsourcing and cloud companies are desperate for recurring revenue now no-one is placing big orders for new kit. Surprisingly for some, you can't do outsourcing without knowing what's going on with the infrastructure. There is no "inevitability" about outsourcing, despite what Turnbull says. Cloud is not "magic." The engineering is hard, which is why a simpler in-house solution may actually be more robust.
Personally I'm surprised that ISP's haven't stepped in to offer an in between solution. Put in a couple of good load-balancers and share them between customers. That would seem like a good idea to me - share the expensive bits but keep the server-side engineering simple.
"That leaves the cloud useful for non-critical things but not the basis for your business."
Whether you deploy your systems in-house or in-cloud, you still need to understand them end-to-end; you still need to monitor them, back them up and have a DR plan. Deploying them in-house isn't necessarily going to make them any more reliable. It may be simpler, but do you have spare kit on hand, ready to shift the load straight onto if a piece of hardware fails? What if your power or ISP uplink fails, can you shift over to another data centre quickly?
You also have to tie up a lot of capital in kit which quickly depreciates; and growing it (e.g. adding more CPU cores) is expensive.
Oh, no, Trevor, you're mad! The cloud doesn't need backups! The cloud doesn't need DR to another cloud or locally! The cloud provides! The cloud is immeasurably cheaper! The cloud, the cloud, the cloud!
I can't remember anyone vaingloriously hyping cloudy services to such an extend in the forum?
This is not the marketing department after all.
I can think of at least three Microsoft shills and a dozen or so generic cloudy acolytes that have repeatedly made these sorts of drain bramaged claims of cloud ubersuitability. Especially that clouds were the solution for virtually every workload: workloads that didn't fit into the cloud were the exception. And boy, were they emphatic about it.
I have a number of direct debits which allow companies to take money directly from my bank account. I'm sure you do too.
Also, I have at various times given front door keys to trusted neighbours or relatives.
So to answer your question, yes, I would.
I think we are missing something here in the rush to say "I told you so". the guy from DiData could have come out with something marketing created for him but he choose to tell it like it is. Ultimately it was the responsibility of those buying the services to ensure that they had put together a "proper" and complete system.
Too many organisations are diving into the cloud without thinking about it properly, as a result of reading this article perhaps some of them will think twice next time or think again about the services they have already bought and if they do that will be a good thing!
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
