It's confusing a lot of people because something sold as a cloud application (ie. SaaS) may or may not be designed with HA in mind and the vendor likely won't tell you. If it is, and the underlying infrastructure is sound, you're probably OK. Hopefully.
If it's not, it's not much different to an application running on some server in a co-lo somewhere, the only real difference is that you don't lease the server directly and you're not responsible for any backups.
Then you've got virtual servers (which with modern hypervisors and a suitable SAN backend can in theory make an entire application HA regardless of whether or not that was part of the original design) which confuses the issue even further. Yes, they can in theory do all that but you often find that companies selling virtual servers haven't done it at all. All they've done is bought a few racks of servers and put together some fancy management software to make it easy to create and destroy virtual servers on the fly. The features like live migration are mostly not used at all, but you don't find that one out until your virtual server fails and their support team tell you they're "rebooting the physical server it lives on". These may also be sold as "cloud servers".
Where things start to get more complicated is when the data being stored requires some massaging before you can take a copy - or for that matter if you can only take a copy under specific circumstances or your copy is only useful under specific circumstances.
For instance:
Most modern databases store their data in files on the disk. Database transactions are atomic, sure. And (hopefully, assuming a modern FS) so are disk transactions. This does not mean, however, that you can simply copy the underlying files. cp, tar et al are not atomic, so you can wind up with an unusable backup. Both MySQL and Postgres explicitly state that you need to either shut down the database, use the native backup tool (which requires a lot of free space because you're essentially dumping the DB to a text file on disk and you take a backup of that) or in the case of MySQL, lock the tables.
For instance:
Microsoft Exchange stores all the data in a honking great database. This has pros and cons. The biggest pro is with appropriate indexing (pre-cooked by Microsoft because they designed the application), it's very fast.
The biggest con is that backup and restoration of individual mailboxes are a PITA (though I understand some companies produce proprietary software to try to resolve this). It's not too difficult to backup and recover the entire server.
Something similar is true for most mail systems to a greater or lesser extent. Systems which store everything in discrete files (such as Courier IMAP) at least have the advantage that it's dead easy to recover a person's mailbox, but it's a pig to recover a particular email from it because the metadata you'd use to find the email isn't stored in the filename, it's in the file itself. About the only sensible thing you can do is create them a new mailbox, restore the entire backup into it and tell them to find the email(s) they need from in there.
These are fairly simple examples I can come up with without having to put any real effort in. It's likely that Amazon - in creating their EC2 system - created something with lots of wonderful features but "dead easy to backup and restore, very difficult to screw up the backup process" wasn't one of them.
Bigger solutions are invariably more complicated. And when they're more complicated, there's more to go wrong - and when it does go wrong, there's more that can be affected.
This is why I'm quite wary of people throwing the word "Enterprise" around. IME, it's frequently a codeword meaning "A proprietary vendor has told us their product can be all things to all men - which is technically true but what we're buying needs many more man-hours of work to turn it into anything for anyone than we can hope to dedicate."
The term you need to google for is "lawful intercept".
In essence, in most countries any telco is legally obliged to provide a mechanism for law enforcement to intercept calls and metadata about calls. Assuming Wikipedia's correct, this mechanism may allow interception to take place without the telco even knowing about it. (see: http://en.wikipedia.org/wiki/Lawful_interception) and IIRC such a mechanism is baked right into the GSM standard.
So the answer to your question is: Wiretapping does not necessarily require co-operation.
Companies seldom evaporate overnight. There's a whole bunch of processes they have to go through before they're closed down in a legal sense.
The difficulty I see is that while there's established law and procedures in place if a company holds a physical object of value that belongs to someone else on the day they go to the wall, I'm not sure it's quite so simple if the item of value is the data they held for their customers. Particularly when the customers might need access to that data within X hours or days, rather than several weeks later.
Depending on the circumstances surrounding their closure, not necessarily.
A lot depends on how business law in the country where they're based. In the UK, for instance, once a company enters administration, the directors are all sacked and administrators come in to run the business while looking for some way of disposing of it.
This means that no matter what guarantees you were given about the safety and availability of your data, those guarantees are out of the window the minute the administrators are called in. If you are very lucky, they'll keep everything running while looking for a buyer for the company as a whole - or at least for long enough for you to migrate off. If you are fantastically lucky, the buyer will keep the system running either in the long term or as long as it takes for them to transition you to something else.
Knowing this, you might wonder why anyone in their right mind would ever use a cloud-based system?
The answer is simple: Most businesses are already so thoroughly co-dependent on other businesses that they're basically screwed if specific others collapse. Adding another to the house of cards supporting your business is really not the end of the world. Furthermore, if you take any major cloud provider, all their customers have value. Most business would expect that their provider could find a buyer if they hit difficulty.
Of course that's not guaranteed, so the sensible thing is to make sure you've got a plan B if the worst happens. Easy enough when the cloud provider is just handling the OS, databases and storage (eg. Amazon EC2), rather more awkward when it's a SaaS provider (eg. Google Apps, Salesforce.com).
If car manufacturing in the UK is anything to go by, the cycle works a bit like this:
1. Companies outsource manufacturing to cheap overseas country. 2. Manufacturing more-or-less collapses in UK. 3. The UK now has a large number of skilled workers who have experience building cars and a shortage of work for them. It's fair to assume they'll work for slightly less than they used to demand, and shipping cars is remarkably expensive. So a number of foreign manufacturers set up factories in the UK. 4. Manufacturing brightens up - though the factory owner is no longer a British company.
Examples: BMW manufacture the Mini in the UK. (They also manufacture a number of engines. Yes - the UK ships car engines to Germany for BMW cars!)
Toyota, Honda and Nissan also have factories in the UK.
The best one I heard of they made a conscious decision not to. And this was in a company affected by Sabarnes-Oxley.
Apparently it was more cost-effective to edit the macro to make it SabOx compliant - which apparently entailed hacking it to completely mess with Excel's own inbuilt behaviour for things like the File/Save dialog - than it was to migrate to a proper app. I shudder to think how they've dealt with any upgrades.
I don't know why it is exactly, but a surprisingly large number of people have a lot of difficulty in abstracting information.
You tell someone who has that difficulty to click the "Print" icon and they don't think "Ah, okay, the one that looks like a printer". They think "Ah, okay, third from the left."
Thing is, you'll never know about this until something happens to mess with an icon they depend on. Then you'll never hear the end of it;)
What usually happens is a company gets big enough to have a department with a need that they perceive as being useful, but far too trivial to mess around with getting IT involved with. Fortunately, that department have one person on the team who's quite good with Excel (or sometimes Access). Frequently, that person is the person who saw the need and didn't think it worth bothering IT because they could cobble something together in an afternoon.
And that's how they start out. But then requirements get more complicated, and the little application that one person saw a need for grows. Maybe a colleague sees it and says "Hey, that's good! Where did you get that?" "I made it myself" "Really? Amazing! Tell you what, I could use a copy of that spreadsheet myself. Especially if it could also do X". And now a new version can do X.
Over the course of months or even years, the spreadsheet gets passed around the department and gets ever more complicated. In extreme cases, it winds up becoming critical to that department. Then the person who produced it leaves the company, and a few months later the IT helpdesk gets a call about it.
Anybody who's worked in IT support in a sufficiently large company will tell you similar stories.
There is a type of business it works for quite well. I know because I used to work for such a business.
The business type is one where a large number of staff have simple requirements based around a small handful of apps, none of which depend on Windows. The company was a major UK insurance broker with around 300 branches nationwide.
For the most part, the branch staff only needed access to the system which generated quotes and stored customer policy data - a legacy system dating back 20 years or more that was terminal-based. Email was web-based (Outlook Web Access on Exchange 5.5 IIRC). The branches ran IBM PCs which booted from the network. Some of the earlier PCs had been purchased as a custom build without hard drives or Windows licenses; later PCs were cheap enough that it wasn't worth the custom build, they were just configured in the BIOS to boot from the network. The company had two call centres, these used a similar system.
The Unix support team was around four people, who were if anything somewhat underworked.
1. Larger printers almost invariably support Postscript and/or PCL. More-or-less guaranteed universal support (though you may not get all the functionality you'd like in some OSs) is therefore trivial. 2. It's quite common for larger companies to lease printers rather than buy them, for a number of reasons:
You generally have all your technical support in just one location. But you have branches (and hence printers) all over the place. How will you deal with repair when printers get broken? Happens more than you'd imagine once you've got enough printers. The leasing contract (whether it's done directly through the printer manufacturer or through a third party) will include sending a man with a screwdriver pretty much anywhere in the country for no extra charge and getting him there in an agreed timescale.
The absurd prices you see quoted for leasing one or two printers are generally "fuck off" prices. As in "Fuck off, we don't want your business." They're generally a lot better when you're leasing a whole bunch of printers.
If your company buys printers as and when, and replaces them when they need it, sooner or later you wind up with many different types. Making driver support a nightmare. But with this sort of leasing agreement, you often find the company supplying the printer will supply and support only one or two models for some time. Printer discontinued? Tough, that's your supplier's problem. Having said that, larger laser printers aren't like cheap inkjets, they don't get discontinued every 6-12 months just so the manufacturer can slightly redesign the ink cartridge again.
3. When the lease goes out to tender, part of the tender document will explicitly state "Must function under $OS".
This is the motor industry you're talking about here.
An industry which seems to think it's above normal consumer law (you buy something, it's faulty, you can return it for repair/refund/replacement) and in many parts of the world the legislators have had to pass another, separate law essentially saying "Yes, this also includes the motor industry. Just because you're selling expensive items does not exempt you from it."
You must have been living under a rock for the last year.
It was used for hacking the console, making it possible to run your own software, hacked games and backups of games. Those in favour say "and? I bought the console, I can do what I like." (These people make up the bulk of/. commenters, but by and large are in a minority if you look at various PS3 forums).
Those against say "Games are expensive enough as it is, if there's more piracy they'll get even dearer. And hacked games? Where's the fun in networked play if someone can use an aimbot? The whole benefit of networked console gaming is that you're all on a level playing field."
Sony say "We don't care what you bought, our EULA allows us to add and remove features as we wish."
Legislators say "Consumers can't relinquish statutory rights, that's the whole point of consumer statutory rights. We don't care what your EULA says."
Remember that when 2.6 came out, Torvalds himself decided to stop keeping separate stable and development kernel trees. Arguably, there wasn't a lot of point - most Linux distributions add all sorts of patches anyhow, it wouldn't kill them to add another patch here and there if such a regression does come up.
So now, such a regression does come up occasionally. Doesn't matter if it does - it's not like RedHat or SuSE are going to ship the latest 2.6 kernel without testing and patching where appropriate anyway. It's the likes of Ubuntu which are going to get stung - with such fast release cycles, it's inevitable that they either choose between running an older kernel which has had a chance for any major bugs to come to light and get patched or they run a newer kernel with a couple of extra features but a higher risk of nasty bugs.
I'm not sure that's quite the same thing. I imagine it's much easier to argue "I accept the device is perfectly accurate if it's used according to these guidelines... unfortunately in this case it wasn't" than it is to argue "The device is fundamentally broken because..."
In the first case, you're arguing a one-off mistake (or, at worst, a mistake that affects everyone who was caught by that particular police officer at that particular location). In the second case, you're trying to tell a system that sees itself as getting it right 99 times out of 100 that it's made a massive fundamental cockup impacting thousands of cases nationwide on a daily basis.
(And WTF is going on with/. javascript? I click in this box and the browser scrolls back to the top of the window?!)
Slashdot Mirror
Not to mention you'd need the bandwidth on the satellite system to deal with every commercial airliner in the air simultaneously.
Do not click on above link, it's a shock video.
No mod points or I'd mod it down.
That's exactly what it is.
It's confusing a lot of people because something sold as a cloud application (ie. SaaS) may or may not be designed with HA in mind and the vendor likely won't tell you. If it is, and the underlying infrastructure is sound, you're probably OK. Hopefully.
If it's not, it's not much different to an application running on some server in a co-lo somewhere, the only real difference is that you don't lease the server directly and you're not responsible for any backups.
Then you've got virtual servers (which with modern hypervisors and a suitable SAN backend can in theory make an entire application HA regardless of whether or not that was part of the original design) which confuses the issue even further. Yes, they can in theory do all that but you often find that companies selling virtual servers haven't done it at all. All they've done is bought a few racks of servers and put together some fancy management software to make it easy to create and destroy virtual servers on the fly. The features like live migration are mostly not used at all, but you don't find that one out until your virtual server fails and their support team tell you they're "rebooting the physical server it lives on". These may also be sold as "cloud servers".
Where things start to get more complicated is when the data being stored requires some massaging before you can take a copy - or for that matter if you can only take a copy under specific circumstances or your copy is only useful under specific circumstances.
For instance:
Most modern databases store their data in files on the disk. Database transactions are atomic, sure. And (hopefully, assuming a modern FS) so are disk transactions. This does not mean, however, that you can simply copy the underlying files. cp, tar et al are not atomic, so you can wind up with an unusable backup. Both MySQL and Postgres explicitly state that you need to either shut down the database, use the native backup tool (which requires a lot of free space because you're essentially dumping the DB to a text file on disk and you take a backup of that) or in the case of MySQL, lock the tables.
For instance:
Microsoft Exchange stores all the data in a honking great database. This has pros and cons. The biggest pro is with appropriate indexing (pre-cooked by Microsoft because they designed the application), it's very fast.
The biggest con is that backup and restoration of individual mailboxes are a PITA (though I understand some companies produce proprietary software to try to resolve this). It's not too difficult to backup and recover the entire server.
Something similar is true for most mail systems to a greater or lesser extent. Systems which store everything in discrete files (such as Courier IMAP) at least have the advantage that it's dead easy to recover a person's mailbox, but it's a pig to recover a particular email from it because the metadata you'd use to find the email isn't stored in the filename, it's in the file itself. About the only sensible thing you can do is create them a new mailbox, restore the entire backup into it and tell them to find the email(s) they need from in there.
These are fairly simple examples I can come up with without having to put any real effort in. It's likely that Amazon - in creating their EC2 system - created something with lots of wonderful features but "dead easy to backup and restore, very difficult to screw up the backup process" wasn't one of them.
I've already got one of those, it's called a macro lens.
Bigger solutions are invariably more complicated. And when they're more complicated, there's more to go wrong - and when it does go wrong, there's more that can be affected.
This is why I'm quite wary of people throwing the word "Enterprise" around. IME, it's frequently a codeword meaning "A proprietary vendor has told us their product can be all things to all men - which is technically true but what we're buying needs many more man-hours of work to turn it into anything for anyone than we can hope to dedicate."
The term you need to google for is "lawful intercept".
In essence, in most countries any telco is legally obliged to provide a mechanism for law enforcement to intercept calls and metadata about calls. Assuming Wikipedia's correct, this mechanism may allow interception to take place without the telco even knowing about it. (see: http://en.wikipedia.org/wiki/Lawful_interception) and IIRC such a mechanism is baked right into the GSM standard.
So the answer to your question is: Wiretapping does not necessarily require co-operation.
Sounds like exactly the same sort of fanboi-ism as you see on here regarding the relative merits of Linux or OS X.
Companies seldom evaporate overnight. There's a whole bunch of processes they have to go through before they're closed down in a legal sense.
The difficulty I see is that while there's established law and procedures in place if a company holds a physical object of value that belongs to someone else on the day they go to the wall, I'm not sure it's quite so simple if the item of value is the data they held for their customers. Particularly when the customers might need access to that data within X hours or days, rather than several weeks later.
Depending on the circumstances surrounding their closure, not necessarily.
A lot depends on how business law in the country where they're based. In the UK, for instance, once a company enters administration, the directors are all sacked and administrators come in to run the business while looking for some way of disposing of it.
This means that no matter what guarantees you were given about the safety and availability of your data, those guarantees are out of the window the minute the administrators are called in. If you are very lucky, they'll keep everything running while looking for a buyer for the company as a whole - or at least for long enough for you to migrate off. If you are fantastically lucky, the buyer will keep the system running either in the long term or as long as it takes for them to transition you to something else.
Knowing this, you might wonder why anyone in their right mind would ever use a cloud-based system?
The answer is simple: Most businesses are already so thoroughly co-dependent on other businesses that they're basically screwed if specific others collapse. Adding another to the house of cards supporting your business is really not the end of the world. Furthermore, if you take any major cloud provider, all their customers have value. Most business would expect that their provider could find a buyer if they hit difficulty.
Of course that's not guaranteed, so the sensible thing is to make sure you've got a plan B if the worst happens. Easy enough when the cloud provider is just handling the OS, databases and storage (eg. Amazon EC2), rather more awkward when it's a SaaS provider (eg. Google Apps, Salesforce.com).
So what you're saying is the workers who got sacked now have new jobs without having to re-train significantly. Their managers, OTOH, are SOL.
Don't see the problem there.
If car manufacturing in the UK is anything to go by, the cycle works a bit like this:
1. Companies outsource manufacturing to cheap overseas country.
2. Manufacturing more-or-less collapses in UK.
3. The UK now has a large number of skilled workers who have experience building cars and a shortage of work for them. It's fair to assume they'll work for slightly less than they used to demand, and shipping cars is remarkably expensive. So a number of foreign manufacturers set up factories in the UK.
4. Manufacturing brightens up - though the factory owner is no longer a British company.
Examples: BMW manufacture the Mini in the UK. (They also manufacture a number of engines. Yes - the UK ships car engines to Germany for BMW cars!)
Toyota, Honda and Nissan also have factories in the UK.
The best one I heard of they made a conscious decision not to. And this was in a company affected by Sabarnes-Oxley.
Apparently it was more cost-effective to edit the macro to make it SabOx compliant - which apparently entailed hacking it to completely mess with Excel's own inbuilt behaviour for things like the File/Save dialog - than it was to migrate to a proper app. I shudder to think how they've dealt with any upgrades.
Tell me, how well does that tie in with laptops?
I don't know why it is exactly, but a surprisingly large number of people have a lot of difficulty in abstracting information.
You tell someone who has that difficulty to click the "Print" icon and they don't think "Ah, okay, the one that looks like a printer". They think "Ah, okay, third from the left."
Thing is, you'll never know about this until something happens to mess with an icon they depend on. Then you'll never hear the end of it ;)
You'd be surprised.
What usually happens is a company gets big enough to have a department with a need that they perceive as being useful, but far too trivial to mess around with getting IT involved with. Fortunately, that department have one person on the team who's quite good with Excel (or sometimes Access). Frequently, that person is the person who saw the need and didn't think it worth bothering IT because they could cobble something together in an afternoon.
And that's how they start out. But then requirements get more complicated, and the little application that one person saw a need for grows. Maybe a colleague sees it and says "Hey, that's good! Where did you get that?" "I made it myself" "Really? Amazing! Tell you what, I could use a copy of that spreadsheet myself. Especially if it could also do X". And now a new version can do X.
Over the course of months or even years, the spreadsheet gets passed around the department and gets ever more complicated. In extreme cases, it winds up becoming critical to that department. Then the person who produced it leaves the company, and a few months later the IT helpdesk gets a call about it.
Anybody who's worked in IT support in a sufficiently large company will tell you similar stories.
Replying to myself, but to be fair I should clarify.
Staff in non-customer facing roles (finance, IT, regional managers) had Windows desktops. They didn't even try to migrate them to Linux.
Essentially, the company replaced their dumb terminals with Linux rather than replacing Windows with Linux. Which is a much easier task ;)
There is a type of business it works for quite well. I know because I used to work for such a business.
The business type is one where a large number of staff have simple requirements based around a small handful of apps, none of which depend on Windows. The company was a major UK insurance broker with around 300 branches nationwide.
For the most part, the branch staff only needed access to the system which generated quotes and stored customer policy data - a legacy system dating back 20 years or more that was terminal-based. Email was web-based (Outlook Web Access on Exchange 5.5 IIRC). The branches ran IBM PCs which booted from the network. Some of the earlier PCs had been purchased as a custom build without hard drives or Windows licenses; later PCs were cheap enough that it wasn't worth the custom build, they were just configured in the BIOS to boot from the network. The company had two call centres, these used a similar system.
The Unix support team was around four people, who were if anything somewhat underworked.
There's a few things at issue here:
1. Larger printers almost invariably support Postscript and/or PCL. More-or-less guaranteed universal support (though you may not get all the functionality you'd like in some OSs) is therefore trivial.
2. It's quite common for larger companies to lease printers rather than buy them, for a number of reasons:
3. When the lease goes out to tender, part of the tender document will explicitly state "Must function under $OS".
I wasn't passing comment on any of the arguments, I just wanted to give an idea of what the typical arguments were.
IIRC it's the other way around, making it harder to mis-fuel a petrol vehicle than a diesel one.
This doesn't make much sense considering the other way around is substantially more expensive, but there you go...
This is the motor industry you're talking about here.
An industry which seems to think it's above normal consumer law (you buy something, it's faulty, you can return it for repair/refund/replacement) and in many parts of the world the legislators have had to pass another, separate law essentially saying "Yes, this also includes the motor industry. Just because you're selling expensive items does not exempt you from it."
You must have been living under a rock for the last year.
It was used for hacking the console, making it possible to run your own software, hacked games and backups of games. Those in favour say "and? I bought the console, I can do what I like." (These people make up the bulk of /. commenters, but by and large are in a minority if you look at various PS3 forums).
Those against say "Games are expensive enough as it is, if there's more piracy they'll get even dearer. And hacked games? Where's the fun in networked play if someone can use an aimbot? The whole benefit of networked console gaming is that you're all on a level playing field."
Sony say "We don't care what you bought, our EULA allows us to add and remove features as we wish."
Legislators say "Consumers can't relinquish statutory rights, that's the whole point of consumer statutory rights. We don't care what your EULA says."
Remember that when 2.6 came out, Torvalds himself decided to stop keeping separate stable and development kernel trees. Arguably, there wasn't a lot of point - most Linux distributions add all sorts of patches anyhow, it wouldn't kill them to add another patch here and there if such a regression does come up.
So now, such a regression does come up occasionally. Doesn't matter if it does - it's not like RedHat or SuSE are going to ship the latest 2.6 kernel without testing and patching where appropriate anyway. It's the likes of Ubuntu which are going to get stung - with such fast release cycles, it's inevitable that they either choose between running an older kernel which has had a chance for any major bugs to come to light and get patched or they run a newer kernel with a couple of extra features but a higher risk of nasty bugs.
I'm not sure that's quite the same thing. I imagine it's much easier to argue "I accept the device is perfectly accurate if it's used according to these guidelines... unfortunately in this case it wasn't" than it is to argue "The device is fundamentally broken because..."
In the first case, you're arguing a one-off mistake (or, at worst, a mistake that affects everyone who was caught by that particular police officer at that particular location). In the second case, you're trying to tell a system that sees itself as getting it right 99 times out of 100 that it's made a massive fundamental cockup impacting thousands of cases nationwide on a daily basis.
(And WTF is going on with /. javascript? I click in this box and the browser scrolls back to the top of the window?!)