6 ms·

Microservices are just one option of refactoring that can be considered at later stage of life of the system. Even big guys who are using microservices started

Microservices are just one option of refactoring that can be considered at later stage of life of the system. Even big guys who are using microservices started with monolith. Many people can't seem to catch this important detail - they started as monolith that was later refactored/modularised/split/microserviced. It doesn't mean, the moment they did it, that humanity found a better way of writing software called "microservices". It just means that, at that stage of life of the project, it made sense. Starting with monolith is still, in most cases, the best way to write projects, even if later they evolve into microservices. Starting projects with maximum split into microservices is, in most cases, just a plain, stupid idea. The most important part when starting project is avoiding friction at all levels - from dev setup, contribution, deployments, database evolution (migrations), interaction between different parts of the system (it's easier to just call a function from a module than to do rpc - which involves implementing rpc on the other side, managing it's deployment, keeping interfaces in sync etc)... Microservices are for mature services with crystallized interfaces. They emerge naturally and the split is obvious at later stage - this information is not available at the beginning.

ChicagoBoy11 9y ago
I've mostly focused on front-end stuff, but it's amazing to me how much advice similar to "start off doing <simple-even-if-perhaps-not-proper> and then later when the problem space becomes clearer or you begin to suffer <then-do-proper-refactor-or-concern-separation>" hits a chord with just about everything I've ever worked on. Even when doing incredibly small front-end projects, I have a hard time thinking about times where I didn't regret optimizing or modularizing things before it was obviously necessary. Would usually later uncover that it was either useless or that I had built the wrong abstractions, needing to start over again. Conversely, every time where I've spun something quickly using the most straightforward patterns and optimized or refactored only when it became abundantly clear that it was necessary, the right way to abstract the code always felt like a no-brainer and I would always end up with very useful abstractions which allowed me to build meaningfully on top of them.
- pdimitar 9y ago
  As a full-stack dev this is my exact experience as well. As Martin Fowler says in his book Refactoring -- don't go ahead of yourself, code your way out of the business problems, stay on top of your code, refactor periodically (even if it's only to remind yourself what does a module do!) and the best patterns for your project will emerge by themselves.
corpMaverick 9y ago
I think you hit the nail in the head. But it is going to be really hard to convince people otherwise.
Clubber 9y ago
We had a guy who was an OK developer, but he read all these articles about this and that. He decided to make a 2 page application "micro serviced." It contained 56 projects and counting. For a 2 page application. It was the most convoluted piece of garbage I have ever seen.
- eropple 9y ago
  What sort of breakdown was this? Like, I'm morbidly curious.
  - Clubber 9y ago
    It was 4 projects per entity plus a few shared projects: the Dtos, the data, the WebAPI, and the tests; all for each entity.
    - it_learnses 9y ago
      Is he/she now a manager?
      - candiodari 9y ago
        Ask him to put it on github. It can be the new FizzBuzzEnterPriseEdition !
korzun 9y ago
> Microservices are just one option of refactoring Breaking down a monolithic platform into different microservices is not something I would call refactoring. > Microservices are for mature services with crystallized interfaces. You are not making any sense here. What exactly is a 'mature service'? Just throwing technical jargon around? > The most important part when starting project is avoiding friction at all levels - from dev setup, contribution, deployments, database evolution (migrations), interaction between different parts of the system (it's easier to just call a function from a module than to do rpc - which involves implementing rpc on the other side, managing it's deployment, keeping interfaces in sync etc)... Those things are pretty important for any kind of project. > They emerge naturally and the split is obvious at later stage - this information is not available at the beginning. Most microservices are plain boring and extremely predictable. Have an eCommerce site? Then you have a user service, a cart service, payment service, etc.
- mirekrusin 9y ago
  1. Refactoring is pretty much anything that you do to improve the system that doesn't change anything to the outside observer - in other words, your boss can ask you the stupid question "so you've been working all this time, committing changes like crazy and nothing has changed at all?": and your answer is "yes, but...". Extracting scattered logic and encapsulating it into modules (classes, whatever) with clear responsibilities is refactoring for example. Extracting your module into separate dependency package is refactoring as well. Similarly extracting module to some kind of RPC is also a task that falls into refactoring bag - because it doesn't change anything for the outsider. 2. Mature service is your app after several cycles of release. At the beginning the project is just a dance with the client, going in circles, changing things all the time, until she's happy (with at least parts of the system). The thing is that at the beginning you don't know how the system will look like and more importantly - she doesn't know as well. The only tool that we have, that we know works well, is rapid prototyping with quick feedback loop. You want to minimize the friction of changes. She asks you to do something, you do it, then she changes her mind, rearranges things etc - often those changes require schema changes, shuffling hierarchy or adding some indirection layers etc. You can't do it fast if you have to coordinate several microservices to use new schema. You need to promote all of them to the new version and you need to orchestrate it on live, production system. With monolith you don't have this problem, everything is in one place, you run migrations on deployment to bring the system to the new state and presto, you're done. This kind of friction echoes through all environments - from your local dev, through staging to production. If you're working with more colleagues, your changes can easily block others' work. 3. So we agree that avoiding friction is important for any kind of project. I'm saying this implying that microservices are adding extra friction to the development. Instead of just calling function in your system you now have to maintain separate, coordinated, interface compatible service. All changes now need to go to two places. They need to be coordinated on migration/deployment, have their own devops setup etc. 4. ...and then you introduce discount codes, different countries, tax information, translations, connecting users with paypal and what not - all spanning across multiple microservices, you need to duplicate new communication schema across all of them, versioning apis, sometimes managing breaking changes which are pain in the ass in microservice world... all that for what? What exactly are you gaining? Are you really maxing out on thousands of requests per second on any one of those components? Is microservice going to save you because you can scale horizontally? Aren't they writing to the same store that's a bottleneck and scaling out the middleware won't improve anything at all? If they are separate then how are your joins doing when you need to match multiple, cross database collections? For example to update some kind of aggregate information for every user? Or any kind of reporting? E-commerce site with user, cart, payment and all the rest is trivial in monolith webapp as described in full in beginners book Agile Web Development with Rails for example. There's no need to clutter basic app like that with microservices IMHO.

ChicagoBoy11 9y ago

I've mostly focused on front-end stuff, but it's amazing to me how much advice similar to "start off doing <simple-even-if-perhaps-not-proper> and then later when the problem space becomes clearer or you begin to suffer <then-do-proper-refactor-or-concern-separation>" hits a chord with just about everything I've ever worked on. Even when doing incredibly small front-end projects, I have a hard time thinking about times where I didn't regret optimizing or modularizing things before it was obviously necessary. Would usually later uncover that it was either useless or that I had built the wrong abstractions, needing to start over again. Conversely, every time where I've spun something quickly using the most straightforward patterns and optimized or refactored only when it became abundantly clear that it was necessary, the right way to abstract the code always felt like a no-brainer and I would always end up with very useful abstractions which allowed me to build meaningfully on top of them.

pdimitar 9y ago
As a full-stack dev this is my exact experience as well. As Martin Fowler says in his book Refactoring -- don't go ahead of yourself, code your way out of the business problems, stay on top of your code, refactor periodically (even if it's only to remind yourself what does a module do!) and the best patterns for your project will emerge by themselves.

corpMaverick 9y ago

I think you hit the nail in the head. But it is going to be really hard to convince people otherwise.

Clubber 9y ago

We had a guy who was an OK developer, but he read all these articles about this and that. He decided to make a 2 page application "micro serviced." It contained 56 projects and counting. For a 2 page application. It was the most convoluted piece of garbage I have ever seen.

eropple 9y ago
What sort of breakdown was this? Like, I'm morbidly curious.
- Clubber 9y ago
  It was 4 projects per entity plus a few shared projects: the Dtos, the data, the WebAPI, and the tests; all for each entity.
  - it_learnses 9y ago
    Is he/she now a manager?
    - candiodari 9y ago
      Ask him to put it on github. It can be the new FizzBuzzEnterPriseEdition !

korzun 9y ago

> Microservices are just one option of refactoring Breaking down a monolithic platform into different microservices is not something I would call refactoring. > Microservices are for mature services with crystallized interfaces. You are not making any sense here. What exactly is a 'mature service'? Just throwing technical jargon around? > The most important part when starting project is avoiding friction at all levels - from dev setup, contribution, deployments, database evolution (migrations), interaction between different parts of the system (it's easier to just call a function from a module than to do rpc - which involves implementing rpc on the other side, managing it's deployment, keeping interfaces in sync etc)... Those things are pretty important for any kind of project. > They emerge naturally and the split is obvious at later stage - this information is not available at the beginning. Most microservices are plain boring and extremely predictable. Have an eCommerce site? Then you have a user service, a cart service, payment service, etc.

mirekrusin 9y ago
1. Refactoring is pretty much anything that you do to improve the system that doesn't change anything to the outside observer - in other words, your boss can ask you the stupid question "so you've been working all this time, committing changes like crazy and nothing has changed at all?": and your answer is "yes, but...". Extracting scattered logic and encapsulating it into modules (classes, whatever) with clear responsibilities is refactoring for example. Extracting your module into separate dependency package is refactoring as well. Similarly extracting module to some kind of RPC is also a task that falls into refactoring bag - because it doesn't change anything for the outsider. 2. Mature service is your app after several cycles of release. At the beginning the project is just a dance with the client, going in circles, changing things all the time, until she's happy (with at least parts of the system). The thing is that at the beginning you don't know how the system will look like and more importantly - she doesn't know as well. The only tool that we have, that we know works well, is rapid prototyping with quick feedback loop. You want to minimize the friction of changes. She asks you to do something, you do it, then she changes her mind, rearranges things etc - often those changes require schema changes, shuffling hierarchy or adding some indirection layers etc. You can't do it fast if you have to coordinate several microservices to use new schema. You need to promote all of them to the new version and you need to orchestrate it on live, production system. With monolith you don't have this problem, everything is in one place, you run migrations on deployment to bring the system to the new state and presto, you're done. This kind of friction echoes through all environments - from your local dev, through staging to production. If you're working with more colleagues, your changes can easily block others' work. 3. So we agree that avoiding friction is important for any kind of project. I'm saying this implying that microservices are adding extra friction to the development. Instead of just calling function in your system you now have to maintain separate, coordinated, interface compatible service. All changes now need to go to two places. They need to be coordinated on migration/deployment, have their own devops setup etc. 4. ...and then you introduce discount codes, different countries, tax information, translations, connecting users with paypal and what not - all spanning across multiple microservices, you need to duplicate new communication schema across all of them, versioning apis, sometimes managing breaking changes which are pain in the ass in microservice world... all that for what? What exactly are you gaining? Are you really maxing out on thousands of requests per second on any one of those components? Is microservice going to save you because you can scale horizontally? Aren't they writing to the same store that's a bottleneck and scaling out the middleware won't improve anything at all? If they are separate then how are your joins doing when you need to match multiple, cross database collections? For example to update some kind of aggregate information for every user? Or any kind of reporting? E-commerce site with user, cart, payment and all the rest is trivial in monolith webapp as described in full in beginners book Agile Web Development with Rails for example. There's no need to clutter basic app like that with microservices IMHO.