A migration with room to rethink the system
The previous shop ran on a custom Linux setup with Nginx, MySQL, web servers, and Zabbix monitoring. The application upgrade and move to GCP happened together. That let me reconsider how the application was built, deployed, and operated, rather than simply relocating the old servers.
I chose a managed instance group for the web servers, Cloud SQL for MySQL, and Memorystore for Redis. Cloudflare sits in front of the shop with its WAF and bot detection. These are recognizable pieces, which matters when you are the person responsible for the infrastructure and the rest of the team needs to understand how a release reaches customers.
I did not add Kubernetes. For this shop, it would have introduced another system to operate without solving the problem I was facing: keeping deployments predictable and the storefront responsive within the budget. Terraform defines the infrastructure. Packer builds the Debian images, with GitHub Actions triggering those builds. A deployment service and custom Bash scripts handle application releases. I designed that path for zero-downtime code deployments; the team now deploys multiple times a day. I do not develop the PrestaShop application itself.
Keep background work away from customers
A shop does more than serve pages. Rebuilding a sitemap can take a long time. Pricing and stock changes can arrive in bursts through Kafka. If those jobs compete with customer requests on the same web servers, a healthy deployment pipeline does not help much: the shop can still slow down at the wrong moment.
I moved that work onto separate servers so that long-running jobs and event floods do not consume the capacity reserved for the storefront. The events come through Confluent Cloud, running publicly in the same GCP region as the shop. There is also a private connection to the retailer's parent company; that is a separate part of the infrastructure.
Caching needed the same kind of care. Cloudflare's Smart Tiered Caching and region hints give bots arriving from around the world a better chance of receiving an already cached asset instead of missing the cache at a closer edge location. It is one way to avoid spending origin capacity on repeated requests while keeping the storefront responsive to customers.
Product search runs on Elastic Cloud, connected privately to GCP through Private Service Connect in the same region. I keep a close view of the whole path: Apache and Google load balancer logs in Cloud Logging, the Ops Agent on the servers, Grafana and Prometheus for metrics, and Tideways when I need to understand PHP performance. Those tools help me see whether a problem begins at the edge, in the application, or in a background process.
The result is an operating model
The platform has reached near 99.995% uptime, while supporting multiple code deployments daily. Those numbers matter, but the more useful result for the team is that changes can be made routinely and investigated when something behaves differently than expected.
I still maintain the infrastructure and consider myself part of the team. The architecture is not finished in the sense of being left alone. It gives us a way to keep the shop fast, to absorb work that should not interrupt customers, and to make the next change without turning it into a special event.