Moral of the story? Know who you are and ride the X for Y thing if it helps open doors but don't build your brand around it. "Mint.com for the Cloud" worked for Cloudability initially but we tried to limit our use of it early on so it didn't define us. Sometimes it still does though >.<
I'd counter that if Company X learns that they're employees are using Basecamp at $99/mo to actually get things done rather than a much more expensive tool that team members don't want to use, the company has gained a valuable insight into how they can save a lot of money (and make their team's life easier). Call me a dreamer but I believe everyone wins on the cloud.
I worked at a company that had invested big $$$ into an agile tool without consulting the teams if it was adequate for their needs. For a month or 2, the teams used the tool as required. Eventually, when the boss turned his back, each team quietly found a tool. Because they were being quiet, each team found a different tool from every other team. They were actually tracking their progress in both systems, but the expensive one was only being updated afterwards. Everyone would sit around the easy-to-use tool and plan things, and then 1 unlucky soul had to transcribe it into the crappy tool. This actually sped things up because the crappy tool would waste time x5, where the combination of tools only wasted time x1. (And we usually got a non-developer to do the transcribing, too.)
Eventually, the whole thing came to light and the company was forced to admit how stupid they were being.
See, they had paid for a year's service of the bad tool, and they were adamant that they get their money's worth. They were absolutely blind to how much money they were wasting daily. The sunk cost was sunk. There was no way to recover from that, and the tool just couldn't be salvaged.
I think this is a common occurrence with government IT spending too. I worked as an electronics engineer for a short time as a contractor. They paid huge sums for some software archiving / source control / versioning program that can't actually handle merging (if I work on version 2 and check in my version becomes version 3. If you were also working on version 2 and check in version 3, you overwrite my changes, unless we worked on different files. It is as if the people who implemented it didn't really know what version control is supposed to do). So everyone ignores it and uses git or svn ti develop, and only copies to the expensive official program when coerced. When we tried to explain to management why we used svn instead, management flatly refused to believe merging source control a la svn could work in principle.
Curious: after the year of service was up, did the company decide to go with one of the other tools you guys found, or did they keep dropping stupid money?
After about 5 or 6 months of that nonsense, they discovered the deception (because we let them in on it... that was a nervous moment, and I got to break the news. lucky me!) and they finally relented and stopped pestering us about the tool they paid too much for. All the teams agreed fairly quickly that 1 particular tool was better, and we all standardized on it.
It is redundant to a degree, but there are varying layers of redundancy.
In this case, it looks like most users of AWS are in need of more geographic redundancy, but in terms of localized data redundancy (term?), it appears AWS is a pretty solid solution.
That's totally right: it's a pretty solid solution and frankly, even with the outage, it's still better than the alternatives based on cost and difficulty of configuration.
