[Lewisham]

This blog post blew my mind. I generally thought of GitHub as being in the front-end business, but maybe they're really in the back-end business?

Is this sort of complexity common? I'm not saying I think it's bad, as I am sure it's all there for a good reason, but it just seems like so many services to bounce through before a web page is even served.

[nostrademons]

Pretty much, yeah. The first startup I worked at (corporate remote access) had half a dozen different services that a request touched before a connection could be established. The second (financial software) also had half a dozen to a dozen. The one I founded (casual game creation) had 4 different independent systems interacting, and never got to the point where it was productionized (I killed it because the prototypes indicated it wasn't a compelling business idea).

Google, of course, is in a class way above all those. I'm not sure if anyone actually knows how many services a single search hits now - perhaps some of the old-timers who're now VP level or above in search. The last public figures I was aware of were "hundreds of distinct services spread across tens of thousands of machines".

Most startups that actually do something useful require far more than a web frontend and a database.

[msbarnett]

In a production environment, at scale, this is a relatively uncomplex example, I think. At any rate I've seen significantly more complicated multi-service architectures for what would also have been called a "front-end" business.

[ptn]

Now, that scrambled my brains. Uncomplex? I thought this was pretty complicated and that mojombo was a scalability God (and he may be).

Could you point me to more complex examples?

[nostrademons]

This is why it's helpful to work in a big, successful company before founding your startup. You get a sense of the scale and complexity of problems that actually have real users, and practice dealing with those problems. If you stay long enough, you also get a sense of the trade-offs involved, and which complexities are accidental vs. which are inherent.

Of course, when you actually go to found the company, you should forget all that scalability nonsense and start with the simplest system possible. However, it's worth having an image in your head about how the system will evolve and what the appropriate response to various scalability challenges is.

[msbarnett]

Uncomplex is probably the wrong word. Averagely complex for this sort of thing? Not easy to achieve or trivial to build, but, from a 40,000 foot perspective, probably typical of the kinds of complexity you'd find in most popular web applications.

There's a very long discussion, somewhere, of Amazon's eventually-consistent architecture that I'd say is definitely on the high-complexity side of things. Unfortunately I can't find the link I'm thinking of, at the moment.

[alexyim]

What does this post even mean? What is a front-end business vs. a back-end business?

As far as complexity goes, I believe Amazon touches some hundred something services before a page is even served. It's no surprise that they decided to make some of that into a business and start charging for it.

[steveklabnik]

To put it slightly crudely, he thought GitHub was in the business of making a pretty UI on top of git repos, not designing Serious Technology that nobody sees.

[alexyim]

Ah, gotcha. Thanks, this makes a little more sense

[Erwin]

A few years back I've seen 100-150 as number of services accessed to render an amazon.com page; as mentioned in this 2006 interview: http://queue.acm.org/detail.cfm?id=1142065

[thibaut_barrere]

Funny - I had the reverse opinion (having used resque etc) :)