Monolithic applications are not always inevitable. Micro-services architectures

The application in question is a 15-year-old monitoring application that is still developed in the same way but by a multitude of contributors, both internal and external.

The technologies used are Struts 1.x, Java, an improbably-persistent framework and a large number of stored procedures.

The height of happiness for both the developer (What?! Are projects still being produced using this tech?) and the user (with a "blank" when pages refresh) and even for the application manager (security issues, staffing, maintenance costs, etc.).

After nearly 3 years, I left this project because I thought I’d seen everything there was to see and, above all, I couldn’t take it anymore!

Nevertheless, it was a good experience and I met lots of great people, and I’d always thought we needed to stop doing things this way and decided to rewrite this app.

After a 3-year break, in 2014, the customer wanted me to get on board as architect/tech lead on a new project. Of course, we treated ourselves, using all the latest fashionable frameworks and a state-of-the-art user interface (based on 1.x angular and bootstrap).
With the project finished and success guaranteed, it was time to return to that monolithic app with this crazy idea of starting over.

Doing things differently, yes, but how? Stopping developments for a multi-month rewriting period was not an option. Then, I had the opportunity to attend Devoxx conferences in Paris in 2014, which particularly focused on micro-services architecture. One of these presentations told the tale of rewriting a full project using micro-services.
The solution was staring me in the face!

It was the best approach to finally put this monolithic app’s work-intensive and time-consuming development cycles to bed. Making things smaller, much smaller, using independent parts.
So I learned about micro-services architecture, prepared the environments, and “evangelised” the different stakeholders.

We had to meet a new particularly niche business demand. Tracking exchanges between the application’s different users. Therefore, we had an opportunity to prove its feasibility.

I started writing a new application, only handling this very specific need, to be added to the monolithic app. An Angular application run parallel to the Struts monitoring application.
One evening, as I was finalising my ‘POC’, the project manager saw how both projects could be jointly integrated. Three was a new tab on the left-hand side of the existing application: by clicking on it, a panel slid over to reveal all the features of this communication module.
She was pleasantly surprised with the result and finally saw proof that it actually was possible to do things differently.

All that was left to do was to set up the back-end with all the components needed to make this type of architecture work and get the infrastructure team on board for the adventure.

Today, 25 micro-services and 2 Angular applications (1.x and 5) run on this platform and it’s only the start!