Everybody says monolithic applications are bad. I usually hear things like:

• Tiny changes need full redeployment (maybe even with downtime)
• Limited agility
• Easy to get a big ball of mud

So why would you like to have a monolith?

There are many definitions of a monolithic application. There are tons for microservices.

A Monolith has it’s advantages. There are companies which are successful with monolithic applications.

You start faster.

It’s one codebase. All in one editor. Only one team working on it. Why would you split that into multiple projects, thinking about interfaces and deployment? If you start with a new project I would recommend to do it just like that. Dealing with multiple services right from the start adds overhead and complexity which you can avoid.

You can must modularize the monolith.

Even if everything is in one codebase, you can still structure it. Of course we all do it, right? In Java you typically use packages. One trap which you can easily fall into is to structure it along the technology. Does Frontend, Backend, Database sound familiar? I still see that very often, because as programmers we think in technology.

Try to do it along business logic. This is much harder but it will make refactoring much easier because changing a thing in one business aspect is much less likely to break another business case.

Make use of things like private and package protected access. It’s a great way to show the intent of the code to the reader.

Testing is easier.

Since all is in one place. Testing is much easier. It will be never easier than that.

Deployment is easier.

It is one application. How hard could it be to deploy it. Sure it can be, but just like testing…it will just grow from here. Enjoy it while you can.

So why change that?

Good question.

If you have a (relativly) small code base and one team. I guess it should stay like this.

If the project grows in terms of team members, teams and/or code base you will start to have a new slew of problems.

More people means, more intercation, more explaining, more code/architecture styles … well more of everything.

At this point you might need to think about splitting the code. If you did the base work in the monolith already you might have a good start into the world of distributed systems. You need to carefully think about if you want to move the complexity one level up and how you will manage it there.

If you did not modularize your monolith, you end up with big balls of distributed mud later.

If you can’t build a monolith, what makes you think microservices are the answer?

To cite Martin Fowler:

First Law of Distributed Object Design: “don’t distribute your objects”.

It’s hard.

If you want to learn more about microservices and monoliths come and join us at the microXchg 2015 community conference in February in Berlin, Germany.

Picture by Antonis Lamnatos licensed under Creative Commons 2.0