Loyalty New Zealand migrates from VMware Cloud on AWS to AWS native and saves 30% in costs

This post has received input from Jeremy Anderson, Imran Ahmed, Matthew Jones, Ian Korolkovas and ER Hapal from Loyalty New Zealand.

In this blog post, we will show you how Loyalty New Zealand executed a move from VMware Cloud on AWS to AWS native services such as Amazon Elastic Compute Cloud (EC2), Amazon Elastic Kubernetes Service (EKS) and Amazon Relational Database Service (RDS) within a 3 month window. The migration reduced platform costs by 30% while increasing reliability, and cut management overhead by 20%.

Overview of Loyalty New Zealand

Loyalty New Zealand has been helping New Zealand businesses build lasting relationships with their valued customers for over 28 years. They operate two brands, Flybuys and Lab360. Flybuys, a retail loyalty program, boasts 2.9 million members spanning 80% of New Zealand households. Lab360 is an end-to-end data analytics consultancy. It leverages high-quality data and cutting-edge technology to help businesses address customer-related challenges.

Brief History on the Initial Migration

Loyalty began their cloud journey by migrating their core applications from VMware on-premise to VMware Cloud on AWS. This move allowed the team to maintain their VMware expertise while achieving better scalability and resilience, resulting in faster recovery times for critical applications.

While the initial move provided clear business benefits, data residency requirements for sensitive data and other dependencies prevented a complete cloud transition. A small on-premise VMware footprint, consisting of support services such as local file shares and domain controllers. This remaining on-premise footprint required significant management effort and was a burden on the team to manage.

Post migration analysis revealed the VMware Cloud on AWS workloads could benefit for dynamic scaling, which was not supported by their current setup. This limitation, along with licensing uncertainties, promoted the team to seek further modernization, and the team worked with AWS to create a modernization plan.

Initial State Architecture

Loyalty’s initial application estate sat across three environments: VMware on premise, VMware Cloud on AWS, and AWS native services (Fig. 1). This native service footprint powered their data platform and ecommerce applications, and primarily consisted of Amazon EC2, Amazon RDS, Amazon EKS and Amazon Elastic Map Reduce (EMR).

Fig. 1: Loyalty New Zealand’s Application Estate Prior to Modernization

The VMware Cloud on AWS environment hosted a multiple Ubuntu-based applications and services, including Virtual Machines (VMs), PostgreSQL databases, Elasticsearch nodes, and Redis / Memcached instances. While vCenter management allowed the team to use their VMware expertise, it restricted their access to native AWS services and modern cloud features. On premise, they managed multiple core services: a Secure File Transfer Protocol (SFTP) server for partner file transfers, a Windows File Server for shared drives, and Active Directory Domain Controllers for identity and access management.

Modernization Approach

The team started by identifying key workloads to modernize, which included out of support Ubuntu servers, legacy data stores, and a number of VM-based applications. They created migration plans for each, emphasizing quick transition to AWS native services. The target state followed AWS Well-Architected Framework principles, focusing on Reliability by distributing workloads across Availability Zones, and Operational Excellence by opting managed services where possible.

Containerization of Legacy Applications

Loyalty managed an estate of VMs hosting Ruby applications on an older version of Linux (Ubuntu 14.04). While Expanded Security Maintenance (ESM) provided a temporary support extension, the announcement of its impending end drove the need for replatforming. Their modernization approach for these VMs was to containerize them with Amazon EKS as a destination post-modernization.

To perform this modernization, Loyalty:

1. Assessed their applications: Loyalty conducted an analysis of their applications to determine their suitability for containerization. They evaluated each application’s dependencies and runtime requirements, then ran containerization POCs for several applications.
2. Created application specific container images: Using community-supported Ruby container images as a base, they created application specific images with required libraries and system tools.
3. Migrating to a new container registry: Loyalty pushed these container images into Amazon Elastic Container Registry (ECR), to be used with the deployment of their applications on Amazon EKS.
4. Deployed their new containers to Amazon EKS: Using the container images in Amazon ECR, they created clusters in Amazon EKS to host and run these newly containerized applications.
5. Automated CI/CD processes for these applications using Jenkins: Loyalty initially performed this containerization and deployment manually, however once they had defined the process, they built CI/CD pipelines using Jenkins to automate the process for future deployments.

Postgres Database Replatforming

Loyalty had a number of Postgres databases which were the primary databases used for their applications. These databases were running on an older version of Postgres (9.1), and, as part of their modernization, they wanted to upgrade to a more modern version. They also wanted to take advantage of a managed service for running these databases and identified Amazon RDS as the target platform.

Postgres offers native dump and restore utilities, pg_dump and pg_restore, which can be used when migrating Postgres databases. To modernize their database platform using these tools, Loyalty:

