At a glance

4 to 6 months
GovCMS, Drupal, LAGOON
Federal government
Hosting & maintenance, Support & optimisation, Technical advisory
GovTech, Whole of government, Open source, Web development, Open platform, Content management systems
Multidisciplinary teams, Agile delivery, Tools & systems, Security, Open standards & common platforms, Open source, Measure performance


GovCMS’s challenge

With production and development websites on one cluster, production sites’ performance could sometimes be affected by high activity and load on development websites. In addition, the platform’s ability to scale down (and save money) wasn’t being maximised.

GovCMS’s transformation

Salsa worked with amazee.ioExternal Link to create two separate clusters — production and non-production (or development). Now all GovCMS production sites are on a separate cluster to development sites.

The outcomes

  • Improved reliability and performance of live/production websites
  • Cost savings through scaling down the non-production cluster when it’s not being used — especially at weekends and after business hours during the week

Full case study

GovCMS’s challenge — competing workloads

When originally designing GovCMS 2.0, Salsa and our partner amazee.ioExternal Link set up a scalable architecture. This meant when demand was low, some servers could be scaled down or idled, which ultimately reduces costs. However, with both production and development sites running on one cluster the ability to significantly scale down was limited. In addition, if development sites were very active, sometimes the performance on production sites could be impacted. In computer science we call this the ‘noisy neighbour’ effect. If neighbours are taking up a lot of bandwidth (creating noise), this impacts you (your site).

Splitting the platform architecture into two separate clusters — production and non-production — would provide many benefits.

GovCMS’s transformation — separate clusters

After we worked on migrating GovCMS from OpenShift to AWS EKS, we took the opportunity to separate out the clusters into a production cluster and a non-production cluster.

The work was broken into 5 main stages:

  1. Planning and costings — to fully scope and cost the project
  2. Migration preparation
  3. Cluster provisioning
  4. Migration
  5. Post-migration tasks

Salsa worked with amazee.ioExternal Link (our platform partners) to complete the cluster optimisation and to ensure sites were cleaned-up or migrated with little or no impact on end-users.

Non-production sites were not migrated, unless agencies specifically wanted these sites to come across. Despite the two dedicated clusters all sites were migrated to the new production cluster. Non-production workloads are typically ephemeral branch environments and are deleted when merged. Through the normal development process, the migrated non-production environments will be deleted from the production cluster.

New dev environments are created in the non-production cluster.

The outcomes — a better platform

  • More predictability and consistency in the workloads in the production cluster so we can tune the resources better (one benefit of that is improved performance)

  • Improved performance of live government websites (due to the workload changes in the production cluster)

  • Dedicated development cluster that can be scaled-down or idled when not in use, delivering cost savings

About GovCMS

The Department of FinanceExternal Link (Finance) owns the GovCMS platformExternal Link , a whole-of-government digital platform for use across all levels of government in Australia. GovCMS is built on Drupal, an award-winning, enterprise-grade CMS that’s easy to use, stable, highly secure and open source (no license fees).