The distributed monolith antipattern


The words distributed and monolith are usually adversaries in software architecture, contrary to the monolith model,  a distributed approach will allow you to have isolated services as building blocks of functionality for your system. Let's assume you reached that architecture already, either from scratch or by decomposing an existing monolith. At this point you have a set of services. 



Some people go and just say - "it's microservices!". Well..., that's not enough yet, but now you have all the pieces into individual services and the whole system working together.  This is a step into the right direction for scalability, but we can do more in other areas. 

So, let's check: how do you deploy them?

If you deploy all services at once, you still have a lot to improve, for now you have a "distributed monolith" (Open to a better name for this), which I consider to be an antipattern, and this is more of a common practice than expected, this is basically a problem inherited from Service Oriented Architecture but there are a few reasons it happens.

Common reasons


1. Services share the same database.
This is old as time, it's OK for this to happen during transition from monolith or classic SOA to microservices, but you need to move away from it. Sometimes organizations just don't pour resources to continue moving forward with the evolution of a system.

2. Deployment constraints tying them together. 
Some DevOps limitation, rule or result of laziness (e.g. somebody liked how things looked in one docker compose file and left it like that).  

3. Shared library with business logic. 
Another bad practice from SOA, a developer encapsulated business logic into a library, then new business updates require all apps and services to be updated and deployed almost simultaneously.  Reusability is important in software but doing it through libraries when using services is a Pandora's box. If you have a service-based architecture, expose business logic only through services.  


Notes.
You can find almost any reason to justify what could be seen as a bad practice, it's up to you, the developer, to decide how to proceed. For example, sometimes you *have* to share a database because consistency is more important than speed or scalability for a specific application. If a requirement like that exists, then you are already building the correct system and there is no need to modify it just to fit with an architectural schema.  

Comments

Post a Comment

Popular posts from this blog

Get-ChildItem vs Dir in PowerShell

Image
Batch as usual Recently I was in the need of modifying a huge amount of files across a network share. After installing Serviio media streaming service I noticed that it will crash "randomly". After checking the logs it was clear that ffmpeg was crashing when trying to open subtitle files that were not in the encoding indicated by the Serviio console. I needed a quick way to update all subtitle files to a common encoding, so I decided to convert all files to UTF8. Since I use a windows environment I went directly to PowerShell and wrote this.  Get-ChildItem -path .\ -filter *.srt -file  | ForEach-Object { (get-content $_.FullName) | Out-File $_.FullName -encoding utf8 } This worked almost right except for files with "[" or "]" (among other symbols) on the name or path. To solve it, just added the "-LiteralPath" switch to tell powershell not to consider any wildcards on the path name and just use it exactly as it is.  Get-ChildIt...
Read more

The case for a 4 week sprint

Image
Every time we talk about SCRUM, the length of the sprint is stated as a period of "two to four weeks", rarely, however, have I seen people going outside of the 2 weeks. This is not written on stone of course, and while 3 weeks might seems odd, there is a benefit to using a longer period for your sprints.  Image is taken from scrum.org Without any hard data to back that decision, the answer I get from asking about this decision seems to be related to "delivery speed", we assume that because we deliver value to the business every 2 weeks, we are in a more "agile" environment. Well, that might not be so true in every sense or for every project. Let's break some arguments: 1. Sprint length is not equal to the speed of delivery There is more to the speed of development and delivery than the timeframe of the delivery cycle, in a world with DevOps and full CI/CD implemented for your project, you could (should?) actually deliver features every single day all t...
Read more

NODE.js fs.readFile and the BOM marker

Working on a ReactJS project, got a small glitch while trying to read a JSON file and parse it as a javascript object. getDataObject() { var dataString = fs.readFileSync("./json/data.json", "utf8"); return JSON.parse(dataString); } output:   SyntaxError: Unexpected token   After checking, double and triple checking again that the file was correct I went deeper and realized that "fs.readFileSync" was returning me the BOM for the UTF file at the beginning of the string. So we just need to strip it out. getDataObject() { var dataString = fs.readFileSync("./json/data.json", "utf8"); return JSON.parse(dataString.replace(/^\uFEFF/, "")); } I then checked and there are "packages" for this, however I don't think is proper to just import a new dependency just to fix something this small. The big issue here is why is this considered correct. The BOM is not ...
Read more