4 ms·

Don't monorepos solve this? Lets presume I'm not a FAANG company (though some of those have monorepos) with a bazillion services, I'm just a startup with say 10

Don't monorepos solve this? Lets presume I'm not a FAANG company (though some of those have monorepos) with a bazillion services, I'm just a startup with say 10 services. At that scale I think its pretty realistic to maintain a monorepo for all 10 services. That way every release only upgrades the version count by one.

grahamannett 7y ago
what? i don’t understand how this has anything to do with micro services vs monorepo, if you are using either and you update a particular something what is different between the two
- simongray 7y ago
  All of the content in a monorepo is versioned together, while microservices have their own independent versioning schemes and for this reason their interfaces can drift.
taleodor 7y ago
Thank you for the comment - monorepos indeed make things better to a degree. From one perspective, you now can point your Product (package) to the whole monorepo. But in reality, you're still facing same issue - let's say your components X and Y are updated in monorepo. You want X in production, but not Y - so now you have to invent something on top of monorepo to capture this. Another words back to square 1. Regarding startups, in my experience they start feeling this pain when they already have 5-6 microservices. But YMMV - depends on a lot of factors.
- dgrin91 7y ago
  Yes, perhaps a better way to think about it is to version the set of services as a whole, and deploy them as a holistic, singular product. Then you don't run into the combinatorics problems.... Just challenges with roll backs.
gravypod 7y ago
They do in part but developers need to be aware of two major things: 1. Always be backwards compatible in protocols and data formats. If you store data on disk or in a table you V1 and V2 tables need to be generally compatible. V2 should always be able to read V1 tables. This helps with rollouts. In an ideal case V1 should gracefully handle V2 tables. This helps with rollbacks. 2. Service to service communications work between V1 and V2. If you don't want downtime you have to gracefully handle the situation in which V2 is rolling out. In a zero-downtime deployment config like blue/green V2 instances can get requests from V1 instances and vice versa. Monorepos don't help with these situations. These are just engineering practices that have to be upheld by the team. Monorepos will make the atomic source code updates applied across the codebase easy.
- thedance 7y ago
  Every place you said "should" is actually "must" otherwise how can anything work? Clearly the next version MUST be able to read the stored data of the current version and just as clearly the next version MUST write data that can be read by the current version. If not then releasing the software is totally impossible.
akuse 7y ago
Don't monorepos have an adjacent problem as well? Feature-flags tend to create a combinatorial explosion of potential code-paths in your system.
jennyyang 7y ago
A startup has no business running microservices. Microservices are only when the engineering team can't scale properly because they keep stepping on top of each other. A startup should be using a monolith until it becomes a victim of its own success and then should migrate thoughtfully to microservices only when it has to. It also requires a very heavy investment in devops and tools since microservices will fail in production in every which way possible. It also requires a huge investment in metrics and alerts and logging otherwise you will have no idea what is wrong with your now too-complicated production system.
- danielovichdk 7y ago
  Do you know the domain of the business? Otherwose it sounds like you should reconsider the advice you give out.
  - jennyyang 7y ago
    My statement applies across the board. It doesn't matter what the domain of the business is. Microservices cost more and have a higher impact on productivity and is only worth it if your engineering team needs the flexibility, at the cost of increase devops investment and more down time.
    - danielovichdk 7y ago
      No.
      - jennyyang 7y ago
        Ok. Once you have real world experience, then you should continue commenting.
- speedplane 7y ago
  > A startup has no business running microservices. Microservices are only when the engineering team can't scale properly because they keep stepping on top of each other. While I generally agree with you in the vast majority of practical cases, it can make sense in some circumstances, namely, if there is a very clear logical abstraction between one service and another. A microservice is just another layer of abstraction, similar to functions, classes, files, libraries, and programs, but even higher up the food-chain, and it comes with its own characteristics and peculiarities. If you have high confidence that one component is (1) logically extremely different from all of the other components, (2) has no side effects, (3) is not I/O bound as it's going over a network, and critically, (4) is on a separate development timeline, then you have a solid candidate for a microservice.
mattlondon 7y ago
I guess it would only help if the dependencies can be statically analyzed somehow - e.g. a change in X causes a compiler error in Y etc etc - or you have really really really comprehensive integration tests. In my experience this is not always the case and the problems creep in in other places that are not easily statically checked or tested, but which come up at runtime, e.g. specific runtime content/data, or serialisation of some message/object that happens at runtime.
thedance 7y ago
No, monorepos don't solve this at all. It's not even related. RPC services are described by IDL and you can't ever break the semantics of the service for any client that was ever using any released version of the IDL. Full stop. The is the golden rule of RPC services and it's also the only rule! You can do anything else, you can completely replace the service with a scratch rewrite in Erlang as long as you don't break the one rule.
fetbaffe 7y ago
Monorepo can help you in tracking dependencies between services at build time, however services are still executed independently in production, thus existing running services will have a dependency to older versions. To solve that without versioning you then have to shutdown all of them & wait until all off them are online again with the latest commit of your monorepo. Now you have created a network distributed monolith.
antoinealb 7y ago
An issue you might face is that during rollouts, you will still have some servers running the old binary and some running the new binary. So you must either: 1. Stop all old servers before starting the new ones -> downtime, might be acceptable 2. Have your clients handle the fact that they might hit vN or vN+1 of your services.

