"Fabric made the decision to move to AWS easy. The approach to the PoC was lightweight and quickly validated our critical systems could run in AWS. Fabric’s iterative approach gave us continuous visibility and confidence that we would meet our deadline to decommission our legacy hardware and maintain service levels of our critical freight lodgement systems."Angus Bissland, Head of Commercial, IT at Australia Post
Fabric, a key application development and support vendor to Australia Post had managed core freight and logistics applications, hardware, network, OS in a traditional datacentre for over 6 years.
The equipment was due for refresh, however Fabric identified an opportunity to look at more strategic options that tied in with Australia Post’s cloud first policy and desire to move away from traditional on premise hardware and consolidate their data center footprint.
Fabric looked at both private and public cloud options, however on assessment found the private cloud/data center vendor cost model prohibitive and the operating model inflexible. It was at this stage that it was determined to investigate the public cloud offering from AWS further.
Once the desired target end state was agreed with Australia Post the project was broken into a number of phases.
The 1st phase involved Fabric configuring database replication to AWS to minimise risks associated with the current SAN and existing backup infrastructure.
The 2nd phase, a proof of concept (PoC) was implemented, the results of which were ‘showcased’ to the customer which included the detailed project plan, resource time and cost estimates for the end to end migration and transition. The solution pricing was sized as a “total cost” per application i.e. S, M, L (including L2 and L3 application support, infrastructure support, and service management).
The 3rd phase ensured all architecture and migration strategies was tested and defined as well as the establishment of a “Direct Connect” between Australia Post’s network and the AWS environment.
The final phase was the migration of the production applications. The migrations were cutover outside of business hours and with no business impact, with the entire project (phases 1 through 3) being delivered in less than 6 months.
The following diagram is a visual representation of the 3 potential migration strategies for the applications. Initially all 3 applications were closer to the lift and shift approach but it was determined that this was not the ideal solution. Only application 2 kept the original operating system due to coding requirements, however, it was determined to refactor code at a later date.
Challenges during the migration necessitated the requirement to change some functions and decouple functions from EC2 instances. This ultimately this resulted in more robust applications, better suited to the AWS architecture.
Following migration, all 3 applications remained classic 2-tier designs, but now utilise AWS features such as; multiple availability zones, ELB’s, and autoscaling of EC2 instances.
A standardised approach was developed across all applications for monitoring and alerting via CloudWatch, Kinesis streams, and Elasticsearch for log capture and consolidation.
Additionally the following features were implemented per application: