Slashdot Mirror

If you never reinvent the wheel, you do not get any better wheels.

Very true. The question is whether it's worth the investment at a given time, and whether the guy who's designing the navigation system needs to know about it.

Rather, remove non-thinking academically trained compiler monkeys from the loop,

I think you missed the point widely here.

The point is not that I don't want to have to think. It's that I don't want to have to think about such inane, minute, insignificant details as memory allocation, when I should instead be thinking about things which are actually important to my application. Like, oh, business logic.

As for throwing more hardware at it, that's just a crutch. I've already seen some competitors of mine collapse because they ran into situations where a doubling of the hardware only lead to 10% improved performance.

Guessing they didn't design for horizontal scalability.

You're right, performance must be considered at the beginning. However, the details we're talking about -- again, memory allocation -- are a vertical scalability problem. Not wholly unimportant, but secondary to horizontal scalability -- mostly because you can always buy more hardware (and space, power, and cooling), even on demand, while you cannot always count on Moore's Law to provide you with a faster CPU, and when you can, it gets progressively more expensive for the performance you get.

Yes, tweaking malloc and free, and tuning for performance, all helps with vertical scalability, which means fewer servers to buy. That is a good thing, and I am not disputing it.

However, this eventually runs into the physical limitations -- if there is a theoretically most efficient algorithm, there is also a theoretical maximum for how much load any one server can handle.

And having things be modular, flexible, maintainable, even stable and portable, are all things that can help with horizontal scalability.

The time to consider vertical scalability, and that two weeks of extra programmer time, and squeezing out even 20 or 30%, is once you already have a product, and some traffic, and you're looking to cut down on operating costs. Because done right, that's all you'll be doing -- spending a little less on hosting.

I'd actually go so far as to say that most companies have a waste approaching 50% when you actually analyze how much flooring space is used, how much power, how much cooling, how much unnecessary cabling.

Now, compare the expense there with a typical programmer salary. Sometimes it's worth it, sometimes it's not.

long-term thinking has, just like in economy, been told to "go to hell", for short-term comfort.

What happened to this, then?

Modularity and flexibility is evaluated for necessity at this stage too. Not all software needs to be either of those.

In the long term, all sufficiently complex software needs to either be both of those, or be eventually replaced with something which is.

We've read recently about Twitter looking at replacing some things with Scala -- being able to replace part of your software with something written in an entirely different language is pretty damned flexible.

In the short term, deliver or die. And I'll deliver a hell of a lot faster with Ruby than you will with C. And Twitter again illustrates this -- call them lazy, call them unreliable, but you can't call them unsuccessful, and they now have the cash to do something about the other two.

I would suggest getting two full virtual servers from a hosting provider, one for your DB and one for your web/applications server. This can be based on Xen or VMware, but that doesn't doesn't matter to you. Just let the hosting provider's high-availability clustering handle things for you. Add load-balancing in only when traffic levels require it - and with the sort of traffic you are discussing, you do not need load-balancing unless your code is really bad or user requests generate some really massive computations (such as some sort of online business intelligence or analytics).

Some bigger providers in this space are here, here, here, and here. Amazon EC2, which others have mentioned, may not be a good a fit for your proposed applications, since their storage model is stateless.

http://www.mosso.com/cluster.jsp

Mosso is owned by Rackspace, and they've been using the term for a while.

(disclaimer: I work for Rackspace).

http://www.mosso.com/

There are, in fact, several web hosting companies who have already launched their own clouds with a fuller range of supporting services. For instance:

US: GoGrid, MediaTemple, Mosso

UK: ElasticHosts, FlexiScale

Absolutely agree that cloud hosting services offer significant economies over traditional hosting. While we're naming vendors, a more complete list of cloud vendors includes the following (and most offer a much fuller range of web hosting services than EC2!):

US: Amazon EC2, MediaTemple, GoGrid, Mosso, Linode, Joyent

UK: ElasticHosts, FlexiScale

There are other options for web hosting through virtual servers. I use Mosso ( http://www.mosso.com/ ) for several of my small sites and have always had 1st rate support from them. The sites I host there are just personal sites but have had zero hosting problems of any kind in the year plus I have had the account. Disclaimer: I have my Mosso account as Rackspace employee company perk so not sure of pricing. However with that being said if for some reason I were not employed at Rackspace any longer I would keep my Mosso account.

I think your math is flawed. Your 500 physical servers just went to 500 virtual servers. Each one has a dependency that is now harder to dissect and is more abstract from the hardware.

Sure you may have a smaller room - but you definitely have more complexity. Now you have servers moving all around, because you really can't tell what their true capacity is on the physical server - it just looks like CPU or memory is getting busy. Now you need to move it. In pops VMotion. This is very fancy ooo-aaah stuff. You start doing this once, twice, eighty times a day (obviously depending on the size of your environment) However, soon you start with what I call "VMotion Sickness".

See, Vmotions create two problems. 90% of the time they are just moving a problem resource to somewhere else, creating a never-ending game of whack-a-mole, AND at the same time it consumes a serious amount of resources across your entire virtualization environment.

What you've done is add COMPLEXITY to those 500 servers by pushing them onto 100 physical boxes. You've also magnified risk of physical hardware problems so maintenance must be much more rigorous. And you've now added a huge learning curve to your entire team to learn how to triage any problems and avoid whack-a-mole.

Full disclosure: I work for a systems management software company, http://www.hyperic.com/, that specializes in managing virtualized environments and talk to these shops every day. Also, while I am at it - one of our customers, http://www.mosso.com/, a clustered hosting provider that is a division of Rackspace built a great case study on managing a 100% virtualized environment. And for the record, they were able to keep their staff the same, which they thought was a big achievement. They had actually thought that virtualization would add so much complexity, they would have to ADD staff to maintain SLAs. The case study can be found here: http://download.hyperic.com/pdf/Hyperic-CS-Mosso.pdf

Mosso uses server clusters lets you run both ASP and PHP on the same setup for $100 a month. No root access, but an interesting blend of features. Might be more accessible than VPS, which is the other choice between shared and dedicated. It's owned by Rackspace Managed Hosting.