2

Most architecture design discussions I'm seeing discuss both micro services and monoliths and the trade offs between two.

For the average corporate neither of these architectures in their purest form are suitable. Organisations often have multiple applications talking to each other that are not really micro services and not really monoliths.

Is there are common terminology for this and if you are giving this answer can you pleas provide some reference links as well.

3
  • Why do you care what other people call it? Jun 30, 2020 at 22:54
  • Microlith? Big Ball of Mud? Shantytown?
    – Jon Raynor
    Jul 1, 2020 at 18:03
  • MonoLite? Macro Services? Jul 2, 2020 at 13:16

1 Answer 1

2

There are a lot.

At one end, you have the monolith, a single deployable entity that represents your entire system. At the far opposite extreme, you have microservices, small, well-bound, loosely-coupled, independently deployable pieces that form the system.

Between those, you have many different architectures.

I would consider the "majestic monolith" to be a special case of the monolithic architecture. Like a monolith, the majestic monolith is a single deployable entity. From the outside, it looks the same as a monolith. However, from the inside, there is great care to isolate different pieces or modules with well-defined interfaces between each of the modules.

You also have service-oriented architectures. I consider these to be a precursor to the microservice architecture. The pieces tend to be loosely-coupled, but they may be larger and not all of them may be independently deployable.

You also have multitier architectural patterns. Since a monolith is a single deployable entity, the deployment would account for the view layer as well as any APIs and data model. However, you could separate that out into a view layer and a data layer as two separate deployable entities. Perhaps even three tiers - a view layer, an API layer, and a data layer. And your view layer may even be a web view and a mobile app view. They aren't end-to-end services and have some level of coupling, but could possibly be independently deployable.

It's a good point that most people tend to talk about "monolith" versus "microservice", but most applications tend to be somewhere in the middle of those extremes. Since it's a spectrum, there are lots of options somewhere in the middle. Rather than having names for all of those arbitrary middle points, it's useful to talk about being more like one of the two endpoints, and perhaps having a few somewhat well-defined concepts in the middle.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.