On this page:
At a glance
Overview
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 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 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:
- Planning and costings — to fully scope and cost the project
- Migration preparation
- Cluster provisioning
- Migration
- Post-migration tasks
Salsa worked with (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 (Finance) owns the GovCMS , 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).