Cloud Connected

"I have been searching for a product like Cloud CMS for over 10 years.

After false starts with some typical content management solutions, we were finally able to design the content repository that our business required."
James Baddiley
James Baddiley, CEO

CEM - shuffling deck chairs on the titanic

Going back 15 years, we’ve seen the core of providing websites shift across various types of “platforms” - from Web Content Management (WCM) to Enterprise Content Management (ECM) to Customer Experience Management (CEM).  Every iteration involved another set of technologies, and associated migration headaches.

Each expansion also consumed more and more of the resulting presentation tier.  At first, this was mostly a good thing as no standard mechanisms existed to facilitate efforts.  However, in the last few years alone key frameworks have arisen to tackle this job much more effectively, such as:  EmberJS (2007), AngularJS (2009), and Backbone.js (2010).  Suddenly, the templating systems embedded within a CMS platform were not only unnecessary - but were actively getting in the way of good website design - much like a certain iceberg.

Cloud CMS allows you to fly over this barrier with an API-first approach.  No more shuffling deck chairs - sorry Leo.  We’ll take it from here…


With Cloud CMS, you’re free to select any presentation framework and build your customized look-and-feel that focuses on both your content, as well as your customer.  No meddling in the page delivery, no unsupported add-ons, no unnatural or customized CMS configurations - just a pure API driven solution, done right and provided natively.

How we use Docker at Cloud CMS

At Cloud CMS, we use Docker to provision our cloud infrastructure servers on top of Amazon Web Services. Our stack consists of five different clusters:

With the exception of MongoDB, all of these clusters are allocated using elastic load balancing and are architected in such a way that we can spin up new servers and tear down old ones with elastic demand. That is to say, they are fully elastic in design. The product components were all built in such a way so that cache state is fully distributed and requests naturally failover to alternate servers as the configuration changes over time.

Note: MongoDB is deemed an exception to this but it’s no less scalable. It simply has a different architecture. Here, we utilize a MongoDB sharded backend with replica sets. The Cloud CMS primary object identifier (_doc) serves as a shard key to distribute objects evenly across the back end shards.

The DevOps tasks of releasing new product updates, allocating new servers and bouncing users between servers are all very automatic. We made a fundamental design decision early on to be stateless so that server-side session management would not be needed. This means that any server anywhere in the cluster can handle the request. OAuth 2.0 bearer tokens are passed with every request and a distributed object cache helps us to ensure consistent performance benefits without having to reload objects every time.

Docker plays a very key role in all of this. With Docker, we’re able to define the various images that comprise these clusters. Docker build files (Dockerfile) describe all of the software that must be installed, everything from yum (dfn) updates to third party libraries like ImageMagick or FFMpeg. They set up users, lay down permissions and produce an image that is a perfect snapshot of a fresh environment.

Docker then lets us launch these images into a configuration locally. On my laptop, I can spin up a full Cloud CMS infrastructure. Every image forms the basis for one or more containers. With a single command, I am able to launch 10 Docker containers:

  • 2 Cloud CMS API Servers (cluster)
  • 2 Cloud CMS UI Servers (cluster)
  • 2 Cloud CMS App Servers (cluster)
  • 2 Elastic Search Servers (cluster)
  • 2 MongoDB Shards (cluster)

Each of these servers exposes a port binding which is dynamically mapped according to the Docker launch script. It takes a few seconds for these containers to spin up. I can then work against this Cloud CMS infrastructure locally. This is the basis for how we do development and testing.

The other beautiful thing about this approach is that we’re able to deploy the exact same containers to AWS and we’re using locally. Thus, we can test the precise bits that are about to go into production (ahead of them actually going into production). This provides vast assurance that our deployment model is sound. And frankly, it’s one of the reasons that we’re all able to sleep well at night!

In addition, we offer these very same Docker images to our enterprise subscribers. This allows our customers to run Cloud CMS on-premise, either within their own data center or on their own Amazon AWS private cloud. This gives them more control over their backend infrastructure and provides them with more autonomy over their costs and services. It’s running on their hardware and they can make decisions about how much bandwidth, storage or data transfer to throw at it.

Cloud CMS offers support for these customers through a software support model, complete with updated Docker images as they are released. Customers are then free to take new images as they wish and are not beholden to Cloud CMS for product updates and bug fixes on the public infrastructure.

And finally, we offer a standalone Docker image for development purposes. Enterprise customers can distribute this image to their developers so that they can achieve faster iteration and the same fluidity of development that our engineering team enjoys. They can run Cloud CMS locally. They can bring it up, tear it down, start over and iterate as quickly as they’d like to. They can work locally, whether on a plane or in a coffee shop. They run Cloud CMS right on their laptops in a Docker container. No internet access required. No stepping on any else’s toes.

Using the Cloud CMS import/export transfer capabilities, these same developers can then push and pull content against their private or public cloud instances. This is fully distributed content replication and is very similar to GitHub. You work on something locally and you push it to the cloud via a command line tool.

At Cloud CMS, we’re very excited about Docker and appreciate it greatly for all of the DevOps challenges it has solved for us. We spent a lot of time early on experimenting with Chef, Puppet and Ansible only to realize how much faster things are when done with a Docker mindset. So far, we haven’t had to rely on any external tools to manage the construction and assembly of our Docker images. Furthermore, the commitment to Docker within Amazon AWS has been very beneficial. We certainly feel that we’ve picked the right technology to get the job done.

Content Analytics working in Cloud CMS in minutes

I need to confess that I find the Analytics feature in Cloud CMS absolutely amazing. More amazing is the fact you can sign up for a Cloud CMS trial and see the Analytics feature work with the Sample Web Site project with no configuration or programming necessary. Enough of my excitement – I will outline how you can see this feature:

  1. Sign up for a Cloud CMS trial. Login as instructed in the email you will be sent
  2. Select the Sample Web Project. This will take a couple of minutes for the system to create the project and the Sample Web Site
    1. At this point you can look at the CMS components and your hosted Website.
    2. Navigate through Documents to view Cupcakes (Samples->Catalog->Products)
  3. Now - when you look at the hosted website or a preview of the website analytics will be collected real-time. Look at various cupcake pages
    • Preview: Select Product Catalog to view the cupcake site
    • To find the URL to hosted site.
      1. In the left Nav select Applications
      2. Open Sample Web Application
      3. Select Deployments to find the URLs for your hosted site
  4. To view Analytics
    1. in the left Nav select Warehouses (nearly at the bottom of the left nav)
    2. Open Sample Web Project ‘analytics’ warehouse
    3. Open Warehouse
    • Observe the counts of various cupcake pages viewed

What is not included in this demo:

  1. Events: triggering actions based of the analytics collected. For example:
    • Sending an email when certain number of content views
    • Validation that content has been read
    • Automatically, changing where content appears based on the content metrics

This is a fairly simple example of a very powerful feature which hopefully you have been able to see in minutes. I have not seen this type of feature within a Content Management System other than with costly add-on products or search tools.

If you have any questions or comments please email