We have all heard about the famous “move to the cloud” concept, and for many, the concept of moving things out of your own office or hosting center and into this “cloud” seem daunting. In this article, I will give some insights into how we did this for one of our applications, a Legacy Monolithic CMS application running in PHP with Laravel and utilizing a PostgreSQL database. This application has been used as a framework to deliver multiple client projects of varying complexity with multiple integrations against 3rd party services and contains many 1000’s of lines of code.
We started out investigating what benefits we would get and what potential challenges we might encounter as we moved this application into the cloud. We evaluated several different options from “just” lift-and-shift through leveraging various GCP infrastructure options to converting the application to be completely cloud native. We decided to make minimal changes to the application itself and just make some minor structural changes.
Version wise, the only thing we needed to upgrade was the postgreSQL database to be able to utilize Google Cloud SQL as the hosted database in place of the local postgreSQL database-server and free ourselves of the database management operations. Google Cloud SQL is a fully managed database service on Google Cloud Platform which supports both MySQL and PostgreSQL. Since we used some functions and extensions that were not supported on Google Cloud SQL, we needed to rewrite these into a supported standard language. Due to the newer version of Postgres, we could easily do this with the new functionality included in that version.
After considering the implications of Cloud vs fully hosted local environment, the only changes we needed to do, were the database changes to support Google Cloud SQL and changes to the mail-routing to utilize Mailgun for sending mail from within Google Cloud Platform. Sending mail from Google cloud platform on port 25 is not permitted since this port is always blocked on GCP.
We also saw some potential future enhancements in splitting the Monolithic application into microservices, utilizing Google Cloud Load Balancer and moving the application into a Kubernetes Cluster, but this was beyond the scope for our project.
We decided to do a “lift-and-shift” move of the current VM to Google Cloud Compute Engine which, in short means replicating the VM (including some required changes to network configuration). We then moved the databases to Cloud SQL. The “lift-and-shift” was done in an orderly fashion and went without any issues and we were able to launch our Sites CMS application on GCP for testing within hours, utilizing the local postgreSQL database server, residing on the same VM, as it had always done. We modified the configurations so we could utilize Mailgun and did some testing on the CMS, hosting the pages and testing the performance of the application.
With all the testing and initial configurations in place, we prepared the postgreSQL database for the transfer to Google Cloud SQL. We rewrote the SQL functions we needed to, and created our Google Cloud SQL instance and imported the database to the cloud instance. After configuring the necessary security settings for allowing our application to communicate with the Google Cloud SQL instance, we started off by testing the full solution by switching one of our dev-sites to use the new Cloud instance. After intensive testing of the functionality, we decided to first move our developer sites onto Google Cloud Platform, and then move the corresponding production sites after verification of a successful dev-move was confirmed.
Gradually, we moved the sites, one by one, onto the GCP Solution, without any downtime to the web-sites. The only thing that was affected was that any articles published between taking the database dump and switching to the new solution would need to be re-published when the new solution had been deployed. This was a business decision out of a cost/benefit basis and we could have architected a no-down-time solution for the move if needed.
We moved from having a total of 6 servers hosting sites (from dev to prod), in different versions, to just 2 Google Cloud hosted servers and two Google Cloud SQL instances. No changes to application level code were required. Since this move developers have started to make use of Cloud Native features like Pub Sub in applications. With Google Cloud Platform, security is high by default and everything is encrypted at rest or in transit.
This application is one of a series of legacy applications we have moved from hosted environments into various GCP environments including Kubernetes and Google Compute Engine. We have also implemented Cloud Native applications using Kubernetes and Google App Engine.
If you have any questions regarding what a move to Google Cloud Platform could do for you, please don’t hesitate to contact us.