Introduction
It became a recommended practice for Cloud Migrations to be done in phases to minimize risks, speed up the deployments, and ensure the continuity of the services. The easiest and most common method is to Lift-And-Shift aka rehosting an application and its data with the minimum possible changes to the code. During a few minutes, we’ll walk through the process of doing that for a Java/SpringBoot Application.
The YouTube Channels in both English (En) and French (Fr) are now accessible, feel free to subscribe by clicking here.
Do you prefer the Video format instead? We have got you covered:
How To Lift And Shift
Migrating an application with the lift-and-shift approach is often done by updating a few configuration files, taking into consideration the PAAS model, in which we are only responsible for the App and its data, with the infrastructure being handled by the Cloud provider in use.
Many services are available to do so but depending on your specific case, one may be favoured over others. For this showcase, we opted for AWS ElasticBeanstalk which has an intuitive command line interface (CLI) that we can quickly play with to achieve the desired result.
What is ElasticBeanstalk?
ElasticBeanstalk is an Amazon Service that enables organizations and developers to deploy and scale their Applications in the Cloud with the least possible change to their code, it’s even very friendly no matter your Cloud experience.
So, our only focus should be our code because it’ll provision and manage the App infrastructure for us, of course, we can define some specific settings to customize the resulting infrastructure. It works with multiple stacks like Java, .Net, Docker, Go, NodeJS, PHP, Python, and Ruby.
Demo
For the sake of the article, here’s the context in use for the following sections:
“As a company, we have a Java (Spring Boot) Application along with a MySQL database hosted on-premise to serve our users. As part of our long-term digitalization strategies, we should first quickly move it to the Cloud, considering that our team has less or no Cloud experience beforehand.”
The source code to use is hosted on GitHub, feel free to clone it and jump in the right folder.
Let’s start by cloning the project from the GitHub repository.
git clone https://github.com/numerica-ideas/community
Then, go to the directory that contains the project:
cd community/aws/springboot-migration-elasticbeanstalk
Migration Steps
Migrating that Spring Boot App is done in only 5 steps that anyone can apply right away and that we’ll summarize into 3:
- Create the deployment package, generally an executable JAR file.
- Define the environment or infrastructure to run the App in, and a few settings to provide.
- Upload the executable of the App for it to get deployed automatically.
You first have to install AWS CLI and set it up to use an account with the right ElasticBeanstalk capabilities.
Here’s how to configure your CLI to use a specific AWS account:
Once done, then quickly install eb by using pip pip install awsebcli. Let’s note that the EB CLI requires Python 2.7 or 3.4 and a pip package manager.
Step 1: Initialize the Project
The first step is to enable our project to use the EB CLI, the eb init command is available for that, it’ll create a config.yml file into the project, feel free to version it to have some precision of the deployment settings the App uses.
For this step, we used the following options:
- Region: us-east-1
- Kept the default name for the created Application
- Platform: Java – Corretto 17
- No CodeCommit config
- No SSH for instances
This being done, within a hidden folder called .elasticbeanstalk, you’ll see the file config.yml that holds all those settings.
Step 2: Create The Environment
Afterward, let’s consider creating the EB Environment, this step should be done once. The sample option will create the environment with a sample application, but we’ll update it at the end with our own SpringBoot App.
Here’s the terminal command to run:
eb create spring-cloud-migration --sample --single --timeout 30 --instance_type t3.micro --database.instance db.t3.micro --database.username SpringBootAdmin --database.password Strange_Pwd --envvars PORT=9090 --tags tag1=val1,tag2=val2
Then, go to the directory that contains the project:
By this, we are creating an environment named spring-cloud-migration, that uses a sample application hosted on AWS for the first deployment, running on a single instance (for now), with a timeout of 30 minutes in case the provisioning doesn’t go through quickly, with a t3.micro instance used for the server(s) and RDS database, plus the credentials for the Relational Database to use, along with a specific port (9090), and a few tags for illustration purposes.
The environment could be dev, prod or even staging depending on your release workflows, meaning you can create many environments and use them afterward for deployments.
By default, EB uses Nginx as a reverse proxy to map your App to the Load Balancer that is created for your environment, the Nginx server runs on port 5000 by default which we can customize by defining the PORT environment variable that our App will use at runtime. You can read more about this in this guide: Configuring the proxy server – AWS Elastic Beanstalk.
If you specify the “– platform”, or even “– region” option, it’ll override the global value provided during eb init in the previous step.
By accessing your AWS account, within the ElasticBeanstalk service you’ll see your created environment, ours looks like the following screenshot:
The sample App is used for our environment setup for now, this is made by the option –sample, so opening the auto-generated domain name will display something close to the following screenshot:
Step 3: Deployment Package (build)
To perform the deployment we need to have an executable for Java Apps, but before doing so we have to ensure that our App knows we are customizing the port from the environment variable and that the database credentials are available.
The class ServerPortCustomizer.java whose content is as follows has been created for that purpose:
@Component
public class ServerPortCustomizer implements WebServerFactoryCustomizer<ConfigurableWebServerFactory> {
private static final Logger logger = LoggerFactory.getLogger(ServerPortCustomizer.class);
@Override
public void customize(ConfigurableWebServerFactory factory) {
String envPort = System.getenv().getOrDefault("PORT", "8090");
int serverPort = Integer.parseInt(envPort);
factory.setPort(serverPort);
logger.debug("=== The server port is {} ===", serverPort);
}
}
From the environment creation in step 2, the following environment variable will be accessible within the deployment context of our App: RDS_HOSTNAME, RDS_PORT, RDS_DB_NAME, RDS_USERNAME, and RDS_PASSWORD.
Let’s provide these to Spring Data via the application.properties file:
# Datasource connection
spring.datasource.url=jdbc:mysql://${RDS_HOSTNAME}:${RDS_PORT}/${RDS_DB_NAME}
spring.datasource.username=${RDS_USERNAME}
spring.datasource.password=${RDS_PASSWORD}
spring.jpa.database-platform=org.hibernate.dialect.MySQL5Dialect
The whole file looks like below:
Let’s create the Deployment Package (JAR) by running the command ./build.sh, the corresponding script is already available within the project, this compiles the App and saves a JAR file in the root folder.
Note: It defaults to 8090 if no port env var is provided.
Step 4: Linking Package with Environment
Next, you have to link your App JAR file to the Environment that you previously created, this is done by making sure EB will have access to that file within the project code.
Let’s update its configuration as follows so that it locates it in the root folder:
Step 5: Deployment (eb deploy –staged)
Finally, let’s deploy the App to the related environment with the command: eb deploy --staged, more options can be provided to this command, as the label (–label) which is used as the deployment version name, and the official documentation highlights all the available options.
EB isn’t only used to deploy Apps as part of a migration process, it’s possible to scale them as well. This aspect is covered as part of the Cloud Migration Series that we started on the Lift And Shift way and it’s available on YouTube:
Trick: The command eb open will open the generated deployment domain name in the default browser but you won’t see anything magic since our App is an API (no UI).
The deployment is overridden and we no longer see the sample application, feel free to use Postman to test it as illustrated in the video.
———————
We have just started our journey to build a network of professionals to grow our free knowledge-sharing community that’ll give you a chance to learn interesting things about topics like cloud computing, software development, and software architectures while keeping the door open to more opportunities.
Does this speak to you? If YES, feel free to Join our Discord Server to stay in touch with the community and be part of independently organized events.
———————
If the Cloud is of interest to you this video covers the 6 most Important Concepts you should know about it:
Conclusion
The “Lift And Shift Cloud Migration” is an easy process that any team can apply with very little Cloud experience, but you still have to do your due diligence to pick up the right service or platform to move forward with.
Thanks for reading this article. Like, recommend, and share if you enjoyed it. Follow us on Facebook, Twitter, and LinkedIn for more content.
![Java Interview Questions and Answers for beginners [2024]](https://assets.numericaideas.com/2023/12/Java-Interview-Questions-and-Answers-1300x731.png)
