Cloud Connected



"The only difference between Cloud CMS and your current on-premise document repository is that you don't have to worry about software or hardware installation and upgrades any longer."
Jeff Potts, Founder
Metaversant Group

The best way to enable content authoring with your JS framework

Now that you’ve built that beautiful application in Angular, Aurelia, Ember, React - or the next big JavaScript framework - how do make your content authors happy?  Easy:  Think Headless.

image

Never let a CMS dictate your presentation tier options.  The field is too crowded and is changing too rapidly for pre-ordained “templates” to suffice.  Instead, crank out that prototype in your desired framework(s) and

  • utilise REST calls to query content
    • a simple mockup will do
  • returning JSON for each node

Then go back and splice in actual CMS REST calls after-the-fact.  Or better yet, checkout their SDK.

Any API first, or headless, content management system worth its salt will dovetail nicely into such a process.  You get to spin up your MVP quickly, and look like a hero when authors can revise their items with ease.

Content Management as a Microservice

One of the big ideas we pursued when we set out to build Cloud CMS was to design the product so that it was entirely decoupled. Our vision was to have a number of discrete tiers that would consist of either single servers or clusters of servers dedicated to a single class of problems.

For example, the Content API tier is dedicated to powering our JSON API. It does nothing else but receive requests, execute them and hand back JSON data responses. It had nothing to do with presentation or rendering of content for consumption.

On the other hand, our Application Server tier does nothing but take that JSON data and convert it into a format desired by the web site or mobile app. It might be HTML but it also might be alternative JSON, XML or binary formats.

There are several other tiers as well, including a DB tier, a Search Index tier, a tier for messaging, a tier for Job Queue management and tiers for Job executors for long running tasks like statistics map/reduce and even web page screenshot capture.

By separating things into different tiers, we created more work for ourselves initially, but we believed this would allow Cloud CMS to be more extensible and more testable from a deployment perspective. We also believed that it would enable the platform as a whole to perform better and in a more elastic fashion where individual tiers could scale out as demand grew.

For our customers, this meant consistent, steady performance on modern cloud platforms (like AWS). Pricing would not only be lower (since capacity of machines per tier would scale down with lower demand) but it would also be as close to a utility model as you could achieve (in terms of paying only for what you use).

The Arrival of Docker

What we didn’t anticipate, however, was the proliferation of container technologies circa 2013 and specifically the arrival of Docker. Docker provided Cloud CMS with a way to package up our tiers into services that could easily be deployed in all kinds of interesting configurations. It greatly reduced the heavy Dev/Ops and IT cycle involved with running a cloud infrastructure service.

With Docker, we suddenly found ourselves in a position where our customers could not only run Cloud CMS in a hosted capacity, but they could also run Cloud CMS on their own. They could run it on-premise, in their own data centers, and even on their own laptops.

Docker allowed us to express our tiers as services that could be launched into containers. Docker then allocates these containers (Docker Swarm) onto a single host or many different hosts (EC2 instances) on the fly.

Furthermore, the elastic architecture of Cloud CMS means that new containers can come online at any time and join the pack. Others can come offline at any time. It’s self-healing and largely automated.

Cloud CMS and Microservices

In bundling our tiers into container images, we realized that we had gone a long way toward packaging Cloud CMS up as a set of microservices. While “microservices” is an abstract description of “small autonomous services that work together, modeled around a business domain”, Docker turns this into a reality by providing a way to package service code and automate its testing and deployment.

This automation of testing and deployment is the critical piece. Once the descriptor files are in place to describe the deployment, Docker handles the instantiation of containers as well as the allocation of those containers onto hosts (EC2 instances). It solves for the software installation and configuration task, but it also tackles the far more complex Dev/Ops challenges of network configuration, port binding, volume mounting, log collection, fail case handling and more.

For us, this makes it easier for us to manage and deliver Cloud CMS as a Software as a Service offering. However, it also opens up a world of possibilities for our customers.

It makes it possible for our customers to drop Cloud CMS into their applications. Not as a remote API service, but as an integrated, low latency, same subnet and possibly in-process module. Their application may pull in many microservices this way, each deployed as a container, including perhaps:

  • Shipping API
  • Order Processing API
  • Inventory Management API
  • Invoicing API

