With lots of interest in Docker-based migration of applications into a public cloud infrastructure, there are questions on the best approach to shift and scale applications in the cloud. Before answering that, a more pragmatic question should be asked:
"Should my application shift to a new architecture and the cloud?"
Though the answer is not simple. Here is an attempt to identify the key questions to ask before taking up this exercise.
1. Are We Moving to the Cloud, or Are We Talking Architecture?
The answer for this needs to be carefully analyzed. If the 'hype' part of the consideration is eliminated, you need to look at following:
Is there a financial need to move to the OPEX model compared to the CAPEX model of in-house hosting/maintenance? Are the costs worked out and agreed upon for a three-five-year period?
Did management make an informed decision that the application needs to be upgraded to a next-generation architecture/platform (not based on hype), and will they stand by it with reasonable budget challenges?
Have business associates and other stakeholders inside and outside (including customers) bought into this idea, and are they behind fully on this?
2. Any Scalable Components?
Many applications have components that are heavily and directly used by their users. Just scaling the application by adding more resources to it is the traditional way to handle demand increases. However, a detailed analysis may lead to the determination of libraries/components that are exercised many times across different application flows. These are ideal spots that slow down the application and are candidates for scaling while the rest of application can work with the normal resources allotted to them.
3. Monoliths and Separation of Concerns
From the previous step, if these libraries/modules are determined to require scale, re-engineering them to become standalone service(s) with interactions via APIs can be the first step to start the journey to cloud-based scaling. Having higher configuration VMs for these and a more optimal VMs for other parts of the application can be a cost-effective way to move to the cloud.
4. How Small Can You Go? Can We Split the Database?
In the exercise that was done above, if you can isolate the entire hierarchy of the application components up to the database level, you are mostly into the new architecture of software model of 'microservices.' Achieving this is quite a challenge in the traditional applications that have been developed in the pre-Hibernate era.
5. Check for Cloud-Native Alternatives
In the process of dismantling the application, if there are chunks of activities that are provided by the cloud provider as part of their service offering, it be worthwhile to consider using it. The cost of these services gets driven down when there is more traction among application developers over a period of time. Welcome to 'serverless' architecture!
6. Should I Be Cloud-Vendor-Agnostic?
If there are not many native services that can be utilized and the cost of cloud hosting is a consideration/concern, it will be wise to choose components of cloud services that are common among leading providers. There are some specific solutions that can be used here additionally for this exercise, namely OneOps that was open sourced from Walmart labs. A word of caution: Ensure that there are experts in your organization who can understand the various cloud infrastructures that are being considered for hosting/migration of your application.
As with every software modernization/upgrade exercise, getting a picture of the complete pathway upfront will be difficult. But understanding what the destination architecture/platform offers and studying the use cases of similar applications migrated will lessen the surprises in the journey.