In 2020, the year of COVID, we all realized that business continuity challenges are more than real.
In a world full of unpredictable events, such as the COVID pandemic, any business should be literally ready for anything. It does not matter if we speak about a busy holiday season in e-commerce when the systems are overloaded or about shifting to remote work or about environmental disasters that can destroy physical servers of the company.
Businesses must be ready to maintain the same level of continuity in any situation and be able to recover from any disasters quickly and resiliently. With cloud solutions, such as Amazon Web Services (AWS) or Azure, maintaining business continuity has become easy and accessible. Using cloud solutions, it is possible to ensure the failover of even the most complex and high-load system.
Business Continuity Challenges for One of the Biggest EHS Vendors
This is the story of our company’s business continuity maintenance quest for one of our most loyal clients, Cority (Enviance), a Canadian EHS vendor. We have been developing the Environmental compliance management system for our client for more than 15 years already, and in this context, migration to the cloud was just a question of time.
What is an Environmental compliance management system? In essence, it is a multifunctional system that any business can use “to track and record emissions, make reports, automate workflow, manage numerous tasks and documents within a single system.”
The questions of security, compliance, and quality standards have always had a paramount level of importance for Cority (Enviance), which works with companies from the Fortune 500 list. Business continuity and disaster recovery policies are the key elements of the cooperation between our companies, which is why we research and test top-notch approaches and solutions in this sphere.
Today cloud solutions are regarded as the most progressive and secure by Gartner and other industry analysts, including IDC, TechRepublic, and TechTarget. That is why it was decided to switch to the most cost-effective and reliable cloud service for.
“By 2024, more than 45% of IT spending on system infrastructure, infrastructure software, application software, and business process outsourcing will shift from traditional solutions to the cloud.” (Gartner)
Before the Cloud
Working with Cority (Enviance), we have the primary site (the data center where the servers are set up and deployed environments for development and testing), which we use for the service provision to the client, and the disaster recovery site (DR site). In case of any emergency on the primary site, Softengi is supposed to switch to the DR site.
Before choosing cloud solutions for Cority (Enviance), Softengi had a DR site (standby server) located in a secure place in another country. In any emergency, environmental crisis, or physical damage to the on-premise servers, the DR site would be activated within the next 6 hours.
Nevertheless, this solution was less cost-effective, secure, and reliable for obvious reasons, which is why we researched the most effective cloud alternatives.
AWS vs. Azure: How We Choose the Cloud Vendor
There are several options for cloud providers, but the main battle is often fought between AWS vs Azure. Both vendors offer a wide range of internal services and which are different in terms of the location of the servers and the prices.
AWS vs. Azure: 7 Things to Consider
Our task was to replicate virtual servers from Hyper-V hypervisor to the cloud with maximum efficiency and minimal costs. To perform an effective and successful cloud migration, the team set several goals:
- Creation of the roadmap for replicating virtual servers from Hyper-V into the cloud. We were using Hyper-V for the virtualization of resources, and we didn’t want to change it;
- Assessment of the existing options for the replication of virtual machines from Hyper-V into the cloud;
- Preparation. Cost assessment;
- Network configuration;
- Utilization of FortiGate+ AWS for the highest security level;
- Launch of the extended replica server on the DR site;
- Creation of access to AWS through the VPN tunnel;
- Failover testing.
Having analyzed the task and the services offered by AWS and Azure, we decided to go with AWS for 9 reasons:
- One of the main reasons for choosing AWS Server Migration is the fact that it is possible to pay only for the repositories which are used during the migration process. AWS permits the most efficient resource consumption;
- Another reason for choosing AWS is the possibility of launching all the capacities of the DR site within the next 4 hours after the incident;
- The possibility to use ECV for the Hyper-V replication;
- Remote access to the DR site via VPN is another tangible benefit;
- Secure data transfer to the DR site in the cloud with the help of FortiGate, which is considered one of the most reliable firewalls;
- Continuous data replication to the AWS cloud;
- Flexibility;
- Scalability;
- Transparency: the team uses VPN to switch activities to the DR site.
Peculiarities of the Process of Migration to the Cloud: A Cost-Effective Approach
As mentioned, the main reason for the choice of AWS was cost efficiency. We could use only those resources that we needed. For instance, for the replication, we chose a small-capacity machine, while for testing and development, we used machines with large memory, storage, and networking capacity. We can only use it for a short period of time, such as testing or failover, and thus, pay only for this time.
Most often, the migration to the cloud starts with a single virtual machine or testing environment if we speak about software development. We chose the same way. Firstly, we transferred 30% of our infrastructure (a domain controller, testing environment, and the infrastructure monitor system). For the virtual machines, we chose the SSD (GP2) class of storage and S3 Glacier to store backup copies of virtual machines.
The DR site was located in Frankfurt and based on AWS t2.medium EC2 instance, Windows Server 2019 with Hyper-V installed. It acts as a Hyper-V extended replica server that receives altered data from the primary site and keeps replicated virtual machines up to date.
Inside AWS, we were working with the on-demand instances.
The peculiarity of our cloud migration process is that we chose the type of instance that consumes minimum resources but cannot use the hardware-based capabilities of the Hyper-V.
In this case, we cannot launch virtual machines inside the EC2 instance, and we use this instance only for replication. When there is a need to run replicated machines we follow the scenario of shifting to the dedicated server – bare metal instance (m5.metal), which has virtualization capabilities to launch the replicated virtual machines in the Hyper-V.
- Creation of AMI image from the Hyper-V extended replica server;
- Deployment of the “bare metal” instance from the recently created image;
- Detach the EBS volume from the replica server, which contains the files of the replicated machines;
- Attach the EBS volume to the “bare metal” instance;
- Launch of the failover for each replicated virtual machine;
- Configuration of the virtual machines (CPU, RAM, and Network);
- Start of the virtual machines;
- Connection of the team to the DR site over VPN.
Monitoring FortiGate activity looks like this:
This approach allows us to spend resources efficiently: we save money by avoiding working with the constantly launched “bare metal” instance, which is much more expensive.
Conclusion
The choice of AWS cloud service as a DR site was the most optimal and, even more, important for the client, the most cost-effective approach. Using AWS, we don’t have redundant resources, we pay only for the resources we use, and this is a rock-solid argument for cloud migration of any business.
