VfL Wolfsburg plays digitally in the Champions League - with support from Claranet
Summary:
Challenge: Migration and hosting of the VfL webshop based on Shopware
Solution: AWS cloud environment with cloud-native scaling mechanisms
Result: Modern, digital shopping and club experience for VfL fans
Digital club world for fans
Football is considered one of the drivers of digital communication. More and more fans are also engaging with their team in the digital world - both before and after the game as well as during the match. It is therefore important for clubs to create attractive digital worlds of experience where fans can find information, be entertained and easily buy tickets and merchandise. VfL Wolfsburg wanted to fundamentally overhaul its online presence in order to create a consistent digital fan world for its fans.
First digitalisation offensive
Claranet supported VfL Wolfsburg in 2019 with the launch of the new webshop based on Shopware. Like the TYPO3-based corporate website, a live ticker, a fan app and a VIP app, this was operated in a secure, high-performance Claranet system environment that can also withstand peak loads, such as during sales phases for top match tickets.
Cloud-only strategy
The conceptual strength and extensive experience also made Claranet the partner of choice for the Bundesliga football club for the planned switch to the cloud.
Following strategic advice from Claranet, VfL favoured a public cloud environment from Amazon Web Services. The infrastructure setup designed by Claranet and the provision of managed services are carried out in two AWS accounts of VfL Wolfsburg.
A distributed, fail-safe setup of the productive environment across several availability zones ensures a high degree of flexibility, scalability and performance.
In order to protect the systems from unauthorised access and cyber attacks, Claranet implemented the entire infrastructure in accordance with the best practices of the AWS Well Architected Framework: A virtual private cloud (VPC) network is set up in each of the two AWS accounts. This means that all applications in production and all applications in the test environment are based on a separate VPC.
Claranet had already impressed us both conceptually and operationally in 2019 with the operation of our then new website and online shop. We were therefore confident that Claranet would also develop a clean migration strategy for this project and realise a smooth move."
Cloud-native approach
Two different architectures are used to provide the various services: Shopware and TYPO3 are provided as a classic architecture based on EC2 instances and autoscaling groups. The Fan app and VIP app were realised as a container architecture based on ECS (Elastic Container Service) and ECR (Elastic Container Registry).
In addition, Claranet implements a fully automated continuous deployment process by using cloud-native deployment tools such as CodeCommit, CodeBuild and CodePipeline.
In order to withstand peak loads more cost-effectively, cloud-native scaling mechanisms such as autoscaling groups are used, which enable the flexible and temporarily limited connection of additional computer resources in the form of EC2 instances.
Safe migration
For a transitional period, the services were operated in parallel in the existing infrastructure at Claranet and in the AWS cloud in order to initially test the cloud environment extensively under live conditions.
Claranet then took over the operation of the services in the AWS cloud environment, secured by potential rollback scenarios, which were not used, however. The migration went smoothly after a project duration of two months.
"A load test showed that the AWS cloud platform set up can easily withstand the announced target of 2,000 simultaneous shop visitors," says Oliver Gliß.
Related articles

Oddschecker makes safe bet for future growth with Claranet cloud migration

Boosting developer productivity through innovative platform engineering

FinOps: Tools and methods for your company

Hybrid Cloud: The bridge between flexibility and control?

Deceptive stability in Kubernetes: Why a second look is necessary