3 ms·

Instead of microservices, I split my projects in tons of libraries and think of them as products, enforcing a well thought of and consistent api (usage api, not

Instead of microservices, I split my projects in tons of libraries and think of them as products, enforcing a well thought of and consistent api (usage api, not http one). I call that an atomized monolith. I get the cool things about microservices: properly isolated functionalities, ability to assign a team on it, simplicity of code and considering each feature as important, not just "that thing in the codebase". But it also have all the good parts of monolith: easy deployment and local setup, aggregation made easy, and ability to run integration tests. For my rails projects, geminabox was of great use for me to achieve this, as it allowed me to host private gems. Lately, I've done a lot of golang, and was surprised to see how it's a natural pattern with go packages. Only hurting part for ruby projects: keeping dependencies up to date in all those libs (since they all have their test suite, it means that I at least have to update them for test dependencies). To solve this, I've built some tooling that will update all my project automatically and create merge requests for them, running from a cron task.

naasking 10y ago
> Instead of microservices, I split my projects in tons of libraries and think of them as products, enforcing a well thought of and consistent api (usage api, not http one). I call that an atomized monolith. There's already a term for that: modularity.
- oelmekki 10y ago
  A word which totally not carries lessons learnt from microservices vs monoliths. But using that name is fine by me, I'm not trying to define other people world, just sharing mine.
  - naasking 10y ago
    I think it does carry those lessons, but most languages are incredibly bad at enforcing modularity. Monoliths make it far too easy to cheat, and dynamically typed languages are typically worse here. Microservices then just forces on you the modularity your language should have already given you.
- pieterh_pvtl 10y ago
  There is a great talk on this by Simon Brown http://www.codingthearchitecture.com/presentations/sa2015-modular-monoliths http://www.codingthearchitecture.com/presentations/sa2015-mo... https://www.youtube.com/watch?v=h_rBDIC51C4 https://www.youtube.com/watch?v=h_rBDIC51C4
pinouchon 10y ago
I think this is a good approach. Many popular libraries put API design as their top priority, sometimes at the cost of clean code. For example, RamdaJS has this principle of "API is king": "We aim for an implementation both clean and elegant, but the API is king. We sacrifice a great deal of implementation elegance for even a slightly cleaner API.". Imo, good "monolith atomization" requires you to do this kind of tradeoffs, and this can be though.
oelmekki 10y ago
Oh btw, forgot to mention this: for rails projects, mastering rails templates and thor is a must have, too, in atomized monoliths. It allows to quickly build rails engines with all the project setup made instantly. You can even build complexe templates that ask for input to toggle features or provide variable values. Yeah, I love tooling :) http://guides.rubyonrails.org/rails_application_templates.html http://guides.rubyonrails.org/rails_application_templates.ht...

naasking 10y ago

> Instead of microservices, I split my projects in tons of libraries and think of them as products, enforcing a well thought of and consistent api (usage api, not http one). I call that an atomized monolith. There's already a term for that: modularity.

oelmekki 10y ago
A word which totally not carries lessons learnt from microservices vs monoliths. But using that name is fine by me, I'm not trying to define other people world, just sharing mine.
- naasking 10y ago
  I think it does carry those lessons, but most languages are incredibly bad at enforcing modularity. Monoliths make it far too easy to cheat, and dynamically typed languages are typically worse here. Microservices then just forces on you the modularity your language should have already given you.
pieterh_pvtl 10y ago
There is a great talk on this by Simon Brown http://www.codingthearchitecture.com/presentations/sa2015-modular-monoliths http://www.codingthearchitecture.com/presentations/sa2015-mo... https://www.youtube.com/watch?v=h_rBDIC51C4 https://www.youtube.com/watch?v=h_rBDIC51C4

pinouchon 10y ago

I think this is a good approach. Many popular libraries put API design as their top priority, sometimes at the cost of clean code. For example, RamdaJS has this principle of "API is king": "We aim for an implementation both clean and elegant, but the API is king. We sacrifice a great deal of implementation elegance for even a slightly cleaner API.". Imo, good "monolith atomization" requires you to do this kind of tradeoffs, and this can be though.

oelmekki 10y ago

Oh btw, forgot to mention this: for rails projects, mastering rails templates and thor is a must have, too, in atomized monoliths. It allows to quickly build rails engines with all the project setup made instantly. You can even build complexe templates that ask for input to toggle features or provide variable values. Yeah, I love tooling :) http://guides.rubyonrails.org/rails_application_templates.html http://guides.rubyonrails.org/rails_application_templates.ht...