Analyze compute footprint of Spring Boot & Quarkus Application, by deploying on Openshift
Part 1 Can be read here
In Part 1 of this story , we have read the migration steps of existing spring boot application to Quarkus based one. This part contains the deployment phases , executing both on Openshift and analyze their corresponding compute footprint.
Deployment Steps :
Post verify the applications in local system it is time to deploy all in cloud (in our case it is Red Hat Openshift). We will have one namespace and will use S2I method to deploy all the services in same namespace.
- Create and logged in to the namespace ‘springboot2quarkus’. Snapshot below.
2. Deploy the back end service: Logged in to Openshift web console in developer perspective.
Topology => Import from Git=> provide git url => place ‘/emart-backend’ in context Dir => select java as
Builder Image => select ‘openjdk-11-el7’ as Builder Image Version => put ‘emart-backend-service’ as application name => unselect ‘Create a route to the application’ as we do not need route generation, cause it is back end service and we will not expose to beyond cluster internal network. Edit the service to expose it in port 8081 because from front end service we will connect it @ http://emart-backend-service:8081/
3. Deploy the spring boot front-end service : Follow the same steps as discussed above to deploy this. After the build Open shift web console topology will appear as below.
4. Verify the application : Clicking the route (ticked in above snapshot) we can verify the application in browser. Here you can verify
Add/update read/del etc. Rest functionality.
5. Deploy the Quarkus based frontend service: There is little file level requisite to deploy quarkus in OpenShift using s2i. Below steps to follow.
o Create a hidden directory called .s2i at the same level as the pom.xml file.
o Create a file called environment in the .s2i directory and add the following content.
o Commit and push your changes to the remote Git repository.
o Login to Openshift using oc command and set targeted namespace i.e. ‘springboot2quarkus’
o To import the supported OpenShift image, enter the following command:
o Next is to command the deployment, where we pass the git path with the context directory where our project exists and application name.
>> oc new-app openjdk-11-rhel7 https://github.com/abhiroopghatak/emart-app.git — context-dir=frontend-emart-quarkus — name=quarkus-emart-frontend
o As the Quarkus app is the front end one so we must expose its service and get the corresponding route.
o Use the Quarkus $route/userdata.html in browser to check the application and verify its functionality, which is same as we have experienced in spring boot front-end app.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — -
Analyze compute footprint and compare both apps:
At this stage we have two front end application (spring boot & Quarkus) connecting to same backend service and provide same functionality and deployed in Openshift. We can log in to metric dashboard and get their compute footprint.
▪ Memory / CPU & filesystem Usage: We can see Quarkus app is using less that spring boot app.Below is snapshot for Spring boot app.
Below is the snapshot of Quarkus application. Notice its usage and compare with above one.
▪ Application Restart time: In the cloud pod restart is common thing. So, the application pod if goes down, the sooner it comes up and ready again, makes it more resilient. To compare this attribute among our spring boot and Quarkus app we deleted both the pods and check the log in newly
spun pods . Spring boot app took 5.76 seconds to comes up where as Quarkus has taken only 1.636 seconds.
▪ Build Time: If we check the builds corresponding to Quarkus and spring boot app, we notice spring boot app wins here.
Conclusion:
On comparing the footprint, we found that runtime is very less in Quarkus and very resilient in cloud. If we develop the app from scratch, it will be much easier in Quarkus and even if we migrate from existing spring boot app it is straightforward. The API dependencies play a big role in that. Except for explicitly setting the parameter name, it is seamless. I ’ve managed to complete the migration in one week. It was very interesting and challenging week and I have learned a lot for Quarkus during this time and I am sure that the next micro-service migration will go much more smoothly. And based on compute footprint analysis it will be wiser to select Quarkus in my next java based micro-service project.
