Application Cloud Migration and Re-architecture Journey

I remember in 2016 I first got involved in a cloud migration initiative. The preparatory activities took longer than the actual migration itself. Our team had to do an inventory and assessment of the application components, tools and other dependencies to make sure that nothing breaks post-migration. The goal was to move to the cloud without much impact to our applications and operations support. The first phase of our cloud migration strategy was basically just rehosting or a lift and shift. As much as possible we just had to move seamlessly to the cloud without any change to the application.

Benefits of phased cloud migration strategy:

• Better risk management - because you minimize the possibility of dealing with big impact changes at the same time

• Better cost management – you won’t have to worry much about bill shock due to the lack of understanding of how billing per cloud service works. When you’re new to the cloud it’s easy to miscalculate things and make mistakes in your cost forecasts.

• Managed capability ramp-up – managing and supporting an application in the cloud requires some upskilling of existing resources. Leveraging new cloud services would require a certain level of proficiency and experience to be able to operate your applications efficiently.

• More effective redesign/re-architecture – Incremental changes and redesign enables you to experiment and understand the nuisances of operating an application in the cloud. Hence, you can avoid over committing to certain service providers and specific services. Because there are services to which using it would mean you’re married to the service provider and it may not be that easy to jump to other providers once you’re in.

Since what we initially did was just re-hosting, all we had to do was to deploy the latest version of the app to the Dev environment in the cloud, make it work, perform testing and remediate as necessary. Once it’s good in Dev we deploy it to staging. One common issue encountered in different applications was reachability. There were instances wherein ports were not opened prior to deployment and there were also instances wherein subnet and security groups were not properly configured or set. For the staging verification, we also had to cover other tools that we’re using for operation. For example, in one of the applications that we’re supporting we had a need to connect to the database and extract reports periodically. So, we needed to include that in the verification to ensure that our applications will not just run as expected but also to ensure that we’re able to maintain the quality of our support. If post-migration we won’t be able to extract data, then we will not be able to satisfy our service level agreement for the reports. One important takeaway here is that the assessment done must be holistic to be able to avoid or at least minimize impact to operations. Once the assessment was completed without any open issue, that’s when we decided to proceed to production. The production deployment had an additional step especially for applications which had a number of daily transactions because we had to consider cutover to ensure that all the latest data were carried over to the cloud. Of the 10 applications my team migrated, we had different cutover plans depending on the nature of the application.

For a similar migration strategy as mentioned above, migrating Retrace is very simple. Below are the steps of migrating Retrace from on-premise to the cloud.

Enabling Retrace in the Cloud Post Lift and Shift (re-hosting) Cloud Migration:

1. Ensure that firewall ports for Retrace are open.
2. If your application uses profiling, error logging and custom logging of Retrace, you need to install the agent in your new environment in the cloud.
3. Validate that indeed the expected Retrace data are appearing in the Stackify platform.

For other cloud migration strategies (not mere lift and shift), the cloud migration process will be different. If your migration strategy includes PaaS, SaaS and Serverless, the migration process will become more complicated, will take more time and will require some re-design. But the good news for Retrace users is, Retrace supports IaaS and PaaS. What is even better is that Netreo will release its OTel appliance in the next couple of days. What this means to Retrace subscribers is that you’ll be able to use Retrace even for cloud native applications (SaaS and serverless).