Question

Seaside is known as “the heretical web framework”. One of the points that make it heretical is that it has much shared state. That however is something which, in my current understanding, hinders easy scaling.

Ruby on rails on the other hand shares as less state as possible. It has been known to scale pretty well, even if it is dog slow compared to modern smalltalk vms. flickr uses php and has scaled to an extremly big infrastructure…

So has anybody some experience in the scaling of Seaside?

Answer 1

Short answer:
you can scale Seaside applications like hell yah

Long answer:
In the IT domain, scaling is one thing but it has two dimensions:

1. horozontal
2. vertical

Almost everybody thought about scaling in the vertical dimension. That was until intel and friends reached some physical barriers and started to add cores to compensate the current impossibility of adding MHz.

That’s when all we started to be more aware of scaling horizontally as the way to go.

Why am I telling you this?

Because Seaside is a smalltalk image running in a VM and that is roughly the same situation of a system in a server of a monocore processor.

Taking that as foundation, you scale web apps by making a cluster of servers. It’s the natural thing to do, it’s the fault tolerant thing to do, is the topologically intelligent thing to do, is the flexible thing to do, I guess you get the idea…

So, if for scaling, you do the same as intel & friends, you embrace the horizontal way. And it’s even cheaper that the vertical way (that will lead you to IBM and Sun servers that are as good as expensive).

RoR applications are typically scaled horizontally. Google has countless cheap servers to do their thing. It works perfectly fine no matter how dramatized people want’s to impress you throwing at you a bunch of forgettable twitter whales.

If they talk to you about that, you just be polite and hear what they say but remember this:

1. perfect is the enemy of the good
2. the unfinished perfect will never be as value as the good thing done

BTW, Amazon does something like that too (and it kind of couple geolocation so they enhance the chances of attending your requests with the cluster that is closest to your location).

On the other hand, the way Avi scaled dabbledb (Seaside based web application company bought by twitter) was using one vm per customer account (starting up and shutting down those on demand).

Having a lot of state in an image doesn’t make scaling impossible nor complicated.

Just different.

The way to go is with a load balancer that uses sticky sessions so you can have one image attenting all the requests of an user session. You make things so any worker-image behind the load balancer can attend any user of a given app. And that’s pretty much it.

To be able to do that you need to share the persistent objects among workers. All the users databases needs to be accessible by the workers at anytime and need to deal well with concurrency.

We designed airflowing scalable in that way.

It’s economically convenient too because you can start with N very small (depending on the RAM of your first server) and increase it on demand until you reach the hardware limit.

Once you reach the hardware limit, you just add another host to the cluster and recofigure the balancer (and the access to the databases).

Simple, economic and elegant.