Background
Lucky to be part of cloud migration team in my organization, with the best thing is my involvement when it matters most for me.
I take this platform to share my learnings which I have learnt while talking to the people and exploring the solutions for the technical problem, which is eventually leading me to gain leadership and technical skills.
Some of the learnings and takeaway:
Split the tasks into 2 categories:
- Tasks, which are required to be completed at any cost.
- There is no end to improvement, so tasks, which qualify for continual improvement.
Phase wise migration
Migration would occur in following 2 categories:
- Application
- Data
- Infrastructure Services (Database, Messaging Platform)
- DevOps Pipelines
- Most importantly, Alerts
Migration would generate to lot of unpredictable behaviour, so it might led to give a thought to the following factors:
- Define phases in the context of traffic volume, it can a client or set of clients generating low traffic.
- Give thought to the delta data migration
- Does the current infrastructure (database) supports delta data back up
- Proposed infrastructure support delta data restoration.`
Nothing but the set up from the scratch
- So it's worth investing in having the local set up where you can debug the application from your IDE in your development environment.
- It's a golden opportunity to upgrade all your existing services because of following reasons:
- Need to conduct all the possible testings irrespective of service upgrade.`
- Uncertainty on how the new target system would behave with the services.`
2P Dependencies
Make sure you highlight the dependencies on the dependent team first otherwise you might end up in a situation where you are ready to Go Live but you need to complete last moment thing like traffic diversion. We had the similar scenario where we had to communicate the team to add header element in their request URL so that the traffic can be diverted to new infrastructure.
Mistake, which you might make
-
Make sure to confirm in your source code repository and deployment pipeline if all services have been migrated. We missed some of the services because of following reasons:
- One service was missed as we searched with some patterns and this particular service was not full filled by this pattern.
- Root cause: One of the Git repo contains another un related micro service.
- Learnings: Have the common pattern and hence get this un related micro service to another new git repo.
- Root cause: Git repos were scanned based on patterns and one of the git repo was not following this pattern.
- Learnings:
- Scan should happen to all possible places, but not limited to just following:
- Git
- Container Repository
- Log Aggregator
- One deployment was missed as this deployment was part of already migrated module.
Don't ignore any single error message, which you see as part of testing, it can be functional testing or load testing. Because of the ignorance, we had to increase the meta space memory for the JVM from 128m to 160m post deployment.
What went well
- After migration, there was traffic for delivery but not for ingestion. Upon highlight, the concerned team had to rectify their side.
- Load Test, which gives the proof for the microservice scalability and API performance, was on top priority.
Challenges
- While using Azure VM, we realized that adding data disk from the portal is not sufficient. It's required to be changed on the kernel level.
- Upgrading the dependent infra (Database, messaging platform) client version directly is not sufficient as each of the springboot maps to specific infra version through dependencies module.
Learnings from the leaders
- There is no end to the work so don't hesitate to give some relax time to the mates, if team member is tired, we can't achieve any turnaround result.
- Irrespective of your busy schedule, explain all the interesting facts and root cause of any issues to the team, which you have gone through.
Top comments (0)