Cloud Connected

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.

Cloud CMS Web and Mobile Forms

One of the things that Cloud CMS does really well is forms - specifically, web and mobile forms.

If you’ve ever worked with the development of forms before, you know they’re pretty tricky to put together. You typically have back-end code that is responsible for taking a data structure, validating it and writing it to a database. And you also have front-end code which does user-facing data validation that is cosmetically appealing (pretty red boxes) and helpful. You need to think about customizing the front-end controls (using JavaScript typically) to offer a compelling end-user experience while also offering an intuitive layout. Form elements need to interact together such that changes to one part of a form automatically update or validate with other parts of the form.

It gets more interesting as the requirements grow. For example, you may be asked to have your form work across multiple pages. Perhaps there is a need for a wizard with previous, next and submit buttons. Or perhaps there is conditional logic such that certain sections of a form only appear if a user selects something. Or perhaps the next button should take you to a different set of pages depending on your form’s data (such as having to fill out certain income schedules for a tax payment submission).

And across all of that, there is the question of validation and making the user interface intuitive to end users as data changes. End users should be informed of when they are allowed to proceed to the next step in a form and be shown what updates are required or how they can fix things.

All of this is usually very challenging to deliver, particularly since it requires so much front-end and back-end code that needs to be kept in sync. As such, it has been a hard problem to generalize until very recently.

In the past few years, we’ve seen some new innovations that have made this easier.

One of these innovations is JSON schema which provides a descriptive way to structure your content. You can use JSON Schema to express forms, their data attributes and how they should be validated. With JSON Schema, you can singularly describe the constraints and validation logic of your form and then have that validation run on both the client and server side. You just write it once and it applies in both places.

Other technical innovations include modularized JavaScript and JSON document databases. Modularized JavaScript and other improvements to JavaScript (including EcmaScript 5 and the pending EcmaScript 6) allow for flexible development of intelligent controls that run in the browser. This effectively allows the browser to be much more intelligent about it’s rendering and enables it to make late decisions about how to lay out the controls onto the page or bind them into wizards. This process can be driven entirely from configuration (also a JSON document) while still allowing for JS controllers and methods (packaged up into AMD modules).

Using HTML injection to build user interfaces or forms has really grown up in the world. Popular frameworks like Angular.js or Ember.js work this way. Instead of generating HTML on the back-end and passing it over to be shown in the browser, the front-end generates its own HTML using JSON data retrieved from the back-end. This allows for really beautiful user interfaces that are customized on-the-fly, per user and per device.

Cloud CMS builds on all of this to deliver really intuitive and easy web and mobile forms. We provide an open-source, JavaScript-based Cloud Forms engine that runs entirely on JSON Schema. It builds forms for you on-the-fly, using a configuration-driven approach. And it saves your form data right into Cloud CMS so that you can collaborate around it, report on it and leverage it within your business.

Several years ago, we decided to open-source our forms engine under the Apache 2.0 license so that anyone could use it within their projects. No strings attached and no funny stuff. We’re big believers in open-source. It’s not just that we want to give back, but we also believe that the open-source process is the best way to build a fantastic product.

The result was Alpaca Forms. We put a web site up and promoted releases, along with documentation, examples and community forums. The result has been amazing! We’ve watched as Alpaca has been used in all sorts of interesting projects, ranging from education and government to the entertainment and medical worlds. We’re so glad that it has helped people to deliver amazing applications!

And beyond that, we’ve really enjoyed working with the community. Such great people with interesting ideas and lots of feedback. We’ve greatly enjoyed being in touch with such a great community!

Cloud CMS continues to build and offer Cloud CMS Forms as part of its offering. Each Cloud CMS subscription comes with a fully-engaged content management system that naturally works with Alpaca’s web forms. We offer technical support, bug fixes and production-level SLA’s for Alpaca within live applications.

If you’d like to learn more about Cloud CMS forms, visit our web site or Sign up for a Free Trial.

Thanks for being part of our community!

Getting Started Videos for Cloud CMS

We are very proud of Cloud CMS and encourage you to see for yourself the potential of Cloud CMS (Free Trial).

To help you get the most out of the trial and knowledge of some of the features, we have recorded a number of ‘Getting Started’ videos showing some basic features, administration, and a ‘taster’ of some of the more interesting advanced features. (More videos to come for the advanced features).

The Getting Started videos:

  1. Create a Project
  2. Add Users to Projects
  3. Upload Content
  4. Add Comments to your Content
  5. Tag your Content
  6. Search for Content
  7. Print Documents

Content model and Forms, Export

  1. Define your own content Types
  2. Create Forms
  3. Export to CSV, PDF, or ZIP
  4. Export with PDF Templates

Administrative Functions

  1. Define your own Roles
  2. Configure an Email Provider
  3. Customize your Theme
  4. Administration Console

There are so many features in Cloud CMS that you may be interested in. We have made a start with these videos and we are planning to do more. Did you find these videos useful? If there is a specific feature or Use Case you would like to see please let us know Contact Us