5 ms·

Do you think it's good idea to migrate from monolith to microservices before scaling the team? We are essentially doing this right now, I personally don't thin

by Olphs 3y ago

Do you think it's good idea to migrate from monolith to microservices before scaling the team? We are essentially doing this right now, I personally don't think the teams are yet large enough to warrant this migration, but leadership says that we can't scale further before we have microservices. Imo most of the problems could be solved with increased testing and knowledge about the system. The tech also could definitely still scale with just by boosting the hardware and occasional performance passes on slow endpoints/queries.

yakshaving_jgt 3y ago
> but leadership says that we can't scale further before we have microservices These are depressingly common alarm bells. There are companies with valuations over 12 figures which don't do microservices, so the scaling justification is dubious at best.
iamflimflam1 3y ago
Are you doing “extreme” micro services? A esperare database for each micro service, one endpoint for each microservice etc.. or the slightly more sensible - let’s split the monolith up into obviously independent system (very much like the article talks about).
- hardware2win 3y ago
  >extreme microservices >separate databases Isnt it like the basic thing?
  - ohgodplsno 3y ago
    If your database isn't the performance issue and those two services spent 99% of the response time on calculating the 15755th digit of pi, not separating the database isn't a problem. Similarly, if both of your services need to fetch some user information, but you haven't created a user information service with its own database they could both talk to, having a shared database is fine. Splitting each and every service with its own database, talking to other services to access their database by default is cargo-cult behavior. All it's going to do is make it hell for you to work on those services.
    - hardware2win 3y ago
      But if 1 database dies, then all microservices dont work So why are you even using them? The benefit of microservices is also reliability, which you just threw away Isnt this basically distributed monolith? So you combined bad things of both worlds! Single point of failure of monolith And deployment difficulties and need for saga like patterns to deal with network trickiness from distributed designs Whats the point?
      - ohgodplsno 3y ago
        Once again, cargo-cultish reasoning, where it's all or nothing. 1/ Replication & read-only copies for resilience exist, to allow you to function in degraded state if your database goes down. 2/ If the database for one service goes down, any service that calls it ends up being down anyways. No, being able to respond with a 503 that says that megatron-service is down and you can't fetch the data isn't different from responding with a regular 500 saying that the database is down and you can't fetch the data.. 3/ All of your calls do not necessarily end up calling the database. Your service starts even if the DB is down, some calls will simply fail. You're providing a degraded service. 4/ If they need similar data, you really don't want to have two databases holding that data. Because I can promise you, the cost of having to handle replication, de-duplication, synchronization, configuration, GDPR compliance, etc on X databases is infinitely higher than having a database where you simply turn on a write replica that fails over. 5/ SPOF-fear is bullshit, you always have a single point of failure in your stuff. 2FA service is down ? Sure, your entire service isn't dead, but hey, users can't log in, sounds like a pretty fucking big point of failure. Microservices just distributes your single point of failure into a dozen, equally bad, equally hard to track down problems. And even in a monolith, you can easily work around these problems: what kind of fucking code have you seen that a whole server will not start because it can't connect to a database ? 6/ You do not need your servers to be distributed. That is bullshit, and if you are at the scale where you actually need to, it'll be the least of your problems.
        hardware2win 3y ago
        1st point is really good, make sense! Your 3rd point shows scenerio where 2nd point is not applicable. >what kind of fucking code have you seen that a whole server will not start because it can't connect to a database ? Server? Idk. App? Sure, CRUD app that requires config/filling cache dictionaries from db >Once again, cargo-cultish reasoning, where it's all or nothing. Thats fair point, so what are micro services doing for you then? Allowing teams to deploy independently?
mikeryan 3y ago
can't scale further before we have microservices. Scale what? Load (Seems not) Scale the team? This is often an overlooked aspect of microservices you're able to isolate the domain knowledge to smaller services and hire more specialized engineers who can focus on a specific silo of the app and only have to work to discrete APIs. Scale features? There's a legit argument to be made that if you see yourself going to a microservice architecture in the future based on your current codebase or product roadmap that doing it sooner then later is always going to be preferable. The bigger the monolith the harder it is to unwind. It could also be that there's some tech debt that's something of a limiting factor, making the change in architecture could be an opportunity to address some of that.

