4 ms·

The projects I've seen getting to technical bankruptcy have been with no exception monoliths. With microservices you have the ability to take one service and f

The projects I've seen getting to technical bankruptcy have been with no exception monoliths. With microservices you have the ability to take one service and fix it, reimplement it or replace it if necessary. Also use whatever technology makes more sense for that project, as long as it speaks the same protocols and sticks to the same interfaces. With monoliths, there's always the analysis paralysis related to the possible ramifications of a change, which slows down everything.

threeseed 9y ago
Monoliths assume that every single developer that will ever touch that codebase will do the right thing. That is everyone from the intern to the 3 month contractor to someone who only cares about finishing off their cards before the end of the sprint. So I am in your boat that every single screwed up, beyond repair project has been a monolith. And always because a small handful of developers decided at some point to cross a logical boundary and introduce spaghetti-like dependencies.
- xxs 9y ago
  >>Monoliths assume that every single developer that will ever touch that codebase will do the right thing. << This is just false, there are pull requests, reviews and all. Morealso there are modules and just because you can deploy the 'monolith' as a single process and use shared memory doesn't mean you can't add/remove parts or have to compile all at once. Analogy with microservices - your login service is borked. The rest of your site is kind of useless even if perfectly operational.
  - threeseed 9y ago
    Pull requests are a relatively new concept to software development. So if you're working on an existing project then chances are the model that was used was "as long as the unit/style tests pass it's fine". And of course there's the very common "we have a fixed deadline so let's just cut this corner and we'll fix it up later". And in the Java world at least modules aren't real. They are purely logical constructs that developers can work around by importing from packages in other modules. And creating the spaghetti code problem again.
    - pferde 9y ago
      It's not really that new, it's just the term "pull request" that's new. I've worked in several projects where prior to committing code change, it was shared out to the team in form of a patch, feedback gathered, and only when everybody was happy with it, it got committed. Or, a bit dirtier solution - a commit was made with an explicit request for a closer review from the rest of the team.
    - xxs 9y ago
      I'd say the microservices fad is newer than the distributed source repositories but disregarding something because deemed 'new' doesn't make a good argument. And in the Java world at least modules aren't real. The statement shows lack of understanding how modules should be utilized (it has very little to do with packages). Interfaces (can) do exactly the same what protocols in microservices do. Enforcing that might be harder but facades/proxies ensure there would be no (feasible) way to bypass. There is no substitute for good data models/responsibility.
- mattmanser 9y ago
  And microservices guarantee that every single fad is represented in a hundred different ways in every different microservice, and that there is not a single bit of consistency in the code base. The mental overhead of that is HUGE. Every new bit of functionality you have to figure out how this microservice was built? Opening a microservice and learning what developer X did with developer Y's "I don't understand functional, but I'm damn well going to use it, and wouldn't it be great to build this in the Zebeedeee framework that trended on HN two weeks ago and then mysteriously disappeared forever". Bad programmers are going to muck up microservices even worse than they're going to muck up monoliths. At least with monoliths they might actually reuse some code rather than cut and paste it from the last microservice they worked on.
conradk 9y ago
You could also have a "monolith" in a single or multiple compatible languages (C, Rust, C++, etc) and have different features/modules separated in different libraries. These libraries could then act as the "microservices". Developers could be tasked with working on these libraries that would have 0% overhead (since they are just a piece of code that can be used in another library), instead of creating REST/SOAP/RPC APIs that come with the HTTP/SOAP/RPC overhead. This means you can start small, with a public REST/SOAP/RPC API. Less infrastructure, less server config, etc. And if at some point you need more scalability, you can always do an actual microservice (ie a separate REST/SOAP/RPC API) with the library code the day you absolutely need it for horizontal scalability or whatever. I have seen this pattern used in the Rust world a lot. Projects expose both a library and a binary. And the binary is built on top of the library. This means you have 0 overhead if you want to use the binary's features, since you can simply include the library and get going. Also, I think that having the tools to support deprecation is big advantage when working with a monolith. I think Rust has built-in support for compile-time deprecation notices. PHP, for instance, doesn't have that particular feature yet, as far as I know. Symfony tries its best by adding deprecation notices when you call a deprecated method/function. But you have to call it to realize it's deprecated. I'm not here to promote Rust or hurt PHP, I actually love both. The statements above apply to a lot of other languages as well. I just took the examples of Rust and PHP because these are the ones I've worked with the most. @xxs's comment is spot on as well.
- partycoder 9y ago
  If you divide your project so self-contained components with scoped set of responsibilities that are not coupled to the rest, that's fine as well. I've used that pattern with great success. Microservices are a way of achieving this, but as you describe it, is not the only way. Discipline is another way. Now, as you have more people involved, or release deadlines get tighter, chances that tech debt gets introduced increase. Unless you go back and repay the tech debt, situation would worsen. In that sense, microservices are some sort of cap on the impact of tech debt from rushed deadlines and lack of discipline.
  - potatoyogurt 9y ago
