CASE STUDY · INFRASTRUCTURE
Stabilising infrastructure without simply adding more power
A high-traffic editorial website was experiencing stability issues on infrastructure where WordPress, PHP and the database all shared the same machine.
PLATEFORMS was brought in to understand the causes, redesign the architecture and take responsibility for its ongoing operations.
- SECTOR
- Media · Editorial website
- CONTEXT
- High-traffic WordPress
- OUR INVOLVEMENT
- Infrastructure · Monitoring · Operations
- ENGAGEMENT
- Long-term operations
A public front end decoupled from the back office
The public front end, developed in Next.js by BearStudio and hosted on Clever Cloud, is decoupled from the WordPress environment used by the editorial teams. PLATEFORMS is responsible for the back-office infrastructure, databases, monitoring and ongoing operations.
- BearStudio
- Development of the public Next.js front end
- Clever Cloud
- Hosting of the public front end
- PLATEFORMS
- WordPress and data infrastructure, monitoring and operations
Rethinking how responsibilities are separated
- WordPress + PHP + database
On a single large machine
- Shared resources
- Difficult to isolate saturation
- Limited visibility
- WordPress / PHP
- MariaDB primary / replica
- Monitoring
Separated responsibilities
- Resources matched to each component
- Better visibility
Understand before rebuilding
The editorial team was particularly affected by the instability: several editors could no longer work properly at the same time. The client had access to the server, but lacked the visibility, analysis and support needed to understand what was happening.
The work began with a meeting between the client, BearStudio and PLATEFORMS. We assessed the infrastructure, examined the issues and how the platform was being used, then produced an initial assessment report. The architecture that emerged from this analysis was discussed and validated with the client and BearStudio.
The objective was not to systematically replace what already existed or add more power to hide the underlying problems. The assessment led to a new architecture that separated responsibilities more effectively and allocated resources where they were actually needed.
Separate responsibilities to gain control
On the original machine, WordPress, PHP and the database all shared the same resources. With the level of traffic and the existing configuration, these components could interfere with one another.
The new architecture allocates dedicated resources to PHP and WordPress. The data layer uses MariaDB in a primary / replica configuration to separate read and write workloads more effectively. Monitoring also has its own dedicated component.
CPU and memory are sized according to actual requirements. This separation makes it easier to isolate problems and provides usable metrics and logs.
The objective was not to multiply servers. It was to prevent a local problem from affecting the entire platform so easily.
Migrating without interrupting readers
The old and new infrastructure were able to run alongside each other. A migration rehearsal was carried out to prepare for the actual cutover.
During the migration, the public Next.js front end remained available to readers thanks to its decoupled architecture and caching mechanism. The disruption mainly affected the editorial team: approximately two hours were required to migrate the data and switch the platform over.
The migration was completed without any particular incident.
Moving from reaction to anticipation
Metrics, logs, alerts and usable monitoring now provide visibility into how the platform is behaving. The client also has access to the monitoring environment: observability is not a black box reserved for PLATEFORMS.
Disk-space monitoring has already identified storage consumption related to WordPress or backups before a full filesystem could cause an incident.
Seeing what is happening makes it possible to act before the user discovers the problem.
Stability restored under current operating conditions
Since the migration, the infrastructure has remained stable under its current operating conditions.
- The saturation issues previously encountered are no longer observed under current operating conditions.
- Multiple editors can once again work in WordPress at the same time.
- Monitoring alerts PLATEFORMS when an issue occurs.
- Some problems have already been anticipated through monitoring.
Maintain, secure and evolve
PLATEFORMS continues to manage the hypervisor, virtual machines, databases, required updates and backups. Monitoring, log and incident analysis, and ongoing changes are all part of operating the environment over the long term.
The nature of the need has changed: the focus is now on maintaining, securing and evolving a platform that works, following the recurring stability issues experienced in the past.
The client has access to someone who knows their environment and can discuss issues with them when a need arises. The relationship therefore goes beyond one primarily limited to tracking support tickets.
Reliable infrastructure is not only about machines. It also depends on being able to understand what is happening and act when necessary.
What changed day to day
Before
- WordPress, PHP and the database concentrated on a single large machine
- Saturation and instability
- Multiple editors struggled to work simultaneously
- Limited usable visibility into problems
- Intervention mainly after problems became apparent
- Support primarily through tickets
Today
- Separated responsibilities with resources matched to each component
- No saturation currently observed under existing operating conditions
- Editors can work in parallel again
- Metrics, logs and alerts available
- Monitoring also helps anticipate some incidents
- Direct communication with a partner who knows the environment