4 ms·

Microservices Are Technical Debt

27 points by faizshah 2y ago

uwuwuwuwuwu 2y ago
owo
bearjaws 2y ago
Everything is technical debt once you add the semicolon.
Spivak 2y ago
Microservices are also the result of technical debt where the core monolith has become too much of a ball of mud to hack on efficiently anymore. It's the "you have to write code twice— first to find out what you actually need, and again to build the right thing" on a larger timescale. Never seen a satisfying way forward once you find yourself here.
- KronisLV 2y ago
  > ...where the core monolith has become too much of a ball of mud to hack on efficiently anymore. A lot of people never go to microservices from that monolith, they just keep adding features to it and deal (well, try to cope) with it being increasingly unwieldy and hard to manage.
  - CRConrad 2y ago
    You could always replace it with a modular monolith in stead of microservices.
    - KronisLV 2y ago
      If it's been developed as a singleton application (all features always registered/enabled on startup, only one instance ever running), even that might prove to be quite hard. No idea what else to call a monolith that could never run as more than one instance at the same time. You might have to go through dozens of files and sprinkle feature flags throughout to enable/disable certain modules and making any organizational changes to a codebase over a million lines of code is difficult. Plus, when you have 1000 API endpoints that's generally treated as just "the API", then splitting that up in meaningful ways might present challenges. Aside from that, even if you can cut down on what needs to be enabled for certain development scenarios, you are still compiling the whole monolith, so locally you're saving on some runtime resource usage at best and will still sit around when you make any changes that need you to relaunch the monolith. In general, I agree. I'd even build new systems as modular monoliths first. Except when it comes to large systems of any kind, even just updating the dependencies might sometimes be impossible (in a reasonable timeframe).
      - FLT8 2y ago
        > even just updating the dependencies might sometimes be impossible (in a reasonable timeframe). Consider the situation where you have a proliferation of micro-services all using a similar but slightly divergent stack, and you're notified of a security issue that means you need to update the same library across the entire fleet of services. I know what situation I'd prefer to deal with.
        KronisLV 2y ago
        > Consider the situation where you have a proliferation of micro-services all using a similar but slightly divergent stack, and you're notified of a security issue that means you need to update the same library across the entire fleet of services. I know what situation I'd prefer to deal with. That's a valid concern! But surely there's a middle ground, maybe along the lines of: "okay, this is our main modular monolith codebase, but we'll make the decision to split this one vastly different type of workload in a separate service, since it adds 20 dependencies and we don't want to add that complexity in a codebase that's otherwise a fairly straightforwards RESTful API." Yet, it's a bit odd, because people often talk about DDD and drawing domain boundaries, instead of "okay, so this group of functionality will need to export PDFs of bills and receipts, so we'll extract that and all of the related functionality because of technical considerations, whereas we don't care about adding 10 more API endpoints to our main codebase, because there's another 200 there already." Instead, everyone seems to go "ohh, we'll have users in our system, so that's UserService (myproject-locksmith), we'll have orders in the system, so that's OrderService (myproject-bookkeeper), there's also bills so let's make BillService (myproject-scribe)" and so on.
    - winternett 2y ago
      I use Drupal... Although they issue way too many security & functional updates each year, it's been conveniently 100x less expensive to maintain than microservice architecture apps, and it's open source/PHP as a bonus.
  - winternett 2y ago
    Also never forget how they constantly sunset microservices in order to make everyone scramble to refactor into the new (more expensive of course) microservice under a different name... ugh...
- FLT8 2y ago
  It's 1000x easier to refactor the monolith into a more modular form when it's in a single repo. Wait until you want to try to refactor across service boundaries in a u-services world because you got your boundaries wrong. Additionally, as soon as you introduce RPC-style (or even event-based) interactions between services your complexity goes through the roof. You need to deal with: - service versioning and backward compatibility - serialisation/deserialisation complexity and latency, and synchronization of DTO-style objects between services - more complex deployments - far more complex testing - in-transit encryption for data and key management (eg. Istio, ...) - network-layer issues - circuit breakers - caching / other performance band-aids - graceful degradation across the stack when services fail - sagas or equivalent mechanism for coordinating cross-service operations and what happens when things go wrong (fsm help you if you end up needing cross-service atomic transactions because of your ill-thought-out service boundaries) - etc. I'm honestly amazed at how many people blindly follow the "microservices good / monoliths bad" mantra given how obviously wrong it is for most teams.
  - Spivak 2y ago
    I don't disagree at all. In fact I'm saying the desire for microservices is a sign your monolith could use a refactor. I would call it a canary but it's long dead by this stage. If it's faster to spin up a new production service from scratch to implement some functionality than leverage your existing code then something has gone very wrong. Shouldn't all that code make implementing complex features faster and easier? Shouldn't your codebase be full of powerful tools that can be leveraged to build completely new things? Every time I see this happen is because frameworks -- not 3rd party frameworks, but the whisper from Satan that suggests that wrap code in more layers to make it "easier", "simpler" for the user.
    - amy-petrik-214 2y ago
      exactly - refactor the monolith. What we do is refactor the monolith into microservices that we like to call "micro-monoliths". What you get is the agility of a microservice with the simplicity and lack of sync issues of a monolith. Monoliths are problematic because they are too large and unweildy; microservices are problematic because now you have 200 microservices to track and if one service node goes down it can trigger a cascading failure - we're talking complex distributed systems here. The solution is the micromonolith, a hybrid approach striking a balance between the two, best of both worlds.