flukus 9y ago
> With microservices you have the ability to take one service and fix it, reimplement it or replace it if necessary. You can do that inside a monolith too. Microservice as a solution points to architectural problems, we try to build systems that are too vertical, our architecture should be horizontal. Microservices enforce this horizontalness, but it's not the only way to achieve it.
- je42 9y ago
  The issue is when you have multiple teams working on a monolith. I haven't seen a configuration of teams that doesn't screw up the monolith by creating "spaghetti" dependencies between the pieces. Hence making the transition to microservices a multi year journey.
  - marcosdumay 9y ago
    That's because you need a configuration of the boundary, not of the teams. And that, coincidentally, is also what you need to not write spaghetti service interactions.
Sanddancer 9y ago
I've worked on a codebase where a jsp app would call an API served by a mod_perl app, which would call a remote API to a c++ app. Technical bankruptcy can and does creep up even in services made in the micro style. They may not be as common now because the microservice trend is fairly recent, but as years go on, I'm betting you're going to see more issues with microservice systems where code done may be using a decade's worth of changing Best Practices.
- flukus 9y ago
  You just reminded me of one I worked on too, back before the buzzword existed but still a microservice architecture. It was all c# but service1 would call service2 which would call service3 which would call service1. It had all the spaghetti of a monolithic system with 1/10th the debugability and performance (serialization can be relatively expensive).
crdoconnor 9y ago
>The projects I've seen getting to technical bankruptcy have been with no exception monoliths. With microservices you have the ability to take one service and fix it, reimplement it or replace it if necessary. The worst kind of technical debt is usually about having the service boundary in the wrong place and crappy APIs. With microservices this problem is amplified. It's harder to unpick a service than it is a module. If you've ever tried debugging a problem across a series of microservices as well, you'll wish you hadn't...

threeseed 9y ago

Monoliths assume that every single developer that will ever touch that codebase will do the right thing. That is everyone from the intern to the 3 month contractor to someone who only cares about finishing off their cards before the end of the sprint. So I am in your boat that every single screwed up, beyond repair project has been a monolith. And always because a small handful of developers decided at some point to cross a logical boundary and introduce spaghetti-like dependencies.

xxs 9y ago
>>Monoliths assume that every single developer that will ever touch that codebase will do the right thing. << This is just false, there are pull requests, reviews and all. Morealso there are modules and just because you can deploy the 'monolith' as a single process and use shared memory doesn't mean you can't add/remove parts or have to compile all at once. Analogy with microservices - your login service is borked. The rest of your site is kind of useless even if perfectly operational.
- threeseed 9y ago
  Pull requests are a relatively new concept to software development. So if you're working on an existing project then chances are the model that was used was "as long as the unit/style tests pass it's fine". And of course there's the very common "we have a fixed deadline so let's just cut this corner and we'll fix it up later". And in the Java world at least modules aren't real. They are purely logical constructs that developers can work around by importing from packages in other modules. And creating the spaghetti code problem again.
  - pferde 9y ago
    It's not really that new, it's just the term "pull request" that's new. I've worked in several projects where prior to committing code change, it was shared out to the team in form of a patch, feedback gathered, and only when everybody was happy with it, it got committed. Or, a bit dirtier solution - a commit was made with an explicit request for a closer review from the rest of the team.
  - xxs 9y ago
    I'd say the microservices fad is newer than the distributed source repositories but disregarding something because deemed 'new' doesn't make a good argument. And in the Java world at least modules aren't real. The statement shows lack of understanding how modules should be utilized (it has very little to do with packages). Interfaces (can) do exactly the same what protocols in microservices do. Enforcing that might be harder but facades/proxies ensure there would be no (feasible) way to bypass. There is no substitute for good data models/responsibility.
