4 ms·

Micro services don't only provide horizontal scaling but also operational scaling, including risk of deployments, downtime, release coordination and contributio

by alttab 7y ago

Micro services don't only provide horizontal scaling but also operational scaling, including risk of deployments, downtime, release coordination and contributions from multiple workstreams or teams. Sometimes applications with only 100s of users need microservices simply due to the complexity and range of the workloads. The moment your monolithic frontend and backend need to start doing asynchronous work, you'll want to build a "microservice" to pull from a queue.

allover 7y ago
> Micro services don't only provide horizontal scaling but also operational scaling I think it's more accurate to say that they don't necessarily provide any horizontal scaling, but can provide operational scaling. This is only if there's some natural team divide, and the impact of the introduced complexity does not outweigh the benefits of the teams being able to test and deploy independently. Sadly in most cases I have come across, this is not the case -- the complexity introduced and/or problems caused by lack of ecosystem maturity outweigh any potential organisational benefit. > release coordination Microservices can make release coordination significantly harder i.e. when a feature release requires multiple deployments from separate teams, I definitely wouldn't list this in the pros column, it's very much an "it depends". Other tangential factors, e.g. monorepo vs multi-repo, can be more significant. > The moment your monolithic frontend and backend need to start doing asynchronous work, you'll want to build a "microservice" I agree queue-based background work is a case where services are a good fit (sadly this is not what a lot of people are doing with their codebases when they "go microservices"), ... but it can also be simpler to deploy the same exact same monolithic codebase to a worker, and only execute the part that is performing your async task. (If your worker is a lambda, sure, that isn't going to work.)
- weberc2 7y ago
  > Microservices can make release coordination significantly harder i.e. when a feature release requires multiple deployments from separate teams, I definitely wouldn't list this in the pros column, it's very much an "it depends". Other tangential factors, e.g. monorepo vs multi-repo, can be more significant. If you're operating a monolith, every release requires coordination from every team, no?
  - allover 7y ago
    I was referring to the act of deployment itself. A single deployment of a monolith, without needing to ensure a dependent service whose pipeline is owned by another team is "deployed first", can be a lot easier to organise. As I say it can depend a lot on other factors like repo organisation, pipeline maturity. I struggle to see how release coordination can be something microservices inherently improve upon, do you have an example comparison perhaps?
weberc2 7y ago
Right. I don't know what issues people are having specifically with microservices, but we're in a sort of hybrid place where we have about 30 engineers split into a few teams. We collectively build/operate ~7 microservices and a dozen lambda functions, queues, etc, all of which are deployed together about ten times per day. This has been working very well for us, and I would like to see us buy into the microservice model more with teams that each operate one or two services instead of each team committing a little bit to every service. In that model, each team would only need to worry about their own service(s) instead of interactions across every service (or rather, this would be less of a concern). The only piece that doesn't work so well for us is local development; we've tried Docker Compose and PM2 to run the whole fleet of services in either containerized and native-process configuration (respectively), but the former is slow due to terrible Docker for Mac filesystem performance and the latter introduces all sorts of environment sanitization/consistency issues.
JustSomeNobody 7y ago
>The moment your monolithic frontend and backend need to start doing asynchronous work, you'll want to build a "microservice" to pull from a queue. That’s a multi process architecture. We’ve done that for ages. Multiple processes doing what the do and communication is via TCP or named pipes.
lucidone 7y ago
Why can't you spin up a new instance of the monolith and designate it as the "queue worker"? I've done this before with both Laravel and Rails and it worked well enough while keeping things simple.

by alttab 7y ago

allover 7y ago

> Micro services don't only provide horizontal scaling but also operational scaling I think it's more accurate to say that they don't necessarily provide any horizontal scaling, but can provide operational scaling. This is only if there's some natural team divide, and the impact of the introduced complexity does not outweigh the benefits of the teams being able to test and deploy independently. Sadly in most cases I have come across, this is not the case -- the complexity introduced and/or problems caused by lack of ecosystem maturity outweigh any potential organisational benefit. > release coordination Microservices can make release coordination significantly harder i.e. when a feature release requires multiple deployments from separate teams, I definitely wouldn't list this in the pros column, it's very much an "it depends". Other tangential factors, e.g. monorepo vs multi-repo, can be more significant. > The moment your monolithic frontend and backend need to start doing asynchronous work, you'll want to build a "microservice" I agree queue-based background work is a case where services are a good fit (sadly this is not what a lot of people are doing with their codebases when they "go microservices"), ... but it can also be simpler to deploy the same exact same monolithic codebase to a worker, and only execute the part that is performing your async task. (If your worker is a lambda, sure, that isn't going to work.)

weberc2 7y ago
> Microservices can make release coordination significantly harder i.e. when a feature release requires multiple deployments from separate teams, I definitely wouldn't list this in the pros column, it's very much an "it depends". Other tangential factors, e.g. monorepo vs multi-repo, can be more significant. If you're operating a monolith, every release requires coordination from every team, no?
- allover 7y ago
  I was referring to the act of deployment itself. A single deployment of a monolith, without needing to ensure a dependent service whose pipeline is owned by another team is "deployed first", can be a lot easier to organise. As I say it can depend a lot on other factors like repo organisation, pipeline maturity. I struggle to see how release coordination can be something microservices inherently improve upon, do you have an example comparison perhaps?

weberc2 7y ago

Right. I don't know what issues people are having specifically with microservices, but we're in a sort of hybrid place where we have about 30 engineers split into a few teams. We collectively build/operate ~7 microservices and a dozen lambda functions, queues, etc, all of which are deployed together about ten times per day. This has been working very well for us, and I would like to see us buy into the microservice model more with teams that each operate one or two services instead of each team committing a little bit to every service. In that model, each team would only need to worry about their own service(s) instead of interactions across every service (or rather, this would be less of a concern). The only piece that doesn't work so well for us is local development; we've tried Docker Compose and PM2 to run the whole fleet of services in either containerized and native-process configuration (respectively), but the former is slow due to terrible Docker for Mac filesystem performance and the latter introduces all sorts of environment sanitization/consistency issues.

JustSomeNobody 7y ago

>The moment your monolithic frontend and backend need to start doing asynchronous work, you'll want to build a "microservice" to pull from a queue. That’s a multi process architecture. We’ve done that for ages. Multiple processes doing what the do and communication is via TCP or named pipes.

lucidone 7y ago

Why can't you spin up a new instance of the monolith and designate it as the "queue worker"? I've done this before with both Laravel and Rails and it worked well enough while keeping things simple.