success cases
Property Management Company
The Property Management Company focus on Hotel Management Software in the Cloud for small and large hotels, Zavia Distribute the hotel inventory in all online channels and automate the hotel management process in the operational, administrative and commercial areas. The software adjusts to the needs of each client, in this way they pay for what you use.
Integral Operation System in the Cloud; Developed for the continuous improvement and automation of the hotel business process through reservation engines, connectivity with channel managers, payment gateways, real-time information with automated reports and more.
TESTIMONY
Why the Customer Chose the partner
MAIN
Customer Challenge
The scope of this challenge covers Database Migration from RDS to Amazon Aurora of the technological infrastructure of The Property Management Company ERP. We have recommended that before performing this process, create a QA environment where you can replicate the current environment and validate a migration plan with the test validation for subsequent final migration.
Because database migrations are often complex, we recommend an iterative and gradual approach:
1• Evaluation
2• Migration planning
3• Migration testing
4• Test
5• Final Migration
6• Deployment
The Property Management Company ERP does not have different environments, part of the challenge will be to create migration phases, an important stage is the proof of migration, therefore, having a “Test” environment where you can validate that all processes continue to work correctly is very important. This environment will not only serve for database migration validation, but also for future changes in architecture.
This is a list of things we believe need to be considered:
• QA Environment Creation – Leverage AWS Organization using the QA Console.
• Create current architecture diagram for replication. High level.
• Associate users and roles for access and permissions.
• Clone the components of current architecture to TEST environment; EC2 and RDS.
• Configure on/off for efficient use of the QA environment.
Why
Amazon Web Services
The client was already using AWS, but had deficiencies in terms of technologies used to support the solution, which caused the portal or solution to be unstable at certain times and days, and specially during high season, which always presented crashes.
We offered consulting service, in which we help the client initially to generate a QA environment, something they didn’t have and needed, the new environment uses fewer resources, but was able to emule the productive environment, which allows stress tests on a smaller scale.
All this was developed following the best practices of AWS Organizations, generating corresponding business units, separating the workloads of the productive environment and QA, thus identifying the expense in each of the environments.
The solution consisted of the migration to the managed use of the database, going from a MariaDB to an Aurora, which among its main advantages is multi AZ and has the ability to generate write and read endpoints.
The above is important because the batch processes of the client that generated crashes, made intensive use of the database, in order to mitigate, two read replicas were created, additional a family of computation focused on the intensive use of memory was chosen because the metrics of the previous database, indicated that the memory consumption was high, moving from an M family to an R family.
Main
Results and Benefits
As a result of the separation of environments, we found that the database and application were in different regions, now, the database and application were located within the same region, with the aim of eliminating the costs of data transfer. Both services (the application and database) are in the same region.
Using Elasticache RDS and EC2 saving plans there was cost reduction, the plans are active for a year until 2023. It was made at the beginning of the activities of this project.
It was validated that DB backups are correctly scheduled, something that did not exist before.
There use to be a m5.2xlarge databes, after migration, they have now an Aurora with r4.xlarge family (read and write), by changing from one database engine to another, there was a significant reduction in cost, as well as an increment in performance.
The improvements were cost and performance optimization after migration, there is now a reduced version of productive environment (the Test environment), there used to be system crash every now and then, now they have many tools that prevents this from happening (removed multi-region latency. Database Cache, multi AZ database and write/read endpoints).
Autoscaling allowed the application to scale up or down its resources dynamically based on changes in demand, so that the system can continue to perform optimally even during peak loads or sudden spikes in traffic.
Some of the benefits are:
• Optimization of IT team time in infrastructure management due to the move from an on-premises scheme to a cloud scheme
• Lower costs by only paying for what is consumed in infrastructure and services.
• There is also a reserved costs plan.
• Scalability and elasticity of cloud components based on demand.
