DEV Community

loading...

Monolith or Microservices

chis0m
...here to learn.
・2 min read

Monolithic application has single code base with multiple interdependent modules. Also known as Integrated systems.

Microservices is breaking down large application into highly independent units called services. It can also be called Distributed Systems.

So the key concept here is level of Dependency.

Highlight of Characteristics of both
Alt Text

Questions to answer before considering Microservices

  1. Do you have a complete understanding of what microservices are and how they could influence your development operations?
  2. Is your business mature enough to adopt microservices?
  3. How strong is your practice of application infrastructure?
  4. Do you have a tried and tested agile or DevOps practice?
  5. Is your data management team skilled enough to support the incorporation? If it’s a no for this one, they will only slow down what is supposed to be a swift process.
  6. Is your product at the fulcrum of your business model?
  7. What are your goals and vision on scaling up? The architecture is designed for scalability and is ideal only if you have a sound plan of expanding both your product/service and your market.
  8. Is your business model tested and proven?

Here is a thought on Microservices or Monolith:

So my primary guideline would be don't even consider microservices unless you have a system that's too complex to manage as a monolith. The majority of software systems should be built as a single monolithic application.Do pay attention to good modularity within that monolith, but don't try to separate it into separate services... unless you're faced with that complexity, remember that the microservices approach brings a high premium, one that can slow down your development considerably - Martin Fowler.

What to do?

There is an architecture that combines the simplicity of monolith (in terms of architecture and deployment) with the logical advantage of microservices. It is the Modular Monolith (Modulith).

For a typical Laravel application, you could leverage namespaces, service providers, autoloaders, packages, API routes to totally separate these modules. There is a package that could help with this. Check it out here: nwidart/laravel-modules.

click here and here to read more on the package usage.

In a nutshell, each module will have its own model, providers, config, route, migrations etc.

On a final note, as an application grows the best question to ask is how to structure your application in such a way that it will reduce interdependency among modules. So that when it becomes very large you can easily go microservice.

Discussion (0)