{"id":3355,"date":"2021-07-23T13:59:00","date_gmt":"2021-07-23T11:59:00","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=3355"},"modified":"2021-07-22T15:54:05","modified_gmt":"2021-07-22T13:54:05","slug":"the-great-escape-migrating-from-the-on-prem-to-the-aws-cloud-in-a-quickpretty-way-with-cloudendure","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/the-great-escape-migrating-from-the-on-prem-to-the-aws-cloud-in-a-quickpretty-way-with-cloudendure\/","title":{"rendered":"The great escape: migrating from the on-prem to the AWS Cloud in a quick&pretty way with CloudEndure."},"content":{"rendered":"\n
\u201cLife is what happens to you while you’re busy making other plans\u201d<\/p><\/blockquote>\n\n\n\n
said John Lennon in his song \u201cBeautiful Boy\u201d. <\/p>\n\n\n\n
In this article, we are going to see that sometimes there are unpredictable situations that can occur and, even if there\u2019s an accurate and detailed plan, our strategy needs to change quickly.<\/p>\n\n\n\n
When moving to the Cloud from an on-premise environment, <\/strong>it is always necessary to refactor or re-platform your application so that you can fully take advantage of the new paradigm. Sometimes external factors can make your decisions change dramatically: you have to change everything to be able to achieve your goal.<\/p>\n\n\n\n
A couple of months ago a customer asked us to help him migrate his e-commerce websites from his current hosting provider to AWS: we made a plan for an on-prem to cloud migration following the \u201c7R\u201d rules<\/strong><\/a>.<\/p>\n\n\n\n
After an inventory of all systems and applications it turned out that a lot of refactoring<\/strong> and re-architecting<\/strong> was needed, no systems had to be repurchased, retained, relocated, or retired, the rehost option wasn\u2019t even considered because the customer was eager to change the infrastructure paradigm he was using, taking full advantage of the cloud in terms of elasticity, cost optimization, and operational efficiency.<\/p>\n\n\n\n
There was a huge amount of technical debt due to old operating systems, obsolete versions of programming languages, and end-of-life database releases. <\/p>\n\n\n\n
We were not scared: the project was challenging but the prerequisites were clear and the final infrastructure will use containerized applications<\/strong>, RDS<\/strong> databases, and a bit of Amazon CloudFront + Amazon S3<\/strong> static sites hosting. <\/p>\n\n\n\n
The big effort was on the customer\u2019s development team side (supported by us): every application had to be refactored to be stateless<\/strong> and to perfectly integrate with AWS Cloud Services<\/strong> (like using S3 to host 5 Terabytes of static assets).<\/p>\n\n\n\n
We agreed to kick-off the project after the Christmas sales period, giving the developers the opportunity to take confidence with the Cloud and be ready to quickly release bug fixes if needed during the traffic-intensive period. <\/p>\n\n\n\n