5 ms·

I've spent a lot of time over the past couple of months thinking about how it would be great to move to microservice architecture to help with the "ball of mud"

I've spent a lot of time over the past couple of months thinking about how it would be great to move to microservice architecture to help with the "ball of mud" our codebase has turned into. The benefits seem really great, but it's such a daunting hill to climb. You can't just have a couple different services and boom everything works. You need to worry about consistency, efficiency (e.g. no database joins), and so many other things. Then there's a question of how do you handle things that used to be simple-- i.e. a POST request maybe used to return an id but now it just returns 201 and that's it since you have event sourcing and the instance is eventually created. In the end, I wonder how many companies really need microservices. What if boundaries between apps were actually enforced?

progre 6y ago
You can still have isolation of responibilities between modules, like "this module only reads and writes to that database schema". Modules combined with appropiate glue then makes a service that is "fat" in responibilities but lean in network latencies. Code reviews that also checks that module seperation is maintained really helps.
- jzoch 6y ago
  Id go a lot further and say you should invest a ton in enforcing module boundaries automatically. Shopify's approach to writing their own package manager comes to mind - you cannot rely on code review to keep code clean. Entropy will naturally lead to boundaries broken down. If you want the separation of microservices with a network to enforce it you need robust tooling to enforce that.
  - lifeisstillgood 6y ago
    do you have any links re that shopify package manager - google seems to confuse software and postal wrapping...
    - grncdr 6y ago
      I believe GP is referring to https://engineering.shopify.com/blogs/engineering/enforcing-modularity-rails-apps-packwerk https://engineering.shopify.com/blogs/engineering/enforcing-... Previous discussion: https://news.ycombinator.com/item?id=24571423 https://news.ycombinator.com/item?id=24571423
  - swsieber 6y ago
    In java land, I have found multi-projevt gradle builds and copious tests have gotten us pretty far without needing to resort to a custom package manager.
    - Tainnor 6y ago
      multi project gradle builds are a god-send
Cthulhu_ 6y ago
I think it's not really microservices you pine for, but it's being able to untangle said ball of mud into discrete and - more importantly - manageable codebases. 100K LOC is hard to work with, but 10K is manageable. I do think that's why developers idealize the microservices architecture; they don't want to have to keep 100K LOC in their head, or work with 10 other developers; they want to tend to their own 10K LOC garden, they want to isolate a problem space and focus on that, instead of the big picture which is too much for any one person to deal with.
- hackerfromthefu 6y ago
  I absolutely agree, and that's delivered by simple modular architecture over well designed interfaces. Adding runtime networking and server management complexity to that is a completely different things though!
- yeswecatan 6y ago
  You're absolutely right.
hackerfromthefu 6y ago
Have a look at "refactoring legacy code" by michael feathers I think it was. The book is a bit old, about process not fad technology and the age has affected it not at all. It's describes the accurate and correct process to fix the problem you describe.
mamcx 6y ago
> efficiency (e.g. no database joins) This is WRONG. I was in a team that somehow think that could make a decent software without using postgresql as-is. Is wrong: How many devs know how implement, CORRECTLY, ACID? ALL OF ACID? Then if "remove" for "efficiency" the single piece of software that ACTUALLY implement it, CORRECTLY, what exactly them expect? Well, them were running in circles, avoiding ACID, being very efficient running 12 docker images (!) and not implementing actual features. I left because I point to this and was deemed not good fit. With relation to microservices and all their past selves (n-tiers variations) the best advice is: Use a rdbms, properly Maybe, add a cache as redis. End. This is all you need for the vast majority of apps. And it will scale, and will perform very well. If it NOT scale and not perform very well, then is MORE likely that the app code is wrong than PostgreSQL/Redis to be wrong. MORE.
tmd83 6y ago
Exactly this. Even if I forgot all the complexity of distributed architecture, tons of new failure. condition, the conversion to microservice what about the efficiencies. I have quite a few core objects/tables that everyone use that anyone can join or use in their ORM mapping and what happens if they are all in a separate schema and microservice.

progre 6y ago

You can still have isolation of responibilities between modules, like "this module only reads and writes to that database schema". Modules combined with appropiate glue then makes a service that is "fat" in responibilities but lean in network latencies. Code reviews that also checks that module seperation is maintained really helps.

jzoch 6y ago
Id go a lot further and say you should invest a ton in enforcing module boundaries automatically. Shopify's approach to writing their own package manager comes to mind - you cannot rely on code review to keep code clean. Entropy will naturally lead to boundaries broken down. If you want the separation of microservices with a network to enforce it you need robust tooling to enforce that.
- lifeisstillgood 6y ago
  do you have any links re that shopify package manager - google seems to confuse software and postal wrapping...
  - grncdr 6y ago
    I believe GP is referring to https://engineering.shopify.com/blogs/engineering/enforcing-modularity-rails-apps-packwerk https://engineering.shopify.com/blogs/engineering/enforcing-... Previous discussion: https://news.ycombinator.com/item?id=24571423 https://news.ycombinator.com/item?id=24571423
- swsieber 6y ago
  In java land, I have found multi-projevt gradle builds and copious tests have gotten us pretty far without needing to resort to a custom package manager.
  - Tainnor 6y ago
    multi project gradle builds are a god-send

Cthulhu_ 6y ago

I think it's not really microservices you pine for, but it's being able to untangle said ball of mud into discrete and - more importantly - manageable codebases. 100K LOC is hard to work with, but 10K is manageable. I do think that's why developers idealize the microservices architecture; they don't want to have to keep 100K LOC in their head, or work with 10 other developers; they want to tend to their own 10K LOC garden, they want to isolate a problem space and focus on that, instead of the big picture which is too much for any one person to deal with.

hackerfromthefu 6y ago
I absolutely agree, and that's delivered by simple modular architecture over well designed interfaces. Adding runtime networking and server management complexity to that is a completely different things though!
yeswecatan 6y ago
You're absolutely right.

hackerfromthefu 6y ago

Have a look at "refactoring legacy code" by michael feathers I think it was. The book is a bit old, about process not fad technology and the age has affected it not at all. It's describes the accurate and correct process to fix the problem you describe.

mamcx 6y ago

> efficiency (e.g. no database joins) This is WRONG. I was in a team that somehow think that could make a decent software without using postgresql as-is. Is wrong: How many devs know how implement, CORRECTLY, ACID? ALL OF ACID? Then if "remove" for "efficiency" the single piece of software that ACTUALLY implement it, CORRECTLY, what exactly them expect? Well, them were running in circles, avoiding ACID, being very efficient running 12 docker images (!) and not implementing actual features. I left because I point to this and was deemed not good fit. With relation to microservices and all their past selves (n-tiers variations) the best advice is: Use a rdbms, properly Maybe, add a cache as redis. End. This is all you need for the vast majority of apps. And it will scale, and will perform very well. If it NOT scale and not perform very well, then is MORE likely that the app code is wrong than PostgreSQL/Redis to be wrong. MORE.

tmd83 6y ago

Exactly this. Even if I forgot all the complexity of distributed architecture, tons of new failure. condition, the conversion to microservice what about the efficiencies. I have quite a few core objects/tables that everyone use that anyone can join or use in their ORM mapping and what happens if they are all in a separate schema and microservice.