Partner Login Customer Login

Content & Commerce

5 Reasons Why a Cyclops Can't Be a Hydra

June 20th, 2019

By John Williams, CTO, Amplience

If you look at the multi-headed beast that is today’s user experience you can see why the headless backend works so well. If you get it right, you can build as many UX heads as you wish with a constant set of features and content delivered neatly through APIs. The heads can be built using lightweight JavaScript frameworks like React, Vue and Angular for web based experience, as well as iOS, Android or any other UX technologies (such as voice). What I mean to be a truly headless system is a multi-tenanted cloud based system that delivers all its functionality through web based APIs.

JW-Hydra-CyclopsBlog-1

How can you tell if the software you are looking as is a modern headless system? They all have the same key attributes:

Complete API coverage - The ability to do everything (and I mean everything) using an API. If a feature is only available in the UI, via a support ticket or by writing custom code, the platform is not API first. This is fundamental for delivering a consistent user experience across all your touchpoints and avoiding creating silos. (watch out for the statement ‘API first not API only’. This is a meaningless phrase used to excuse full API coverage)

Multi-tenanted Cloud - This is where everyone is on a single version of the platform in the cloud. None of that nonsense of dedicated server instances (single tenanted), choosing a version to start on and expensive upgrade projects to move to later versions. True multi-tenanted platforms address head-on the scale required to run every one of its customers across a globally distributed system. (A dedicated instance is a massive warning label, a cyclops in the cloud is still a monolith).

Scale - The latest multi tenanted headless cloud systems are designed from the ground up as a set of APIs for thousands of tenants. They are designed to accommodate industry peaks, provide automatic scaling on demand and support the continual growth of businesses on the platform. They often come with superior reliability with robust SLAs (99.99% SLA) and better security as a result.

Continuous upgrades - Through the implementation of practices like Continuous Integration and DevOps processes, a Headless provider should be able to provide you with a constant stream of improvements and additional functionality. All of this should without requiring any development and with no down time (we did 152 releases last year and this required no downtime). Imagine, one day you log in and a whole new set of workflow options appear, or new scheduling functionality.

Developer Freedom – So after dealing with a monolithic cyclops for several years you at last get a modern new headless system. You can choose the language / framework you want to use and are not forced into using proprietary technologies that no one else on the planet uses. If this is not the case, then it’s a Cyclops imitating a headless system

But surely these five attributes can be dealt with using an existing system like a traditional Web CMS that has had decades of development? Surely, they can cut off the head and add some APIs, and surely they can mutate from a cyclops to a hydra? At first glance it seems possible and many of the old web CMS vendors are using the term ‘Hybrid’ to refer to a ‘best of both worlds’ solution. But care should be taken when assessing these Frankenstein solutions. Let’s unpick some of the details:

  1. Complete API coverage – The good old monolith has spent decades building all sorts of features into their Web CMS in an effort to keep adding value. In some cases, they have added a form of personalization, AB testing and Search. Some have even tried building baskets and commerce functionality as they ran out of steam and imagination. The problem is, it’s based on the architecture of yesterday for the delivery HTML and this is not easily retrofitted into APIs. Therefore, they don’t have a chance of complete API coverage. Basically this is where the marketing terms ‘head optional’ and ‘Hybrid’ come from, in a struggle to be relevant the web experience driven platforms can only provide degraded functionality in ‘headless modes’- a major problem for delivering slick consistent user experiences across touchpoints such as native Apps and Voice. The fact that WYSIWYG is touted as a benefit of the ‘Hybrid’ solution, as it uses the old HTML templates for preview, completely amazes me as it is irrelevant when it comes to real headless scenarios such as Apps and voice.
  2. Multi tenanted – this is the biggest blocker that most postmodern architectures face, because most were built with every feature and function hardwired together through multiple layers with zero separation. This makes it impossible to unravel the features of the platform into discrete service elements that can be organised and secured against an account/user base. Suppliers therefore struggle to scale, develop and manage everything independently leaving no choice except for single tenant managed systems.
  3. Scale – Monoliths can only scale by replication using containerization (e.g. kubernetes) leading to a managed service environment. The fact that monoliths struggle to grow beyond a single application server forces the implementation to become complex with weird hacks, patches and complex caches. Combine this with incomplete API coverage requiring customization per account and you now have a whole host of difficult to scale and maintain silos. This is the reason why many older generation web CMS sell managed services disguised as a headless cloud.
  4. Continuous Upgrades - The whole system is deployed as a whole system which does not fit well with today’s DevOps Continuous Integration (CI) approach and doesn’t provide the benefit of continuous upgrades and features. Some of the worst offenders require their customers to do the DevOps as they must be customized to be fit for purpose. This means you need a mature IT organisation and will no doubt require system downtime
  5. Staging and preview – this is where the rubber hit the road in the innovation stake of headless. How do you provide an experience for business users that need visual feedback to really understand what they are delivering to the end user when there is no specific presentation layer? This was easy for the monolithic cyclops when there was one web view of the world as the presentation wired directly into the system made sense, but now you need to consider staging and visualization in any UI(Native App, Voice, IoT). This needs new thinking-, such as providing staging as an API – no more hell with syncing environments.

In conclusion if your customer experience is evolving into a hydra with an ever increasing number of heads supporting your experience across a variety of channels, devices and apps, you need to consider moving towards the headless architecture approach. But be very careful that you are not implementing a monolithic cyclops that is pretending to be a Hydra. Later I will discuss how to strangle a Cyclops Architecture and grow your own Hydra User Experience. See my last article.

Back to top

Request a Demo

ic-body-success
e-mail

contact@amplience.com

ic-body-success
United States

Call toll free 866 623 5705
or +1 917 410 7189

ic-body-success
Europe

Call +44 (0)207 426 9990

Contact Us

Developer Edition