Learnings from modernizing a JBoss EAP/FUSE based system
As part of one of the projects we embarked on a journey on converting a JBoss EAP/FUSE based system to SpringBoot Microservices. Some of the reasons why one might want such an upgrade are:
Improve operational efficiency by reducing the technologies across landscape
Reduce license cost by using opensource free frameworks
One should break down the whole system into smaller logical components which can be upgraded and released independently. It goes without saying that one would require a discovery phase before each unique technology component combination. These should be demonstrated by Proof of Concept’s before embarking on the journey.
Uncover hidden issues in existing system
We moved away from unsupported local DB to Cloud based DB. In our performance testing we found that some of the UI features load time had increased exponentially. In such scenario’s the Round Trip Time (RTT) is the Usual Suspect as RTT for local DB was ~1ms compared to ~20ms for cloud based DB. This might not look huge for a single query but what about 100’s or 1000’s of such queries? Though in our case we found that the ORM was doing more queries than required. We were hitting the N+1 DB issue. This issue didn’t surface earlier due to low RTT but with larger RTT’s response time deteriorated significantly. After trying various fixes like upgrading JPA version, eager fetch etc., we resorted to converting this to native SQL’s join statement which did the trick for us.
Prepare to invest in throwaway code
Some of the legacy components might not integrate well with latest technologies. We faced an issue with SpringBoot microservice, where they were unable to communicate with the legacy MRG-M queues. To overcome this, we had to deploy a FUSE bundle which worked as a message bridge between MRG-M (legacy queue) and RabbitMQ (new queue). Though this was a throwaway code it enabled us to move ahead with our re-architecture. It also enabled us to migrate the component in multiple iterations instead of attempting for one big-bang approach of replacing one queue with another.
Accept failure
In such technically challenging projects one should be ready to accept failures. We had several components which were using Apache CXF to host the services and Apache camel for message translation. We faced failures when we tried to move the SOAP based web services to REST WS due to the number of changes required. And then again when we tried to setup Apache CXF + Apache Camel in SpringBoot. Though this gave us better understanding of the landscape enabling us to resolve it finally.