27 points by faizshah 2y ago

uwuwuwuwuwu 2y ago

owo

bearjaws 2y ago

Everything is technical debt once you add the semicolon.

Spivak 2y ago

Microservices are also the result of technical debt where the core monolith has become too much of a ball of mud to hack on efficiently anymore. It's the "you have to write code twice— first to find out what you actually need, and again to build the right thing" on a larger timescale. Never seen a satisfying way forward once you find yourself here.

KronisLV 2y ago
> ...where the core monolith has become too much of a ball of mud to hack on efficiently anymore. A lot of people never go to microservices from that monolith, they just keep adding features to it and deal (well, try to cope) with it being increasingly unwieldy and hard to manage.
- CRConrad 2y ago
  You could always replace it with a modular monolith in stead of microservices.
  - KronisLV 2y ago
    If it's been developed as a singleton application (all features always registered/enabled on startup, only one instance ever running), even that might prove to be quite hard. No idea what else to call a monolith that could never run as more than one instance at the same time. You might have to go through dozens of files and sprinkle feature flags throughout to enable/disable certain modules and making any organizational changes to a codebase over a million lines of code is difficult. Plus, when you have 1000 API endpoints that's generally treated as just "the API", then splitting that up in meaningful ways might present challenges. Aside from that, even if you can cut down on what needs to be enabled for certain development scenarios, you are still compiling the whole monolith, so locally you're saving on some runtime resource usage at best and will still sit around when you make any changes that need you to relaunch the monolith. In general, I agree. I'd even build new systems as modular monoliths first. Except when it comes to large systems of any kind, even just updating the dependencies might sometimes be impossible (in a reasonable timeframe).
    - FLT8 2y ago
      > even just updating the dependencies might sometimes be impossible (in a reasonable timeframe). Consider the situation where you have a proliferation of micro-services all using a similar but slightly divergent stack, and you're notified of a security issue that means you need to update the same library across the entire fleet of services. I know what situation I'd prefer to deal with.
      - KronisLV 2y ago
        > Consider the situation where you have a proliferation of micro-services all using a similar but slightly divergent stack, and you're notified of a security issue that means you need to update the same library across the entire fleet of services. I know what situation I'd prefer to deal with. That's a valid concern! But surely there's a middle ground, maybe along the lines of: "okay, this is our main modular monolith codebase, but we'll make the decision to split this one vastly different type of workload in a separate service, since it adds 20 dependencies and we don't want to add that complexity in a codebase that's otherwise a fairly straightforwards RESTful API." Yet, it's a bit odd, because people often talk about DDD and drawing domain boundaries, instead of "okay, so this group of functionality will need to export PDFs of bills and receipts, so we'll extract that and all of the related functionality because of technical considerations, whereas we don't care about adding 10 more API endpoints to our main codebase, because there's another 200 there already." Instead, everyone seems to go "ohh, we'll have users in our system, so that's UserService (myproject-locksmith), we'll have orders in the system, so that's OrderService (myproject-bookkeeper), there's also bills so let's make BillService (myproject-scribe)" and so on.
  - winternett 2y ago
    I use Drupal... Although they issue way too many security & functional updates each year, it's been conveniently 100x less expensive to maintain than microservice architecture apps, and it's open source/PHP as a bonus.
- winternett 2y ago
  Also never forget how they constantly sunset microservices in order to make everyone scramble to refactor into the new (more expensive of course) microservice under a different name... ugh...
FLT8 2y ago
It's 1000x easier to refactor the monolith into a more modular form when it's in a single repo. Wait until you want to try to refactor across service boundaries in a u-services world because you got your boundaries wrong. Additionally, as soon as you introduce RPC-style (or even event-based) interactions between services your complexity goes through the roof. You need to deal with: - service versioning and backward compatibility - serialisation/deserialisation complexity and latency, and synchronization of DTO-style objects between services - more complex deployments - far more complex testing - in-transit encryption for data and key management (eg. Istio, ...) - network-layer issues - circuit breakers - caching / other performance band-aids - graceful degradation across the stack when services fail - sagas or equivalent mechanism for coordinating cross-service operations and what happens when things go wrong (fsm help you if you end up needing cross-service atomic transactions because of your ill-thought-out service boundaries) - etc. I'm honestly amazed at how many people blindly follow the "microservices good / monoliths bad" mantra given how obviously wrong it is for most teams.
- Spivak 2y ago
  I don't disagree at all. In fact I'm saying the desire for microservices is a sign your monolith could use a refactor. I would call it a canary but it's long dead by this stage. If it's faster to spin up a new production service from scratch to implement some functionality than leverage your existing code then something has gone very wrong. Shouldn't all that code make implementing complex features faster and easier? Shouldn't your codebase be full of powerful tools that can be leveraged to build completely new things? Every time I see this happen is because frameworks -- not 3rd party frameworks, but the whisper from Satan that suggests that wrap code in more layers to make it "easier", "simpler" for the user.
  - amy-petrik-214 2y ago
    exactly - refactor the monolith. What we do is refactor the monolith into microservices that we like to call "micro-monoliths". What you get is the agility of a microservice with the simplicity and lack of sync issues of a monolith. Monoliths are problematic because they are too large and unweildy; microservices are problematic because now you have 200 microservices to track and if one service node goes down it can trigger a cascading failure - we're talking complex distributed systems here. The solution is the micromonolith, a hybrid approach striking a balance between the two, best of both worlds.