Migrate or not migrate - that is the question arising to every business that relies on software with on-premise infrastructure. While physical access to the servers may feel more secure, their maintenance is costly and challenging. On-premise infrastructure support requires either
- an inhouse team of developers
- pros: when everyone is already familiar with the infrastructure, they can provide fast and high-quality support
- cons: high cost; it may be wiser to spend the developers’ time on new perspective projects to achieve further business progress, rather than on maintenance of the current infrastructure
- outsourcing support services
- pros: lower cost
- cons: more time-consuming to fix system failures, since the specialists need time to learn the specifics of the infrastructure, which may be critical for user experience; the older the infrastructure, the harder it gets to find professionals able to support it.
Infrastructure migration to cloud is an alternative that resolves the maintenance issue, offers excellent support, software scalability, and makes the overall app more cost-effective.
The migration itself is a risk-free process, but only when it is thoroughly planned and prepared.
Click to tweet
That’s why in this article we pay special attention to the main stages of preparation for infrastructure migration, based on our experience with B2B sales management software Pro.con.
Let’s jump to the interview with Apiko DevOps engineer Andrii Zomko, who has shared the highlights of getting ready the Pro.con on-premise infrastructure for migration to AWS cloud.
- Hello, Andrii! Could you tell us how was the app infrastructure organized before its migration to AWS cloud?
The initial app infrastructure is organized using a dedicated server from a hosting provider. Since Pro.con is B2B contracts and sales management software for mobile network operators and distributors, every application customer has their own isolated virtual machine with data storage, database, and an application copy.
- What were the reasons for infrastructure migration to AWS cloud?
An on-premise infrastructure solution was getting harder and harder to support. There was a little opportunity to scale up servers and applications. The customer faced issues with support during critical application outages. Some system failures took hours to get resolved.
Migration to cloud will increase app’s cost effectiveness and eliminate the support issue.
- What do you need to do to prepare for the migration to AWS? What are the main stages of such preparation?
- First of all, it is necessary to understand the app’s architecture. We need to know
- if the application can run in parallel, that is if there can be more replicas of the application
- how many resources are used in the current environment (quantity of CPUs and RAM per server, number of servers, and the amount of storage)
- how the application stores its data, and what the database infrastructure configuration is, e.g. you can use
- managed databases, e.g. the ones suggested by AWS like RDS, Aurora, DocumentDB (the database management and maintenance are done by a third-party provider)
- self-managed databases, as in our case with Pro.con app (are configured on an on-premise server or cluster and are managed and maintained by client’s own IT staff)
- Database as a Service (DBaaS) platforms like Atlas MongoDB, offering DB infrastructure setup, management and other related services to avoid misconfigurations in the cloud environment.
- Then we need to design cloud infrastructure
- What key components it consists of (servers, Elastic Kubernetes Service, Container Registry, load balancers, Virtual Private Networks)
- How we can optimize applications for new infrastructure to be fault-tolerant and scalable
- Design network solution for the application, according to its requirements
- Private networks. Servers in private networks don't have access to the internet. To provide this access, a network engineer needs to create a NAT Gateway which results in additional costs. However, it allows connecting to the services outside the private network while staying unavailable for the externally initiated connections, providing more security.
- Public networks can be less secure because they are internet-faced, and you need to implement additional security layers for the servers (security groups in AWS)
- Choose the tools for application deployment, monitoring, and alerting. For example, for Pro.con we use helm for deployment templating, GitHub actions for application deployments (you can find more about using this tool in our article DevOps Practices for Seamless and Faster App Deployment), Prometheus exporters for monitoring, Grafana for visualizations and alerting.
- It is important to create a cost estimate of the new cloud infrastructure, so that the customer will avoid unexpected bills in the future. We should also think about how we can reduce the cloud migration cost for the client. That’s why, we pick open-source tools to provision infrastructure, and tools for deployments. Also it’s crucial to choose servers with optimal compute power, reduce the number of load balancers and unnecessary NAT gateways.
- What steps does the AWS cloud migration plan consist of?
The app has to be cloud-oriented and support AWS-based services. It’s crucial to understand if we need to make any implementation or architectural changes to migrate the application in AWS.
- Implementation of change.
Make changes to the data structure of the application. This phase might be the longest step as it can include many designing and re-platforming sessions at a granular level until the application achieves the desired state. These changes can include code change, architectural change, underlying infrastructure change, and so on.
- Proof of Concept (PoC).
Create a PoC solution for your application to see how it performs in a new environment. Keep your eye on system performance.
- Data migration.
It includes steps like migrating on-premise databases to the cloud and migrating static files and dependencies to Amazon S3. This can be a time-consuming process, considering that the legacy applications might have a huge amount of data in their databases. Once the cloud migration is done, a comparison check will be required to validate if the data between the on-premise database and a cloud database match.
- Application Migration.
This step includes the actual application migration and deploying it to cloud services. In Pro.con case, we need to deploy a containerized application to AWS ECR.
- Test and operate.
Test your application performance, and monitor system health to avoid application outages.
- What are your top 3 pieces of advice when preparing for migration of the on-premise infrastructure to AWS cloud?
- After designing the infrastructure, develop a migration plan, and run a proof of concept (PoC) application. Such a structured approach will allow you to see how your application will work in a cloud environment. Moreover, it helps you to make sure that the migration plan works, and will let your team learn about the steps and tactics involved in migration.
- Try to run performance tests to better understand how many resources your application needs. Also, to make sure your infrastructure is fault-tolerant, stop some servers/containers to see how they will recover from system failures.
- Design a secure network solution. Make sure that your application is not exposed to the internet directly. For example, add a load balancer in front of your application and expose only needed ports (80 for HTTP connection, 443 - for HTTPS). To keep the application more secure - add servers to the private network, and configure NAT Gateway, so the actual servers cannot be accessed from the internet at any chance, and all incoming connections are handled by the load balancer.
- Have you faced any challenges during the preparation for migration to AWS?
A big challenge for us was to understand how many compute resources we needed to configure. That is, how much CPU and RAM the application will use during normal and high loads.
In our case, Pro.con is distributed for multiple customers, which means that every customer has a completely isolated copy of the application. So we needed to complete the following challenging steps.
- Calculate how many replicas of the application would be running inside the cluster and how many compute resources they’d require to avoid unexpected application exits or errors. It is related to Kubernetes environments: Kubernetes has a great feature for application spreading across multiple nodes (servers). We kept in mind that every Pro.con customer needed to have at least 2 replicas (two copies of an application). So, for example, if the number of customers was 20, we needed at least 40 replicas. Also, the number of replicas can grow based on Pro.con customer workloads.
- Find the optimal solution for Kubernetes cluster monitoring, and implement it. There are many monitoring solutions, but most of them are complicated (e.g. ELK stack) or require too much CPU or RAM on a cluster. For now, we have decided to configure Prometheus with Grafana, as it is the optimal solution for our workloads.
Currently, we are on the PoC stage of our migration journey, and preparing for data migration from on-premises to the cloud. Most of the challenges here had to do with application architecture, especially in data storage, because for now the application stores data on disk space in a virtual machine.
- What are the main things to pay attention to while migrating the app infrastructure to cloud?
In my opinion, the main thing to pay attention to is system performance. You need to make sure that your application is predictable in terms of CPU and RAM usage in a cloud environment. It is hard to find that middle ground between cost-efficiency and application performance.
- What benefits of AWS infrastructure have you already experienced? Could you describe them in more detail, please?
Distributed workloads: replicas are in different Availability Zones so applications become highly available. AWS has great support, but most problems can be solved by our team. The solution is highly scalable, for example, we can run up additional servers in seconds, and they will be automatically added to our cluster.
Thank you, Andrii, for these insightful and useful preparation guidelines and tips for infrastructure migration! I’m looking forward to seeing the completed Pro.con migration to AWS services, and to sharing our results and the way we achieved them with our readers.
Feel free to contact us if you have any questions. That’s it for now, but certainly, to be continued ;)Case Studies