When we designed Cloud CMS, we wanted to give our customers the choice of running the platform both in the cloud and on-premise. The cloud makes sense for a lot of infrastructure needs but we recognize that some of our customers will want to have their own hosted installation of the platform.
We also wanted to give our customers the ability to push and pull data between their on-premise installations and the cloud platform (whether our public installation or a private cloud the customer runs). There are times where it’s better to take advantage of the elastic storage and capacity of the cloud and other times where data is better suited to live on-premise.
To achieve this, Cloud CMS offers two-way replication. It’s very similar to Git in that you can push and pull changes between your local installation and a cloud installation.
To pull, you browse the cloud and find a resource you would like to pull down into a local copy. You then export that resource into an archive. And then, on your local installation, you simply import the archive via its URL. Your local copy of Cloud CMS will download the archive and seamlessly produce a replication of the data on your local instance.
Archives are stored in vaults and basically comprise a snapshot of the data along with all of its dependencies. Archives are a lot like Maven Artifacts (if you’re familiar with Maven, Ivy, Gradle or other dependency management / build lifecycle tools). They can contain either all of the data of your export or a partial subset depending on whether you’ve bounded the export by date or changeset IDs (in the case of changeset-versioned branches).
You’re free to work locally on your data and if you choose, at any time, you can push your data back to the cloud. It’s basically the same operation but in reverse. You export the archive. And then, you either pull the archive to the cloud from the local installation or you push it from the local installation to the cloud. The former is applicable if your local installation is visible from the cloud (depending on your firewall / IT restrictions). The latter is often more preferable. But in the end, they accomplish the same thing.
Cloud CMS really looks to Git and Mercurial as examples of great versioning systems that really get it right in terms of being distributed, changeset-driven and replication-friendly. We didn’t seek to reinvent the wheel but instead opted to give our customers access to some wonderful tools for collaboration which, prior to Cloud CMS, were only available to command-line developers.