My first web application has been written in 2000 or 2001 and it was composed of two parts:

• HTML front-end produced by an ISAPI DLL (created in Delphi)
• DBF database

A couple of years later, thanks to the experience acquired with the first project, the architecture changed with the introduction of servlets and a more suitable database:

• HTML front-end produced by JSP/Servlet and database query executed using Ajax
• Java Servlet container
• Oracle database

Once we started to display data using the web there were the requests to produce data too and so a more maintainable solution was required: please, a big round applause to Spring Framework !

The big debate at that time was about the best backend framework to use: Spring or J2EE ? At that time I was involved in a project for one of the biggest bank in Italy and they were using J2EE: I hated it ! It was complicated, untestable (I’m a big fan of TDD) and there were no way to test the EJBs, and each manual test required to start the local server and wait, wait… wait. So for me Spring was the obvious decision.

I started with the beta of Spring 2 and I continued with Spring 3. In the meanwhile I adopted Flex 3 and front-end to avoid all the problems related to the differences of the browser (and I was a big step forward compared to JSP/Servlet/Ajax/Struts/JavaServer Faces that I used before fall in love with Flex: stability, portability, easy and quick development)

One and a half year ago I bought on Amazon a small book ‘Write Modern Web Apps with the MEAN Stack’ because Flex was dismissed by Adobe, Flash wasn’t so popular anymore, and I needed to find urgently a new framework for the next generation of the services I was going to develop. This book started a process:

1. I studied ‘MEAN’: MongoDB, Express.js, Angular JS, node
2. Was the NoSQL  a good option for the new generation of the services to replace MySQL and Oracle ? NO. Dismissed.
3. Were Express and Node a good alternative to Java Spring ? Lot of doubts: I needed more researches because I saw some advantages but I had already a working backend in Java and Spring, it wasn’t perfect but it was good enough. Dismissed.
4. Was Angular good enough to replace Flex ? I started to follow online courses about it, but almost immediately I discovered React and so I started to follow online courses about it too.

The choice between Angular and React will be the content of another post, but the study of Node and Express for the backend opened the door to something different: I discovered that Oracle has dismissed EJB in favour of Web Services (that I don’t like at all) and Restful Services with JAX-RS, and I watched lot of video created by Adam Bien about Java Microservices. I bought three courses that he is selling online, I started to create some microservices and immediately I started to see some benefits:

• The architecture of a microservice as taught by Adam was mapping the same architecture I was using with Spring (a good architecture means: order, a well defined process in the development phase, a process that can be taught to other people and that can follow easily to produce consistent code)
• Each microservice created was very small: fast compilation, fast tests, quick deploy, fast updates

But one question was unresolved: was it possible to create the new release using microservices instead of the existing monolithic backend ? Yes, but I needed to solve the problem of the orchestration of the microservices.

I have analysed the existing monolithic backend and I’ve found that the use of JMS would have solved the problem of the link between the microservices; all the remaining links between the microservices would have been centralised in two other microservices: one used by the mobile App that produce the data, and the other used for some specific features by the Web application and the App that displays the data acquired on tablets and smartphones.

Here is a diagram of the architecture:

And here is a short description:

• Each microservice (in blue) has a public interface used by: Web Application, Analyser App, Web Microservice and Mobile App microservice
• Each microservice (in blue) can send message to other microservices and can receive messages from other microservices using the JMS Service
• The JMS Service (in green) is used only by microservices
• The Mobile App microservice (in gray) is used only by the App that creates the data and it’s the only microservice used by that App
• The web Application and the Analiser App can consume the data provided by each microservice and they uses the Web microservice (in gray) to receive realtime notification and to require data that involve the query of more then one microservice

Six month after I started to create the new microservices, I have already in production:

1. The new release of the Mobile App that can use the new microservice architecture and the old one (in the next six month all the customers will migrate to the new backend)
2. The new Web application written in React
3. The new Analyser App
4. The new backend system is working perfectly, and every week  I add new features and services used by the customers

The biggest advantage of the microservices architecture is that each change and each new feature added to the client applications has a very small impact on the full infrastructure: 95% of the time I update a single microservice and after that the Apps and the Web; the rest 5% of the time it may requires a small update on the Web Microservice.

My biggest scary was the Web Microservice: would it grown in a very complex microservice ? After six month I can say that it’s still very small, simple to manage and it is updated less often then expected.

As you have understood my experience was and is very positive, the architectures works quite well and the quality of the services is quite high.

And what about the drawbacks ? At the moment there are no drawbacks but, where there will be one, I will keep you informed.