mattmanser 9y ago
And microservices guarantee that every single fad is represented in a hundred different ways in every different microservice, and that there is not a single bit of consistency in the code base. The mental overhead of that is HUGE. Every new bit of functionality you have to figure out how this microservice was built? Opening a microservice and learning what developer X did with developer Y's "I don't understand functional, but I'm damn well going to use it, and wouldn't it be great to build this in the Zebeedeee framework that trended on HN two weeks ago and then mysteriously disappeared forever". Bad programmers are going to muck up microservices even worse than they're going to muck up monoliths. At least with monoliths they might actually reuse some code rather than cut and paste it from the last microservice they worked on.

conradk 9y ago

You could also have a "monolith" in a single or multiple compatible languages (C, Rust, C++, etc) and have different features/modules separated in different libraries. These libraries could then act as the "microservices". Developers could be tasked with working on these libraries that would have 0% overhead (since they are just a piece of code that can be used in another library), instead of creating REST/SOAP/RPC APIs that come with the HTTP/SOAP/RPC overhead. This means you can start small, with a public REST/SOAP/RPC API. Less infrastructure, less server config, etc. And if at some point you need more scalability, you can always do an actual microservice (ie a separate REST/SOAP/RPC API) with the library code the day you absolutely need it for horizontal scalability or whatever. I have seen this pattern used in the Rust world a lot. Projects expose both a library and a binary. And the binary is built on top of the library. This means you have 0 overhead if you want to use the binary's features, since you can simply include the library and get going. Also, I think that having the tools to support deprecation is big advantage when working with a monolith. I think Rust has built-in support for compile-time deprecation notices. PHP, for instance, doesn't have that particular feature yet, as far as I know. Symfony tries its best by adding deprecation notices when you call a deprecated method/function. But you have to call it to realize it's deprecated. I'm not here to promote Rust or hurt PHP, I actually love both. The statements above apply to a lot of other languages as well. I just took the examples of Rust and PHP because these are the ones I've worked with the most. @xxs's comment is spot on as well.

partycoder 9y ago
If you divide your project so self-contained components with scoped set of responsibilities that are not coupled to the rest, that's fine as well. I've used that pattern with great success. Microservices are a way of achieving this, but as you describe it, is not the only way. Discipline is another way. Now, as you have more people involved, or release deadlines get tighter, chances that tech debt gets introduced increase. Unless you go back and repay the tech debt, situation would worsen. In that sense, microservices are some sort of cap on the impact of tech debt from rushed deadlines and lack of discipline.
- potatoyogurt 9y ago

flukus 9y ago

> With microservices you have the ability to take one service and fix it, reimplement it or replace it if necessary. You can do that inside a monolith too. Microservice as a solution points to architectural problems, we try to build systems that are too vertical, our architecture should be horizontal. Microservices enforce this horizontalness, but it's not the only way to achieve it.

je42 9y ago
The issue is when you have multiple teams working on a monolith. I haven't seen a configuration of teams that doesn't screw up the monolith by creating "spaghetti" dependencies between the pieces. Hence making the transition to microservices a multi year journey.
- marcosdumay 9y ago
  That's because you need a configuration of the boundary, not of the teams. And that, coincidentally, is also what you need to not write spaghetti service interactions.

Sanddancer 9y ago

I've worked on a codebase where a jsp app would call an API served by a mod_perl app, which would call a remote API to a c++ app. Technical bankruptcy can and does creep up even in services made in the micro style. They may not be as common now because the microservice trend is fairly recent, but as years go on, I'm betting you're going to see more issues with microservice systems where code done may be using a decade's worth of changing Best Practices.

flukus 9y ago
You just reminded me of one I worked on too, back before the buzzword existed but still a microservice architecture. It was all c# but service1 would call service2 which would call service3 which would call service1. It had all the spaghetti of a monolithic system with 1/10th the debugability and performance (serialization can be relatively expensive).

crdoconnor 9y ago

>The projects I've seen getting to technical bankruptcy have been with no exception monoliths. With microservices you have the ability to take one service and fix it, reimplement it or replace it if necessary. The worst kind of technical debt is usually about having the service boundary in the wrong place and crappy APIs. With microservices this problem is amplified. It's harder to unpick a service than it is a module. If you've ever tried debugging a problem across a series of microservices as well, you'll wish you hadn't...