We noticed that all of our instances -- in 3 different availability zones in US East -- all cycled at the same time. That was pretty disappointing. Kind of defeated the purpose of having things in different AZs.
Basically they won't allow blame to be placed on them for anything they do. According to AWS, it's your fault this happened.
They set up the maintenance to have as little impact as possible by splitting availability zones onto separate days so that people utilizing multiple zones for high-availability would not lose multiple zones at once.
Afterwards, they gave a detailed breakdown, linking to the vulnerability and explaining both why they had to perform maintenance and why they could not share more details upfront.
They also provided information on how to improve the fault-tolerance of your systems so that future issues like this won't stop your workflow.
Amazon isn't placing "fault" on users; they did a pretty stellar job of handling a nasty vulnerability and treating their users as well as possible.
I've had direct experience with AWS in this regard, and was equally disappointed in the outcome. If you want to see a class act in taking ownership of issues arising from such matters, have a look at Rackspace's response:
Dear Rackspace Customer,
I’m writing to apologize for the downtime and inconvenience that you and others of our customers have suffered in recent days. Like other major cloud providers, we were forced to reboot some of our customers’ servers to patch a security vulnerability affecting certain versions of XenServer, a popular open-source hypervisor. This maintenance was especially difficult for many of you because it had to be performed on short notice, and over the weekend.
Now that this issue has been fully remediated, without any reports of compromised data among our customers, I’d like to explain what happened, and why.
Whenever we at Rackspace become aware of a security vulnerability, whether in our systems or (as in this case) in third-party software, we face a balancing act. We want to be as transparent as possible with you, our customers, so you can join us in taking actions to secure your data. But we don’t want to advertise the vulnerability before it’s fixed — lest we, in effect, ring a dinner bell for the world’s cyber criminals.
That’s the dilemma that we faced over the Xen bug. Such vulnerabilities are regularly found in software, whether proprietary or open source. The key, once a bug is identified, is to fix it swiftly and quietly. This particular vulnerability could have allowed bad actors who followed a certain series of memory commands to read snippets of data belonging to other customers, or to crash the host server. We wanted to flag the issue as quickly as possible to those of you using our Standard, Performance 1, and Performance 2 Cloud Servers, and our Hadoop Cloud Big Data service. But we didn’t want to do so until we had a software patch in place to address the vulnerability.
When we learned of the security issue and realized its significance early last week, our engineers worked with our Xen partners to develop and test a patch, and organize a reboot plan. The patch wasn’t ready until the evening of Friday, Sept. 26. And the technical details of the vulnerability were scheduled to be publicly released on Wednesday, Oct. 1. We were faced with the difficult decision of whether to start our reboots over the weekend, with short notice to our customers, or postpone it until Monday. The latter course would not allow us to sufficiently stagger the reboots. It would jeopardize our ability to fully patch all the affected servers before the vulnerability became public, thus exposing our customers to heightened risk.
We decided the lesser evil was to proceed immediately, at which time we notified you, and our partners in the Xen community, of the need for an urgent server reboot. Even then, to avoid alerting cyber criminals, we didn’t mention Xen as the reason for the reboot. Another major cloud provider did attribute its reboot to security problems with Xen, which put all users of the affected versions of that hypervisor at heightened risk. But we’re relieved to report that, as of now, we’ve learned of no data compromise among Rackspace customers. Now that the vulnerability has been fully remediated, the Xen community has lifted its embargo on talking about it.
Those of you who are longtime Rackspace customers know that we have a strong record of open, timely communication with you. We reach out to you whenever there’s an issue. We answer the phone whenever you call. We do everything we can to find a solution. This past weekend, our engineers worked tirelessly with customers and partners to remediate the Xen vulnerability.
This maintenance affected nearly a quarter of our 200,000-plus customers, and in the course of it, we dropped a few balls. Some of our reboots, for example, took much longer than they should. And some of our notifications were not as clear as they should have been. We are making changes to address those mistakes. And we welcome your feedback on how we can better serve you.
As a veteran Racker who is proud of our commitment to our customers and their businesses, I am personally sorry for any inconvenience or downtime that we caused you during this incident.
Sincerely,
Taylor Rhodes
CEO and President
Rackspace
taylor.rhodes@rackspace.comRackspace's handling of the situation was a joke. They sent notification emails out at 9:30pm on a Friday night, and then proceeded to do the reboots Saturday at peak traffic times.
We have around 200 instances, had about 59 reboot, and specifically were able to plan around these happening on different days.
We weren't super excited when the window seemed to go to 4h right before it started, but we were prepared.
I'm an ex Racker and I've told people high up at Rackspace for years that until they implement something like availability zones, they're a joke for any kind of production. Their philosophy, as is pervasive in the hosting industry, is that they have paying customers so whatever they are doing must be right. Obviously Amazon often also seems to act this way, but this particular maintenance was handled well afaict, and availability zones showed their value.
This could explain why Rackspace was shopped around by Morgan Stanley. They may be profitable now, but Amazon and Google are going to eat their lunch.
I think their best move would be to pivot to be a firm that manages solutions for corporations that refuse to move off on-premises equipment for whatever reason. Their CapEx costs fall away, and they already have a deep ocean of talent to draw on.
There are already large orgs that already do this, but Rackspace has the potential to suck A LOT less than they do at the same task.
It's easy to get stuck in the tech-savvy bubble here, where most people can write code, pick up Chef in a week, and are trying to build cheaply at "web scale." Those people don't need, or want to pay for, support with their servers.
But most companies need some help to run a few servers for web and email. Rackspace is the only large hosting provider who provides that across the board.
That said, Rackspace needs to beef up their devops support, or they risk limiting their own abilities to grow with their customers.
SoftLayer has provided manged service for years, and was bigger than Rackspace even before they were purchased by IBM.
http://www.datacenterknowledge.com/archives/2009/05/14/whos-... (Ignore the 2009 - the post has been updated as of 2013)
Rackspace is the only large hosting provider who provides that across the board, because even their smallest cloud servers come with phone support. As far as I know, you cannot get phone support with an arbitrary set of cloud servers at Softlayer, or Amazon, or Google.
Elastic Beanstalk, OpsWorks, Google sites, Google apps, AWS Marketplace, etc..
Going by what you said about most companies, most registered businesses in the world are likely just looking for a single dinky site with a mailbox pointing @theirbusiness.com, definitely no need for more than a shared server. Google, Wordpress, Github pages, Shopify, and dozens of others make this very simple to setup and use. You said Rackspace is the only large hosting provider that provides this across the board, that is not true and they aren't even in my top 10 if I was looking for a provider.
For a single website that gets less than 10 visits / day with 5 html pages I was just quoted $75/mo minimum by Rackspace with some server management on my part.
How is that different from a datacenter?
1. Rackspace's maintenance announcement was sent at 9:00 PM on Friday night (Pacific time). Seriously?! I had already left for a weekend vacation without my laptop, so I couldn't do anything to get my company prepared. Even if the patch wasn't ready until Friday night, Rackspace could have scheduled the maintenance windows and announced them to customers much earlier.
2. The maintenance window for all three USA regions were scheduled at the same time. We couldn't just move to a different region without going to another continent.
3. Each maintenance window was 24 hours -- that's just too long. Even though our servers were only down for 10 minutes, we had to be on call and ready for 24 hours.
4. Although we have redundant servers in every region, we still couldn't guarantee that those redundant servers wouldn't be rebooted at the same time. As it turns out, we did lose both of our servers in ORD at the same time.