There has been quite a lot of talk about cloud computing lately. When we had the previous MidCOM3 coding sprint we discussed over beer how Midgard2 could fit into the cloud. As replication has been a core Midgard feature since the early days, that was the obvious angle to start looking from.

The way I see Midgard2 in the cloud is the following:

• There are clouds of specialized Midgard2 and MidCOM3 processing nodes that can easily be duplicated. This could be done by setting up an easy Midgard EC2 image for instance
• The processing clouds could act as front-ends by themselves via round-robin DNS, or there could be front-end MidCOM servers that would call the processing nodes via MidCOM3 remote routing (feature that we've discussed but not implemented yet)
• Each processing node would be completely independent and contain its own database
• There would be a replication queue stored on permanent storage service like S3 that each processing node would replicate to and from
• When a processing node would boot up, it would connect to the appropriate S3 bucket and populate itself with data

Implemented this way it would be easy to add or subtract Midgard servers as needed. Each of them would be autonomous from application developer's perspective, but data replication would ensure each node would stay in sync with others.

This would certainly be worth experimenting with. Only things needed would be easy EC2 images, queue handling with S3 buckets, and possibly remote routing support, though the latter wouldn't be needed for simpler services where each Midgard node could contain a copy of all data of the web service. For faster replication of data between nodes, D-Bus update notices could be passed through a message queue service.