If our customers need a Content Management API, they just drop in Cloud CMS and away they go.

Conclusion

At Cloud CMS, we’re seeing more customers transition to running Cloud CMS as a microservice. Docker puts the power of the cloud into the hands of the customer. The implication of this to traditional SaaS companies is very interesting.

While SaaS companies will continue for some time to provide real value in terms of hosting their offerings and handling all of the Dev/Ops tasks associated with running the underlying infrastructure (along with data migrations, upgrades and support), we expect to see customers pull more of this on-premise and handle their own infrastructure management tasks themselves.

Docker and other container technology companies make this easier and lower cost than ever before. This shift in customer preference may shift many traditional SaaS companies into offering a more conventional on-premise support model. We’ve certainly found this to be the case at Cloud CMS.

Return On Investment (ROI) with Cloud CMS

ROI and Content Management Systems (CMS) are rarely used in the same sentence due to the uncomfortable pricing models from all legacy CMS vendors - as well as the spiraling costs of implementing them. Often so much investment has been made in the CMS that changing is not a realistic consideration.

This negativity only increases when you start using the term Enterprise Content Management (ECM), where suddenly vendors start seeing dollar signs, but offer no additional functionality e.g., Alfresco, Documentum, Adobe CQ5, and many more. Rather, creative “Per User” or “Per CPU” pricing makes selling to the Enterprise very attractive to vendors.

At Cloud CMS we strive to provide exceptional value with a CMS which will meet your current and future needs. The benefits of the Cloud CMS approach can be realized in many ways but occasionally you need to have a “SHOW ME THE MONEY!” conversation.

Some potential ways to realize your ROI with Cloud CMS:

Freedom

We adhere to an API First, or “headless” approach to content management. This means all content and CMS functionality is available via our 1,300+ APIs. Every UI, including our packaged console, uses these APIs. Create and manage content thru our console, and call the APIs to access any content on your frontend applications. This provides greater freedom rather than being limited to a CMS vendor’s templating options.

Future Proofing

  1. Reuse: Through the separation of the CMS and the presentation layer you can create amazing websites and application with the frontend technology of your choice. Whenever you need to refresh or redesign the presentation layer, the CMS and content can be reused in-place. Minimizing the changes and maximizing reuse is huge benefit to any project from the technical, marketing, and business perspectives.
  2. Multi-channel/Device: three possibilities for cost savings:
    1. One CMS, creating content which can be deployed anywhere as needed
    2. What are your future device and application requirements? What devices are coming up in the next 6 months+? The frontend costs are maybe unknown but you can limit the risk and costs by using a CMS that provide the Content via APIs. No change to the CMS
    3. Reduce Time To Market: having the content available in a Headless CMS allows for an organisation to respond to changes and the requirements for new devices and channels.

Software as a Service

  1. SaaS CMS services can convert expensive capital outlay for servers and network equipment into a monthly operating expense, while also reducing the IT resources required to manage enterprise records. http://en.wikipedia.org/wiki/Enterprise_content_management
  2. Scalable: Cloud CMS scales seamlessly to meet your needs. Again, no upfront costs.
  3. Always on latest version: Cloud CMS continues to grow with new and enhanced features, performance, bug resolution. No need to wait and plan large upgrade projects.

Feature rich

Cloud CMS is a lot more than a well architected repository and API. Jeff Potts summarized this nicely in his blog Content-as-a-Service Review: Cloud CMS: “..Cloud CMS is an extensible platform with a long list of features. This is more than just a place to stick content and an API to get it back out–this is a full-featured CMS that happens to be running as SaaS in the cloud. ..”

Flexibility - Fits with your infrastructure

  1. Application development and delivery teams at publishing organizations, media companies, and branded manufacturers already use API First CMS tools alongside multiple other sets of API-first micro-services to build out new digital products.
  2. Flexible Deployment Options (https://www.cloudcms.com/developers.html ): whether SaaS or On-Premise, direct API, custom Application server, or using our NodeJS module.


At Cloud CMS we have a straight forward honest approach. We care about what we do and how we do it. We are essentially engineers that want to create the “right” solutions and see our customers get value from their CMS. Needless to say we are proud of what we deliver.

If you have any questions or comments please email info@cloudcms.com