by Olphs 3y ago

yakshaving_jgt 3y ago

> but leadership says that we can't scale further before we have microservices These are depressingly common alarm bells. There are companies with valuations over 12 figures which don't do microservices, so the scaling justification is dubious at best.

iamflimflam1 3y ago

Are you doing “extreme” micro services? A esperare database for each micro service, one endpoint for each microservice etc.. or the slightly more sensible - let’s split the monolith up into obviously independent system (very much like the article talks about).

hardware2win 3y ago
>extreme microservices >separate databases Isnt it like the basic thing?
- ohgodplsno 3y ago
  If your database isn't the performance issue and those two services spent 99% of the response time on calculating the 15755th digit of pi, not separating the database isn't a problem. Similarly, if both of your services need to fetch some user information, but you haven't created a user information service with its own database they could both talk to, having a shared database is fine. Splitting each and every service with its own database, talking to other services to access their database by default is cargo-cult behavior. All it's going to do is make it hell for you to work on those services.
  - hardware2win 3y ago
    But if 1 database dies, then all microservices dont work So why are you even using them? The benefit of microservices is also reliability, which you just threw away Isnt this basically distributed monolith? So you combined bad things of both worlds! Single point of failure of monolith And deployment difficulties and need for saga like patterns to deal with network trickiness from distributed designs Whats the point?
    - ohgodplsno 3y ago
      Once again, cargo-cultish reasoning, where it's all or nothing. 1/ Replication & read-only copies for resilience exist, to allow you to function in degraded state if your database goes down. 2/ If the database for one service goes down, any service that calls it ends up being down anyways. No, being able to respond with a 503 that says that megatron-service is down and you can't fetch the data isn't different from responding with a regular 500 saying that the database is down and you can't fetch the data.. 3/ All of your calls do not necessarily end up calling the database. Your service starts even if the DB is down, some calls will simply fail. You're providing a degraded service. 4/ If they need similar data, you really don't want to have two databases holding that data. Because I can promise you, the cost of having to handle replication, de-duplication, synchronization, configuration, GDPR compliance, etc on X databases is infinitely higher than having a database where you simply turn on a write replica that fails over. 5/ SPOF-fear is bullshit, you always have a single point of failure in your stuff. 2FA service is down ? Sure, your entire service isn't dead, but hey, users can't log in, sounds like a pretty fucking big point of failure. Microservices just distributes your single point of failure into a dozen, equally bad, equally hard to track down problems. And even in a monolith, you can easily work around these problems: what kind of fucking code have you seen that a whole server will not start because it can't connect to a database ? 6/ You do not need your servers to be distributed. That is bullshit, and if you are at the scale where you actually need to, it'll be the least of your problems.
      - hardware2win 3y ago
        1st point is really good, make sense! Your 3rd point shows scenerio where 2nd point is not applicable. >what kind of fucking code have you seen that a whole server will not start because it can't connect to a database ? Server? Idk. App? Sure, CRUD app that requires config/filling cache dictionaries from db >Once again, cargo-cultish reasoning, where it's all or nothing. Thats fair point, so what are micro services doing for you then? Allowing teams to deploy independently?

mikeryan 3y ago

can't scale further before we have microservices. Scale what? Load (Seems not) Scale the team? This is often an overlooked aspect of microservices you're able to isolate the domain knowledge to smaller services and hire more specialized engineers who can focus on a specific silo of the app and only have to work to discrete APIs. Scale features? There's a legit argument to be made that if you see yourself going to a microservice architecture in the future based on your current codebase or product roadmap that doing it sooner then later is always going to be preferable. The bigger the monolith the harder it is to unwind. It could also be that there's some tech debt that's something of a limiting factor, making the change in architecture could be an opportunity to address some of that.