grahamannett 7y ago

what? i don’t understand how this has anything to do with micro services vs monorepo, if you are using either and you update a particular something what is different between the two

simongray 7y ago
All of the content in a monorepo is versioned together, while microservices have their own independent versioning schemes and for this reason their interfaces can drift.

taleodor 7y ago

Thank you for the comment - monorepos indeed make things better to a degree. From one perspective, you now can point your Product (package) to the whole monorepo. But in reality, you're still facing same issue - let's say your components X and Y are updated in monorepo. You want X in production, but not Y - so now you have to invent something on top of monorepo to capture this. Another words back to square 1. Regarding startups, in my experience they start feeling this pain when they already have 5-6 microservices. But YMMV - depends on a lot of factors.

dgrin91 7y ago
Yes, perhaps a better way to think about it is to version the set of services as a whole, and deploy them as a holistic, singular product. Then you don't run into the combinatorics problems.... Just challenges with roll backs.

gravypod 7y ago

They do in part but developers need to be aware of two major things: 1. Always be backwards compatible in protocols and data formats. If you store data on disk or in a table you V1 and V2 tables need to be generally compatible. V2 should always be able to read V1 tables. This helps with rollouts. In an ideal case V1 should gracefully handle V2 tables. This helps with rollbacks. 2. Service to service communications work between V1 and V2. If you don't want downtime you have to gracefully handle the situation in which V2 is rolling out. In a zero-downtime deployment config like blue/green V2 instances can get requests from V1 instances and vice versa. Monorepos don't help with these situations. These are just engineering practices that have to be upheld by the team. Monorepos will make the atomic source code updates applied across the codebase easy.

thedance 7y ago
Every place you said "should" is actually "must" otherwise how can anything work? Clearly the next version MUST be able to read the stored data of the current version and just as clearly the next version MUST write data that can be read by the current version. If not then releasing the software is totally impossible.

akuse 7y ago

Don't monorepos have an adjacent problem as well? Feature-flags tend to create a combinatorial explosion of potential code-paths in your system.

jennyyang 7y ago

A startup has no business running microservices. Microservices are only when the engineering team can't scale properly because they keep stepping on top of each other. A startup should be using a monolith until it becomes a victim of its own success and then should migrate thoughtfully to microservices only when it has to. It also requires a very heavy investment in devops and tools since microservices will fail in production in every which way possible. It also requires a huge investment in metrics and alerts and logging otherwise you will have no idea what is wrong with your now too-complicated production system.

danielovichdk 7y ago
Do you know the domain of the business? Otherwose it sounds like you should reconsider the advice you give out.
- jennyyang 7y ago
  My statement applies across the board. It doesn't matter what the domain of the business is. Microservices cost more and have a higher impact on productivity and is only worth it if your engineering team needs the flexibility, at the cost of increase devops investment and more down time.
  - danielovichdk 7y ago
    No.
    - jennyyang 7y ago
      Ok. Once you have real world experience, then you should continue commenting.
speedplane 7y ago
> A startup has no business running microservices. Microservices are only when the engineering team can't scale properly because they keep stepping on top of each other. While I generally agree with you in the vast majority of practical cases, it can make sense in some circumstances, namely, if there is a very clear logical abstraction between one service and another. A microservice is just another layer of abstraction, similar to functions, classes, files, libraries, and programs, but even higher up the food-chain, and it comes with its own characteristics and peculiarities. If you have high confidence that one component is (1) logically extremely different from all of the other components, (2) has no side effects, (3) is not I/O bound as it's going over a network, and critically, (4) is on a separate development timeline, then you have a solid candidate for a microservice.

mattlondon 7y ago

I guess it would only help if the dependencies can be statically analyzed somehow - e.g. a change in X causes a compiler error in Y etc etc - or you have really really really comprehensive integration tests. In my experience this is not always the case and the problems creep in in other places that are not easily statically checked or tested, but which come up at runtime, e.g. specific runtime content/data, or serialisation of some message/object that happens at runtime.

thedance 7y ago

No, monorepos don't solve this at all. It's not even related. RPC services are described by IDL and you can't ever break the semantics of the service for any client that was ever using any released version of the IDL. Full stop. The is the golden rule of RPC services and it's also the only rule! You can do anything else, you can completely replace the service with a scratch rewrite in Erlang as long as you don't break the one rule.

fetbaffe 7y ago

Monorepo can help you in tracking dependencies between services at build time, however services are still executed independently in production, thus existing running services will have a dependency to older versions. To solve that without versioning you then have to shutdown all of them & wait until all off them are online again with the latest commit of your monorepo. Now you have created a network distributed monolith.

antoinealb 7y ago

An issue you might face is that during rollouts, you will still have some servers running the old binary and some running the new binary. So you must either: 1. Stop all old servers before starting the new ones -> downtime, might be acceptable 2. Have your clients handle the fact that they might hit vN or vN+1 of your services.