Rapid, available and scalable

[ErikDeBruijn]

This is a "meta issue" where we can reference other issues that are concerned with high-availability and scalability.

The following is based on this Google+ Hangout and the discussion following it.

The Hand-o-Matic should be available independent of individual spikes in usage and individual server problems. Performance should degrade gracefully and be compensated by adding more hardware, but this should require minimal human intervention and be kept in balance with the load/demand at the time.

• [ ] Devise a protocol for back-end and front-end nodes
• [ ] Separate the back-end processing "install package" and the front-end "install package" that serve customer requests (if both installed on the same machine, they should still work together well)
• [ ] YMMI: Create a processing job routing system
  • [ ] YMMI: Determine availability and server load of processing nodes
  • [ ] YMMI: Node discovery

I propose to just start developing basic "0.1" versions of each sub project and keep this preliminary architecture in mind.

[laird]

There's now a web service layer between the front-end and the back end, with one service for 'preview' and another service for 'render'.

This allows the front-end and back-end to be scaled independently, load balanced, etc.

The front-end is installed as Service Station, and the back end as e-NABLE Assembler.

Note, however, that the web services are included in the Service Station repository, rather than the Assembler repository. They should probably be moved.

[ErikDeBruijn]

@laird that's great. I agree it makes more sense to have them in the Assembler repo.