5 ms·

There are thousands (tens of thousands?) of dedicated providers, not to mention the possibility of colocating. But here's the kicker, even if Rackspace was bet

by latch 12y ago

There are thousands (tens of thousands?) of dedicated providers, not to mention the possibility of colocating. But here's the kicker, even if Rackspace was better than all the other ones and you were ok with paying the hefty price, in this not-so-new commodity reality, reliability and scalability is mostly a software issue, not an infrastructure issue. A lot of it comes down to getting a reliable messaging infrastructure in place (trivial) and writing software code that lives and breaths asynchronous messaging (not so trivial). So is Rackspace the only choice? Not even by your definition. Softlayer's a clear alternative, for example. But beyond that, reliability goes way beyond the provider, it's 96% your code.

korzun 12y ago
We are not talking about colocation/dedicated hardware. We are talking about cloud infrastructure. The provider pool that offers a mix of both (and has proper integration between cloud and hardware network) is pretty limited. Their cloud offerings (without managed support) are pretty reasonable priced in terms of $/bang. This is my opinion. > reliability and scalability is mostly a software issue Your software is not going to save you if your network is cheaply build and maintained. Your auto-scaling setup will not do anything if your provider is having network degradation issues. I never said the Rackspace is the only choice, but it's one of the better choices when you look at the big picture. Especially if you require actual hardware to be part of your infrastructure. I have been Softlayer customer for 4 years (when they first started, during EV1 days). Their network and support is superb. I also recommend them to people who want to take the hardware route. I did not mention them in my post because I have never played around with their cloud offerings. They were a bit late to the game and I have already invested into integration with other cloud providers (API, etc). Cheers.
- jnoller 12y ago
  Just on the softlayer-esque note, I'd love your thoughts about the OnMetal product
  - korzun 12y ago
    Have not tried it yet. If you do, please let me know about your experience!
    - jnoller 12y ago
      I'm biased: I work for rackspace and fucking love OnMetal - I think it's the near perfect blend of API driven booting of bare metal servers I've seen. Last time I booted a High I/O instance it came up in 2.5 minutes. And the price / performance is a sweet spot.
      - korzun 12y ago
        Nice. Do you have any pictures of OnMetal infrastructure? What do you guys have between the servers and the API layer?
hkarthik 12y ago
> A lot of it comes down to getting a reliable messaging infrastructure in place (trivial). Can you expand on this with some examples? We're currently spending a ton of time getting a RabbitMQ-based message infrastructure to work reliably in EC2 and I wouldn't really call it trivial.
- latch 12y ago
  I meant this in the sense that, for most cases, a typical deploy of something (most likely RabbitMQ) is going to meet their needs. There's a large community, stable libraries for every library and plenty of blog posts and tutorials. Maybe you're doing something I consider atypical..maybe you're pushing more messages, have lower latency requirements, than I'm used to. But at that point, nothing "cloud" is going to help (at least, certainly not something like SQS). For what it's worth, we essentially treat a write to our queue as fundamentally important as a write to our DB (wrapping the latter in a transaction of the former). This helps make sure that reliability issues shouldn't go unnoticed (I've personally never seen RabbitMQ swallowing messages, though it is something I've heard about, but seemingly always from relatively outdated versions).

by latch 12y ago

korzun 12y ago

We are not talking about colocation/dedicated hardware. We are talking about cloud infrastructure. The provider pool that offers a mix of both (and has proper integration between cloud and hardware network) is pretty limited. Their cloud offerings (without managed support) are pretty reasonable priced in terms of $/bang. This is my opinion. > reliability and scalability is mostly a software issue Your software is not going to save you if your network is cheaply build and maintained. Your auto-scaling setup will not do anything if your provider is having network degradation issues. I never said the Rackspace is the only choice, but it's one of the better choices when you look at the big picture. Especially if you require actual hardware to be part of your infrastructure. I have been Softlayer customer for 4 years (when they first started, during EV1 days). Their network and support is superb. I also recommend them to people who want to take the hardware route. I did not mention them in my post because I have never played around with their cloud offerings. They were a bit late to the game and I have already invested into integration with other cloud providers (API, etc). Cheers.

jnoller 12y ago
Just on the softlayer-esque note, I'd love your thoughts about the OnMetal product
- korzun 12y ago
  Have not tried it yet. If you do, please let me know about your experience!
  - jnoller 12y ago
    I'm biased: I work for rackspace and fucking love OnMetal - I think it's the near perfect blend of API driven booting of bare metal servers I've seen. Last time I booted a High I/O instance it came up in 2.5 minutes. And the price / performance is a sweet spot.
    - korzun 12y ago
      Nice. Do you have any pictures of OnMetal infrastructure? What do you guys have between the servers and the API layer?

hkarthik 12y ago

> A lot of it comes down to getting a reliable messaging infrastructure in place (trivial). Can you expand on this with some examples? We're currently spending a ton of time getting a RabbitMQ-based message infrastructure to work reliably in EC2 and I wouldn't really call it trivial.

latch 12y ago
I meant this in the sense that, for most cases, a typical deploy of something (most likely RabbitMQ) is going to meet their needs. There's a large community, stable libraries for every library and plenty of blog posts and tutorials. Maybe you're doing something I consider atypical..maybe you're pushing more messages, have lower latency requirements, than I'm used to. But at that point, nothing "cloud" is going to help (at least, certainly not something like SQS). For what it's worth, we essentially treat a write to our queue as fundamentally important as a write to our DB (wrapping the latter in a transaction of the former). This helps make sure that reliability issues shouldn't go unnoticed (I've personally never seen RabbitMQ swallowing messages, though it is something I've heard about, but seemingly always from relatively outdated versions).