1. Generated dumps of the databases: Loyalty used pg_dump to create dumps of their database. The output from pg_dump is compatible with newer Postgres server versions, meaning that they could upgrade their Postgres version as part of this process.
2. Created the RDS instance: Loyalty then created an instance of Amazon RDS, using a newer version of Postgres (13.20) as the engine. This was created in a multi-AZ deployment, with a standby instance in a separate availability zone for redundancy and failover.
3. Restored backups into Amazon RDS: Loyalty then used pg_restore to import the dumps into the database running on Amazon RDS.
4. Validated data integrity: Loyalty created scripts to validate the data integrity of the new databases across both the source and destination database. They were able to compare the source and destination structure, row counts, and samples of data to have confidence in a successful migration.

Fig. 2: Postgres Database Modernization Using Dump and Restore Utilities

With the databases restored and validated, the applications on Amazon EKS were successfully connected and ready for cutover.

Elasticsearch to OpenSearch Migration

To resolve persistent quorum issues with their legacy Elasticsearch cluster (v1.1.2), Loyalty planned to migrate to OpenSearch Service. They opted to perform a staged modernization, with an interim step being a three-node deployment of Elasticsearch on Amazon EKS.

To perform this modernization, Loyalty:

1. Exported mappings and documents: Using elasticdump, Loyalty exported their existing mappings and data from their source cluster. Elasticdump is an open-source utility that provides import and export tools for Elasticsearch and OpenSearch.
2. Reviewed and updated mappings: Moving between Elasticsearch and OpenSearch meant they had to convert their legacy Elasticsearch specific mappings into an OpenSearch compatible format. They reviewed the output mappings, and updated them to ensure compatibility.
3. Created the new cluster: Loyalty then created their target cluster. In the interim stage this was a three-node deployment of Elasticsearch running on Amazon EKS, and finally a new domain on OpenSearch Service.
4. Imported mappings and documents: Loyalty then imported the updated mappings and documents into the target cluster. They verified a successful migration by comparing document counts, and running sample queries to ensure data integrity.

Virtual Machines to Amazon EC2 migration

Alongside these workloads, Loyalty also had to migrate a number of other applications including a finance system and data analysis tooling to AWS. They identified Amazon EC2 as the target for these workloads, and planned a migration using AWS Application Migration Service.

To perform this migration, Loyalty:

1. Installed the AWS Replication Agent: AWS Application Migration Service utilizes an agent to perform a block-level replication of a VM into AWS. The team installed this agent onto each of their application VMs, and configured these as source servers in Application Migration Service. They also configured the launch settings for the target servers, allowing to configure settings like their EC2 Launch Template and instance type right-sizing
2. Initiated replication: Once the service was configured and agent installed, Application Migration Service performed replication of the source VMs to AWS.
3. Tested migrated applications: Loyalty then launched test instances of the replicated applications on Amazon EC2, allowing them to verify the successful migration of their applications.
4. Performed cutover: Loyalty launched cutover instances for their applications and finalized the migration of these applications in Application Migration Service.
5. Post-migration activities: The team also created a plan to regularly review these workloads and their performance, with the possibility to right-size and cost optimize these workloads as demand fluctuates.

Fig. 3: AWS Application Migration Service Architecture

Other Workloads

Loyalty also maintained a number of smaller workloads that required modernizing, including caches and file servers.

Loyalty managed numerous Redis and Memcached clusters on VMware. Maintaining these clusters required extensive effort for patching, updates, and planned downtime. To address these issues, they planned to modernize to Amazon ElastiCache. To perform the migration, the team opted to set up the new caches with Amazon ElastiCache and simply re-seed them. This move meant the team was able to leverage a fully managed implementation of the respective platforms, simplifying the effort required for updates and patching.

Loyalty also modernized their 5 TB on-premise file share by migrating to Amazon S3 and using a third-party solution, CentreStack to act as their cloud file server. By mapping Amazon S3 buckets as network drives, business users could access scalable storage at a lower cost. They performed a gradual, per-user migration of files into S3 which were then re-mapped to users. Utilizing CentreStack also allowed for Office 365 authentication, eliminating on-premise Active Directory dependencies.

Loyalty also opted to replace their on-premise SFTP server with AWS Transfer Family, further reducing infrastructure overhead.

Fig. 4: Loyalty New Zealand’s Application Estate After Modernization

Achieved Outcome and Conclusion

Loyalty’s migration plans allowed them to execute on their migration from VMware Cloud on AWS towards native services within 3 months. This move yielded a 30% reduction in platform costs and a 20% decrease in managed services support hours. They were also able to minimize downtime during the cutover, with the total outage for their customer facing web and admin portals being less than one hour.

In addition to the reduced costs, utilizing native services also lead to a number of other benefits for Loyalty. Their web applications running on Amazon EKS could now scale automatically to handle spikes in customer demand, and this could all be configured using simple Kubernetes commands. Utilizing services such as Amazon RDS, OpenSearch Service, and Amazon ElastiCache also meant the team spent less time managing their database infrastructure and improvised their resilience posture. Post-modernization, Loyalty now only needed to manage the AWS platform, and no longer had to maintain their vCenter skillsets.

For more on cloud modernization strategies, see our prescriptive guidance on modernization. If you are an existing VMWare Cloud on AWS customer and want to discuss modernization, reach out to your AWS account team or contact us.