Is it better to have one web app or multiple web apps

Question

I am going to develop a server application to provide the functionality of a book keeping software in tomcat server. I can think of two ways to achieve this.

1. Creating a single web application - Let's say we have to provide invoice management, user management and report management. All these logic is bound to this single web application. Functionalities will be separated by package structure.
2. Creating multiple web applications - Create separate web app to provide each functionality. ex: single web application for invoice management, another single web app for user management and so on.

One advantage I can think of creating multiple web apps for each functionality is loose coupling. ex: Developer doesn't want to concentrate on invoice related things when he develops on user management module etc. Another advantage is if one customer wants only a sub set of all the features available, We can remove other web apps easily and provide a solution quickly. I wanted to know pros and cons of these two approaches before going to implementation.

Answer 1

If you want to go for maximum scalability you could go for several apps, for example (but not necessarily) implementing the principle of microservices.

Having several apps, allows you to spread the apps more easily accross several web servers, or containers (like Docker or Microsoft's nanoserver) to quickly manage an internet level load peak. In this respect, the monolithic app is not such a good idea anymore for the web.

In both case, you have still the choice of the database and data model: you could for example let several apps connect to the same database. THis has the advantage of realtime synchronisation and consistency. However this will also become the main bottleneck and obstacle to scalability.

This is precisely an aspect promoted by the microservice architecture: each "service" ("app") its own database, so that each "service" could also evolve at its own pace with less risk of breaking data structures used by other apps/functions.

Answer 2

It will help you to choose the right architecture for your application.

Criteria for choosing microservices:

• Complex app. Your app is complex enough for integrating new tools or it experiences issues with the load that cannot be solved by vertical scaling or it is unprofitable in this case.

• Plan to grow and scale the app. Your project experiences a stable load growth and you plan to integrate new tools, but there are chances that the app will reach a critical point when scaling issues may appear.

• Experience with microservices. There are developers in your team who are experienced in designing and deploying microservices to production and you are sure that there will be a part of the team who will support and develop the main app while they are working on microservices.

• Utopia. You have enough money, loyal managers, and extended deadlines.

Answer 3

In principle, you are asking the heavily debated question of monolith (everything in one application) vs microservices (splitting functionality up into multiple services). In my opinion, there is no clear answer to that question when it comes to new projects.

What we know from experience is that in the beginning you can get away with having everything in one application. Eventually, you might reach a point where you are forced to break it up for technical reasons (scalability, easier deployments, etc.). The question is when should you start breaking it up?

You can err in both directions. Avoiding multiple services, even though it would reduce the complexity of the system can be a mistake, but also splitting it up too early when you do not know yet what you are building. The latter is not uncommon in the initial phase of a project. On the other hand, not thinking about how functionality could be broken up, can be costly later, as it will get harder and harder to make the necessary changes.

Both monoliths and microservices have different pros and cons. Monoliths win in terms of refactoring (it is easier to change the interface of a function than of a remote API), but micro services are superior when it comes to scalability.

In terms of complexity, microservices tend to be superior even for medium size systems, especially if they are well designed. Otherwise, you can also end up with a distributed mess that can be harder too understand than a well-built monolith. The larger the system becomes, the more it will favor microservices.

In the early stage of a project, my personal recommendations would be:

• If you already have a good understanding of the domain (e.g., if you can build on the experience of an already existing working system), you can more aggressively start with a micro service architecture
• If you are unsure whether functionality should be split up or not, leave it together for the moment, but ideally make it easy to break it up later (Bounded Context is a concept that can help)
• If you are not sure whether your application will be successful, be more inclined to go for the monolith first. (While it is true that all big companies run on micro service architectures, it is also true that most projects will never get even close to the number of users of Facebook or Google.)

Martin Fowler looked into the subject in this Monolith First article:

As I hear stories about teams using a microservices architecture, I've noticed a common pattern.

1. Almost all the successful microservice stories have started with a monolith that got too big and was broken up
2. Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.

This pattern has led many of my colleagues to argue that you shouldn't start a new project with microservices, even if you're sure your application will be big enough to make it worthwhile.

But he although points out that not everyone agrees: Don’t start with a monolith

Answer 4

A single web app.

Go for the MVP!