How to support and scale digital experiences – the role for serverless CMS

Digital Marketing and Customer Experience have become very specialised and evolved as fields of study and career paths. Building and managing the digital experiences these teams design usually involves a team of developers creating and maintaining those assets. However, these developers often also have to create the infrastructure that power these experiences. Alongside the front-end digital experience, the back-end also has to be monitored and supported over time.

This all has an overhead for developers as it involves creating and building code and infrastructure, which will need support and updates to maintain relevance and impact. This is problematic when it requires double duty to understand infrastructure and the content that is displayed. Regardless of whether these assets might be simple text or complex digital experiences, they will still need support and upkeep. This can be a big source of overhead for developers, stopping them from focusing on coding and creating.

A content management system, or CMS, can vary from a basic website solution that will handle writing, formatting, and editing of pages through the administration panel of a website through to complex systems that have to serve different content and languages for tens or hundreds of sites. Alongside this, the CMS may also integrate with other functions, such as personalization or other MarTech tools.

One way to overcome this problem around developers supporting complex and disparate infrastructures, is by splitting the front-end systems away from a back-end CMS that provides the content for one or more websites. To implement this decoupled or headless CMS approach, developers will need to think about how it will operate over time, and how it will handle work for other teams. More importantly, they will want to hand over the management side for the infrastructure as well.

Looking at your CMS options from a long-term ROI perspective

Traditional CMS systems deliver the entire website, where the database that stores all the content is integrated with the front-end, where experiences are rendered. While this works, this one-to-one relationship between the data model and the display engine doesn’t scale to meet today’s demands, which may require multiple, sometimes hundreds of websites. Additionally, new devices and display options can more easily be launched outside of a monolithic CMS.

Moving to a headless CMS approach can help as developers can hand the responsibility for managing content over to other teams. Alongside the act of implementing a headless CMS in the first place, there is also the question of how that CMS should run over time. This is where a serverless deployment can be a good option to consider.

From a content perspective, all the data that the site may need over time is stored in the CMS. This can be accessed and consumed using APIs. For developers, using APIs is normally easier and more efficient for them compared to building site infrastructure manually. This approach also makes it easier to build new services or deliver more functionality into the site.

Implementing a headless CMS will involve designing a more thorough data model than a simple website might require. Also, the right deployment method and infrastructure components will need to be considered carefully. To start with, you will have to choose a mature CMS like WordPress or Drupal to integrate with, and where to implement the service. This will normally be in the cloud, as this can offer the scalability and management needed. Alongside this, your sites will have to integrate with a content delivery network (CDN) to speed up delivery of that material to users.

Adopting a serverless approach to this hands over the responsibility for managing that infrastructure over to the service provider. Their service should bring together all the components needed to operate and support the CMS, while the company gets to pay for what they use. For developers, this means they can concentrate on code, with the added benefit that the other teams involved also don’t have to take on the management tasks around the CMS.

Other considerations in migrations

There are other improvements that can be delivered using serverless. For example, any online service or site today has to have strong security. Moving to a headless CMS is no exception – this can increase your potential attack surface as you will have more moving parts to consider. Each component will have to be hardened before being moved online, and then kept up to date and secure over time. Platforms like WordPress are commonly targeted because they are so popular, so new issues are found over time.

For teams that have adopted DevSecOps principles, this should be an easier transition to make, as developers, IT operations teams and security are used to collaborating around common goals. However, for Website Operations, the responsibilities can be harder to lock down. When it comes to sites and software, developers can be held responsible for operating the whole site when this is not their usual remit. Similarly, non-technical teams like marketing can be held responsible by the business when they are either not well-versed in security, or don’t understand the necessary work involved.

Looking at Website Operations (or WebOps) can help in this process. Similar to DevOps, it is about making it easier to collaborate around projects that cross over between business and technology goals, in this case around site design, development and infrastructure. By getting teams to collaborate and understand the wider goals, each team can ensure they are fulfilling their part of the goal. At the same time, this can support more migration projects that simplify the overall process. As part of moving to a new CMS, developers can migrate things off their plates and then concentrate on where they can produce the best software and digital services.

Alongside this, using a WebOps approach can ensure that security teams are consulted and understand what is going on around any deployment. For example, if your organisation does not have expertise in hardening Drupal or WordPress instances, then handing this over to teams that do this all the time can help developers be more efficient and the security team to see that all the necessary steps are in place.

Using serverless CMS should ensure that developers can concentrate on what they are there to do – write code. It can remove the burden of running back-end infrastructure and let other teams manage the content that is put in place. It also provides a focal point for wider changes around the processes and requirements that take place around these projects, and can support wider WebOps adoption.

Rather than issues falling between different groups and becoming contentious, or being loaded on the developers because they are automatically assumed to be responsible, this approach can make these problems more understandable, and put the responsibility for changes where it should be. When you think about it this way, this infrastructure change can lead to more opportunities to improve everyone’s interaction, understanding and results.

The post How to support and scale digital experiences – the role for serverless CMS appeared first on JAXenter.