No, I am not talking about this blog, but about the evolution of the monolithic Java application I spend most of my time on at work. This application is a good old ear deployed on a venerable Glassfish 3.0.1. It works well, but does not meet completely our customers needs for today use. Although some features are used on a daily basis, others are completely useless today and dealing with them to create new features leads to spaghetti code. Fortunately, business is growing and the company is expecting a larger audience for the application scaling up to 100 or even 1000 times the average usage we are dealing with today. Scaling was not really in mind when the first system was designed so, this will lead us to a cleanup, to keep meaningful features, remove the useless ones, and a good opportunity to start from scratch.

Learning from the past

Our application will include a mix of traditional bits (basic CRUD stuff) a whole Internet of Things aspect and even some real time statistics and communication. Of course, when starting from scratch, you have to think about architecture and technologies. Obviously we do not want to reproduce the same mistakes as previously. So first, let's analyze that.

Deployment

The first thing I noticed quite early when I joined the company was how hard it was to deploy in production and sometimes even harder to setup an development environment on my machine.
The cure for this one will be to use configuration management tools such as Ansible which we stated using (but a bit too late).

Separation of concerns

In the growth of business, there are some turnarounds, some strategical decisions, some pivoting done. The customer changes, the target evolves or the needs themselves evolves. In a 5 years old application, this leaves traces : design decisions, technologies, features, ideas not completely implemented,... The mistake here lies in the fact that every single investigated concept during 5 years, is connected to each other. So, in some cases, we have a neat feature, done fairly right interacting with a clumsy proof of concept based on a really stable piece of software. This was a nightmare to maintain and is the main cause of side effects, which are, of course unwanted.

What's next ?

After some investigation, we expect to build our new app in a microservice architecture fashion. I was personally inspired by the one described by iHeartRadio.
As we already use Scala (actually even on top of our old stack, we use mainly Scala now), it is not at all a problem for us to write Play apps or Akka apps.
On the data store level, we are currently experimenting with CouchDB (coupled with PouchDB) for mobile synchronization. We also plan to use Elasticsearch and Cassandra. So, in the near future, expect some blog post related to these topics :) !