Clouds.Fail

Do Clouds Fail..?

Migrating Legacy Workloads to the Cloud
300
A Move to the Cloud May Not Be Viable
301
Modernising Legacy Applications (1)
302
Modernising Legacy Applications (2)
303

Modernising Legacy Applications (2)

Most of the legacy middleware and integrations are from a time before the public cloud, which usually means that the software licenses are not cloud-friendly and do not allow for application portability to the public cloud. Even if some software is available in the public cloud, for example, Oracle databases in Amazon, the cost can be so high that it is not an option.

So the migration to the public cloud often comes down to a re-deployment of the application to a more modern and more cloud-friendly stack in the public cloud. If there is no time nor interest in re-architecting a legacy application — a redeployment to Apache Tomcat or JBoss / Wildfly middleware backed by an open-source database can be the best and most affordable path forward.

While analyzing the legacy applications for redeployment, it is worthwhile considering if the application may be container friendly. If an application can be cloud-native and can be deployed automatically, scale horizontally, and is stateless, then the application is potentially a good candidate to move to an orchestrated container environment like Kubernetes. Not every legacy application will become cloud-native.

Either way, the future deployment should follow modern software development practices, that include a CI/CD pipeline with a certain degree of automated testing, as well as using code to stand up the infrastructure in the targeted cloud environments. Even legacy applications benefit from modern software development and deployment methodologies.

We should remember that software in the cloud still requires a lifecycle. If not, we will in future blame the cloud for a large number of old and unsupported legacy systems we will be dealing with in significant organizations.