21 ms·

> Rackspace Cloud was the only alternative to AWS and had one significant differentiator back then... One other big differentiator compared to AWS, and the rea

by unoti 12y ago

> Rackspace Cloud was the only alternative to AWS and had one significant differentiator back then... One other big differentiator compared to AWS, and the reason I went to Rackspace in the first place: straightforward pricing. Figuring out how much an AWS machine was going to cost was, back then at least, like trying to figure out how much it'd cost to buy a hundred Yen next Monday, for someone who has no experience with currency markets. Amazon's pricing was very complex, but with Rackspace, it was easy for me to tell how much a month would cost for what I needed. > if a customer asks for help resolving problems with Sendgrid (a competing email sending service), Rackspace support people will gladly assist... I was blown away by that, customer gets help with whatever they feel like getting it. While the uptime and performance of the machines I have on Rackspace has been great, the "fanatical support" claim is empty marketing B.S. in my personal experience. A year ago, I had a machine's performance tank while my startup's traffic started to simultaneously ramp up. It turned out there was another host on the same machine slurping too much disk resources, they moved it away. That improved things some, but I ended up needing an expert to take a look at my Apache configuration. I begged Rackspace to help. My startup's life was hanging in the balance: traffic was going up, and performance was going down. I desperately needed help from an expert, and asked Rackspace for help, and offered to pay. They did nothing for me. I started researching it for myself, and basically trained myself to be much more of an Apache configuration expert over the next 48 hours. I needed help, I had money, I was super desperate, and they did nothing for me. I guess the real problem was that I didn't need help with SendGrid, or perhaps I couldn't figure out the right people to ask.

jnoller 12y ago
You should not have had that apache problem and not gotten help. Period. That's unacceptable, and I'm sorry. We're working on it
- snowwrestler 12y ago
  Overall I've been a happy Rackspace customer for years, but we've had the same experience with Apache troubleshooting. The support ended at whether Apache was up and running. Beyond that we were told Rackspace considered it to be "application tuning"--which covers all the important settings that are used to manage loads and secure Apache. Luckily a development company we had on contract had a great Linux admin who could help us out. From this perspective Rackspace definitely has not performed a devops role for us. Network administrator? System administrator? Yes, absolutely, and great support for both. But devops is where the application meets the server, and IME Rackspace has stayed away from that. I do see the reason for it--what does Rackspace know about our application? It's not fair to hold them responsible for that. But it created a gap in our professional support. edit: words
  - jnoller 12y ago
    I think support has to move up the stack to be remotely relevant to 2014 markets and beyond. This is my goal and why I'm running point on the dev to dev support. But to your point, on the 15th we precisely outlined what is covered on each support level: http://www.rackspace.com/managed-cloud/ http://www.rackspace.com/managed-cloud/ Fundamentally; support has to become systems level, and not single instance level, and that means gaining knowledge and expertise (which we have in house) about the nuances of a given application stack.
    - quicksilver03 12y ago
      I guess it depends on the use case and the sysadmin knowledge of the client. I find that the frontier of responsibility becomes too much blurred when the service provider takes care of anything above the hardware: I personally prefer when the service provider concentrates on power and network stability, and anything else is my responsibility.

by unoti 12y ago

jnoller 12y ago

You should not have had that apache problem and not gotten help. Period. That's unacceptable, and I'm sorry. We're working on it

snowwrestler 12y ago
Overall I've been a happy Rackspace customer for years, but we've had the same experience with Apache troubleshooting. The support ended at whether Apache was up and running. Beyond that we were told Rackspace considered it to be "application tuning"--which covers all the important settings that are used to manage loads and secure Apache. Luckily a development company we had on contract had a great Linux admin who could help us out. From this perspective Rackspace definitely has not performed a devops role for us. Network administrator? System administrator? Yes, absolutely, and great support for both. But devops is where the application meets the server, and IME Rackspace has stayed away from that. I do see the reason for it--what does Rackspace know about our application? It's not fair to hold them responsible for that. But it created a gap in our professional support. edit: words
- jnoller 12y ago
  I think support has to move up the stack to be remotely relevant to 2014 markets and beyond. This is my goal and why I'm running point on the dev to dev support. But to your point, on the 15th we precisely outlined what is covered on each support level: http://www.rackspace.com/managed-cloud/ http://www.rackspace.com/managed-cloud/ Fundamentally; support has to become systems level, and not single instance level, and that means gaining knowledge and expertise (which we have in house) about the nuances of a given application stack.
  - quicksilver03 12y ago
    I guess it depends on the use case and the sysadmin knowledge of the client. I find that the frontier of responsibility becomes too much blurred when the service provider takes care of anything above the hardware: I personally prefer when the service provider concentrates on power and network stability, and anything else is my responsibility.