The day after 'S3izure', does anyone feel like moving to the cloud? Today might not be the best day to contemplate migrating to the cloud, given that yesterday's epic Amazon Web Services outage. But that hasn't stopped Google and Microsoft from issuing new offers to help you take on-premises workloads into their clouds. Google first: it's done a deal with an outfit called Cloud Endure that …
... but don't pretend to be surprised at the consequences when it is dropped.
"Cloud" has always thrived on marketurds' BS, and for all its strengths of flexibility and agility, the giant-mainframe paradigm has the same weakness now that it had during the 1970s: when the centre fails, everyone loses.
The dominant cloud providers want your money much more than they care about the continuity of your business. You can figure out the rest yourself.
The cloud, in my opinion, is a good last line of defence when it comes to data backups and storage. I don't see any value in using it for things like content delivery or website hosting. You're just asking for trouble by putting everything in one bucket.
I use it to back up data on my servers, but this comes after the server providers make their own back up snapshot of our servers. Currently I'm trying to convince the accountants to allow me to bring those server backups in house, as a third safe place in the event that our server providers also use Amazon to back up our server images and we both lose our backups if/when Amazon goes down again.
So how do you host your websites then?
I work for a small company hosting databases and application servers (our software) for a handful customers (less than 1000 I think).
Unlike msft, amazon or google, we cannot afford to keep our data center manned 24x7. We cannot afford to engineer our own hardware to reduce operation costs. We do have a co-location, but I believe the switchover is very much manual. It smells like something out of the 1990s, but I admit I am not familiar with the details.
Our application can however be hosted in the Azure cloud. It is basically a state-less web service that can be hosted on n servers accessing customer specific databases. The one thing that concerns me (early research days yet) is the database backend. How do Azure provide a fault tolerant database instance? But I suspect they have probably thought about that as well.
What I assume is that the cloud operators can spread the costs over many more customers. Thus they can put in place several fail-over solutions. And they can buy the newest hardware in bulk, so further cost savings can be had.
Ok, so Amazon had a little downtime yesterday. Does that happen often? Because the service provided by "my" IT guys certainly has its fair share of downtime as well.
Our application can however be hosted in the Azure cloud. It is basically a state-less web service that can be hosted on n servers accessing customer specific databases.
That's kind of the point though. Your application stack is engineered in such a way that it's compatible with the way that public cloud operates, therefore for your business, cloud makes sense.
One size doesn't fit all; for an organisation with a lot of complex applications with multiple data feeds, multiple transform engines and such like, with a big service-management layer sat on top of it all and bonuses linked to performance - cloud just can't compete with an on-premises deployment. In my organisation, the idea of a "little down time" at any time of the day or night unless it's been pre-approved a month in advance by a cast of thousands means a huge amount of pain for all concerned. And being unable to provide business people with a comprehensive update within about half an hour of any sort of wobble taking place is a problem. Being kept in the dark for several hours without any clue what happened or when it will be fixed? I'd love to be a fly on the wall in the Incident Review for that one. Assuming I wasn't in line to cop any of the blame, obviously.
"So how do you host your websites then?"
Through VPS's. Two (at the moment) host 6 sites (3 each). These sites are then replicated on to two other VPS's which are hosted elsewhere with a different company. So the data is mirrored from the primary VPS's to the secondary ones.
In the even of a failure on the main VPS's, the domain name is switched to the secondary VPS until the problem is resolved.
Plus the beauty with the VPS's is that if there's a hardware failure on the host they can be moved to another machine. And in my experience, with the primary VPS providers anyway, they do this very quickly with hardly any down time.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
