[Seaside] re: Enterprise Software V Ecommerce [in smalltalk/seaside/cincom]

[Stephan Eggermont]

I've had a stressfull day, so would you mind if I put this a bit provocative?

The providers of the .NET and java infrastructure are in the business of selling
databases. That is why their programming environments are not updated to 
perform well on modern systems with lots of memory and cores, unlike their
database systems. Garbage collectors and collection libraries are not suitable
for modern machines.

The assumption that all objects are in memory is not very scalable. But Moore's
law makes it more and more scalable. Stevens assumptions are very outdated.
A mid-end database machine now has 48 cores and 512 GB of ram and costs
about 25K (e.g. Dell Poweredge r815). 

If you take a look at the architecture used by Facebook, Twitter etc. for their 
non-analytical systems it is obvious that they are using very inefficient workarounds 
for not being able to work ram-based (memcached). 

If you cannot keep all objects in ram, it might make sense to have placeholders
for large ones. In the Outlook example, keeping the attachments on disk is likely
to solve the space problem. If those placeholders provide enough information for 
searching, sorting  and matching, your only problem is getting the attachments from 
disk fast enough. SSD provides an answer there  (or a NoSQL document store)

Gemstone looks like an obvious match for this. 64 bit support of the other smalltalks
is less well developed. If you need to scale beyond one machine/vm you have to 
think on how to partition your object space. Look for aggregates in the domain driven
design literature. And you might be interested in command-query separation.  
Real scalability of course comes with a p2p architecture instead of a centralized
model. 

The nice thing about building the UI first is that you then know what your architecture
should support. Database first is unlikely to achieve innovative results. And relational
database first is going to lead to lots of duplication because of the bad performance
of relational databases in actually using relations.

Stephan