Solving the problem of wasting a lot of resources just trying to insert systems.
The approach to “migrate” the client to a cloud had to take into account a few important risks.
After the migration to AWS, the customer noticed significant reductions in costs.
The bare-metal servers were not running properly and our client was wasting a lot of resources just trying to host their systems. The infrastructure had been set up in the pre-cloud era and some of the elements of the system had been set up in different hosting locations. This meant it was hard to manage access, and transfer data. The costs of server maintenance, getting new parts and keeping them all up and running at the same time was becoming more and more problematic and had reached the point at which it was directly influencing company stability. Scaling up the infrastructure was also hard because of physical limitations and deprecated software, which did not support automatic scaling. The client’s team were frustrated and wanted to improve things but without serious changes in the approach towards the host systems, only small improvements could have been made. Unfortunately, the infrastructure needed much bigger changes. This case study is a good illustration of how we deal with problems and deliver final solutions.
We investigated several different solutions. A private cloud was an option. However, this was rejected because private clouds are dedicated to a single client and this wasn’t possible in this case. The customer planned to create an infrastructure that could be used for multiple business targets in the future. After rejecting this option, a choice was made to go for AWS, mainly because of its leading position on the market.
The approach to “migrate” the client to a cloud had to take into account a few important risks:
▸ During migration, the system could go down for a maximum of 60 seconds only.
▸ There were more than 90 different servers with different operating systems (Microsoft and Linux) which had to be migrated in a strict order so as to keep availability high.
▸ The system was separated physically and would have to be unified in one solution supported by AWS.
▸ The database infrastructure was suboptimal and had to be redesigned before any migration could begin.
The process we designed was as follows:
1. Dev and test accounts were created in AWS to test progress of the migration.
2. In order to decide how the infrastructure should be designed, we had to create an architectural design diagram.
3. A comparison of the different hardware options was made (cloud vs bare-metal) to ensure the same farm of servers would be launched in AWS.
4. We started by creating an infrastructure in AWS:
▸ Networking parts (VPC, security groups, routes).
▸ EC2 fleet for services. ▸ CloudFormation templates to automate server deployments.
Thanks to the auto-scaling features, our client was positively surprised by the way their infrastructure’s load was handled.
In addition, after the migration to AWS, the customer noticed significant reductions in costs. He is now able to control expenditures from just one location (using AWS Billing). Managing the architecture configuration is much easier having it all in one place, without having to constantly jump from one multiple data center to other centers. The whole process took around 3 months, which included planning, testing and implementation of the changes.
However, the greatest advantage of having the infrastructure in AWS is that it is self-healing.
Now, when one of the EC2 instances fails or goes down, mechanisms such as Auto Scaling Group
and Launch Configuration can raise a new instance automatically without any manual involvement.
Also, thanks to the load balancers used in AWS, services now have regular traffic which means
the applications work consistently. Using Load balancers helps to control the traffic on the servers
and other virtual machines.
Scalac worked with over 80 companies around the world.
Find out more about our consulting and development solutions.
See how our team contributed to customers’ success.