Database Consultants Australia Case Study
Database Consultants Australia (DCA) is an established technology business that has been providing business critical data management and software solutions to corporate and government clientele since 1993.
They boast a strong management team, customer focus and employment history that is demonstrated in relationships with employees and customers that spans the 20 years of the company’s history.
The business develops and supports a portfolio of market leading and innovative products specific to the following strategic business units and industry types:
Migration of a purchased Web Application from Fairfax which had to be migrated out of the Fairfax environment within a short timeframe
Lift & Shift Migration of the Web Application to a new domain name
The migration was completed successfully within the timeframe and to budget
Post Implementation review with Mark Dulfer Of Database Consultants Australia.
What were some pain points being experienced that prompted a search for a cloud services provider?
Database Consultants Australia (DCA) purchased the fairfaxbr.com ruby application stack.
There was a 45 day contractual obligation to migrate it to new AWS infrastructure and make available at the new domain name marketbase.incnet.com.au
DCA are a Microsoft services and we did not have the AWS skills in house to be able to make this transition within the required timeframe.
As such we decided to look for an AWS Partner that could assist us to get the migration done.
What was the engagement process like? How was PolarSeven found?
Fairfax, who we were purchasing the business from, had an existing relationship with PolarSeven and recommend that we contact them.
What due diligence process was undertaken to minimise risk and ensure the best provider was successfully engaged?
Based on the recommendation from Fairfax and some introductory conversations with PolarSeven we were comfortable to go ahead without undertaking any major due diligence.
What solution was implemented within the business?
There were 4 main stages to the migration;
Bringing up infrastructure components such as instances, load balancers, S3 buckets, networking, security groups and other components to support the deployment and management of the applications.
Infrastructure is provisioned using cloud formation triggered by a standardised grunt framework.
The provisioning process generates the following elements:
- S3 Buckets need to support the infrastructure
- VPC with two public, two private and two routing subnets
- Route tables
- VPC endpoints to facilitate S3 connectivity
- Pair of AWS Nat Gateways for public network connectivity
- Security groups to support all elements of the deployment
- Single auto healing OpenVPN server for VPC network access
- IAM Roles, Profiles and Policies to support all deployable elements
- Multi-AZ RDS (MySql)
- Multi-AZ Elasticache (Memcached)
Servers are configured to fulfill the functions designated to them by their role. This implementation uses cfn-init which is a cloud formation wrapper for cloud init, to orchestrate the instances.
Deploying application changes to an existing application cluster by connecting to the Open VPN server to gain access to the network. Then SSH into each of the application servers (as a sudoer) in turn and execute the command to pull the latest application changes from the master branch of the application repository in GitHub
Operationally supporting the infrastructure. In this deployment it refers to accessing the application logs and monitoring services.
The AWS Logs service is installed on the Elasticsearch nodes and Web Application nodes. This service tails log files on the servers and pushes the logs into AWS Cloudwatch where they can be viewed, filtered, or downloaded for viewing.
System monitoring for EC2 instances is provided by New Relic. All servers including the Open VPN server, Elasticsearch nodes and Web Application nodes can be found in the New Relic console.
Monitoring of Elastic Load Balancers, Elasticsearch Memcache nodes and MySQL RDS instances can be done via AWS Cloudwatch metrics.
What specifications needed to be adhered to?
The project was pretty much a straight forward “Lift and Shift” migration.
We had to remove some Fairfax componentry for security and also ensure that we maintained the correct levels of security and access for ourselves.
All other variables were pretty much kept the same.
What were some of the alternative options proposed, that were not undertaken and why?
We want to refactor the application in the long term but this simply wasn’t possible given the time constraints of the acquisition.
Our only option to meet those contractual deadlines was to migrate to the new domain.
How would you describe the project in terms of success?
The main criteria was our time constraint to get the migration done.
We hit that and everything was delivered on time and to budget so we were happy with that result.
How did you rate your experience with PolarSeven?
Their technical knowledge was excellent so it was a very positive experience to be able to have a Partner that we knew could deliver our end product for us.
At no stage of the project did it ever look like we were not going to hit the deadlines so we felt comfortable throughout the entire process.
Would you use PolarSeven again?
Yes, definitely for any type of AWS project we would certainly give them a call.
Would you recommend PolarSeven to others?
Certainly for AWS work. They are a great technical team who delivered well for us in this project.
Download The Case Study
- Client DCA - Database Consultants Australia
- Date August 30, 2019
- Tags Enterprise
- URL View Project