6 ms·

We just made all the microservices into one big monorepo and we deploy all at the same time. To be honest we tried to avoid the monorepo but it was hellish. Ma

We just made all the microservices into one big monorepo and we deploy all at the same time. To be honest we tried to avoid the monorepo but it was hellish. Maybe if each microservices was larger and our team was larger but then are they microservices any more?

JensRantil 6y ago
"Microservices" is a tool to solve problems. The goal isn't microservices, the goal is to solve those problems. Example of problems it might solve: Unclear ownership, slow innovation, unstable software or orthogonal scaling of features.
Cthulhu_ 6y ago
Microservice is a misnomer; it should have a responsibility, but that could be 10 lines of code or 10 million. Anyway, it sounds like you have a distributed monolith. If you cannot maintain and deploy a microservice independently, it should not be a microservice.
- notwedtm 6y ago
  I don't build microservices anymore. All of the reasons listed in this thread tend to cause bottlnecks. I aim for domain services. Define your domains, and build a program to service it.
  - UK-Al05 6y ago
    That's microservices. Microservices handle a bounded domain. At least in traditional advice for splitting microservices. The microservice provide an api for that domain.
    - goodpoint 6y ago
      No, that's SOA. Microservices are almost always described as quite small.
      - UK-Al05 6y ago
        The "Building Microservices" book, which used to be the goto book for microservices suggests on page 31 to page 38 that bounded domains are a good model for microservices. The main difference between SOA and microservices is dump pipes vs smart pipes. Not service size. As explained in that book. Most people trying to implement microservices seem to have not read much about them outside of blogs.
        ex_amazon_sde 6y ago
        Quoting some book does not change the fact that most people understand SOA as being team or domain-bound and microservices as being much smaller.
        UK-Al05 6y ago
        I'm assuming most people adopting micro-services weren't even around when SOA was a big thing. People not reading the literature then implementing it badly isn't problem with the idea. In the same way that not studying calculus then doing badly isn't a problem of calculus. Most of these issues around microservices like how to split them so they don't cause issues, are known and solved problems. Just people have not read the literature other than the odd "blog". Like don't do microservices, for your first iteration. Backwards compaitble apis, and understand your bounded contexts from your first iteration before you try. They end up creating chatty nano services with tons of version fixed cross dependencies.
        tdeck 6y ago
        Interesting because I always thought SOA was just a slightly older term for microservices.
    - jblwps 6y ago
      Doesn't a "service" handle a domain?
      - UK-Al05 6y ago
        Putting micro in front of service was a bad idea. Lots of people have the wrong idea because of that.
- bhouston 6y ago
  > Anyway, it sounds like you have a distributed monolith. If you cannot maintain and deploy a microservice independently, it should not be a microservice. We can maintain and deploy them independently, but it was annoying to try to track which version was deployed where and having to check it out independently, etc. The overhead was incredibly high. So we plopped them all into a single monorepo as sub projects. We can still update each one individually but we know what is live on the website is what is in the head of that branch. As someone whose last website was a monolith (Clara.io), we do feel we are getting the benefits of micro services with little of their downsides now. It is like night and day. It may be we have a lot of micro services for the size of our team - 20+ micro services and a team size of around 12.
myzie 6y ago
+1 to this. In our case we say "deploy all" but use Zim[1] to automatically determine which services have associated changes. This keeps the overall deploy quick. This is comparable to CloudFormation or Terraform in terms of determining whether something is up-to-date, but more general purpose. [1] https://github.com/fugue/zim/ https://github.com/fugue/zim/
lovedswain 6y ago
The biggest difficulty I've experienced is "librification", where some common code ends up in a little library, and soon that library is not so little any more, and not long after starts to look like half of every service. I can maintain discipline when working on small systems alone, but on a team there will always be one lazy person or urgent need which means eventually some shared component gains enough gravity to start sucking code out of their nice isolated homes Giving up and dumping everything into a monorepo, that's not going to help at all. At that point probably better off just giving up any hope of carefully split up and individually managed services
- mewpmewp2 6y ago
  I don't get the first paragraph you are saying. This lazy person puts some random code into a shared component, or... ? Wouldn't this urgent need mean that they put this code into the microservice that needs this urgent update as opposed to going through the effort to make it available for everyone to use?
  - deleted 6y ago
    [deleted]
- bhouston 6y ago
  These libraries already exist whether you write them or you use someone else's. In our case most of our micro services are node.js based so Koa is in every microservice and we use middleware for authentication -- and thus if the authentication system evolves (moving to JWT or a microservice gateway) we have to evolve that middleware everywhere. Same with our consistent logging system. Libraries are better than unique code everywhere for the same task - allows you to fix a bug once and to do consistency checking.
  - rgoulter 6y ago
    The problem isn't "some code which different services use is in a library". The problem is an not-ideal "the code which is in libraries shared by different services is tightly-coupled to particular services". e.g. changing the shared library might break some service which depends on it. Obviously, you don't want code like that. But it's easy to write code which is slightly coupled; and then when you're in a hurry, to increase the coupling.
nicoburns 6y ago
Perhaps they shouldn't be microservices. What would be the disadvantage if you combined your microservices into a monolith? Or perhaps 4-5 "macroservices"?
- jayd16 6y ago
  In this case I think the disadvantages would be you're locked into one machine type and your blast radius is a bit wider.
BurningFrog 6y ago
One "wisdom" I hear is that the benefit of microservices is organizational: One microservice per team, so you cut down on intra-team friction, and the team can manage their own releases.
- beastcoast 6y ago
  What people miss is that micro services/SOA is an organizational concept more than anything. At Amazon, SOA is tied to the concept of the two pizza team. Each 2PT completely owns a collection of related services, owns the roadmap for those services, and can make deployments independently of any other team. If your company doesn’t have enough engineers to justify at least say 5-10 scrum teams then you might not be large enough to need microservices.
  - ex_amazon_sde 6y ago
    Spot on! This is the right granularity.
- dfcowell 6y ago
  Microservices are a solution for scaling teams, not software or infrastructure. (In other words, you're 100% spot on!)
taneq 6y ago
I was going to make some sarcastic response to the effect of "iT's EvErGReeN" but this is basically the only answer. You don't do individual releases of your microservices any more than you do individual releases of the classes/functions in your C++ project.

JensRantil 6y ago

"Microservices" is a tool to solve problems. The goal isn't microservices, the goal is to solve those problems. Example of problems it might solve: Unclear ownership, slow innovation, unstable software or orthogonal scaling of features.

Cthulhu_ 6y ago

Microservice is a misnomer; it should have a responsibility, but that could be 10 lines of code or 10 million. Anyway, it sounds like you have a distributed monolith. If you cannot maintain and deploy a microservice independently, it should not be a microservice.

notwedtm 6y ago
I don't build microservices anymore. All of the reasons listed in this thread tend to cause bottlnecks. I aim for domain services. Define your domains, and build a program to service it.
- UK-Al05 6y ago
  That's microservices. Microservices handle a bounded domain. At least in traditional advice for splitting microservices. The microservice provide an api for that domain.
  - goodpoint 6y ago
    No, that's SOA. Microservices are almost always described as quite small.
    - UK-Al05 6y ago
      The "Building Microservices" book, which used to be the goto book for microservices suggests on page 31 to page 38 that bounded domains are a good model for microservices. The main difference between SOA and microservices is dump pipes vs smart pipes. Not service size. As explained in that book. Most people trying to implement microservices seem to have not read much about them outside of blogs.
      - ex_amazon_sde 6y ago
        Quoting some book does not change the fact that most people understand SOA as being team or domain-bound and microservices as being much smaller.
        UK-Al05 6y ago
        I'm assuming most people adopting micro-services weren't even around when SOA was a big thing. People not reading the literature then implementing it badly isn't problem with the idea. In the same way that not studying calculus then doing badly isn't a problem of calculus. Most of these issues around microservices like how to split them so they don't cause issues, are known and solved problems. Just people have not read the literature other than the odd "blog". Like don't do microservices, for your first iteration. Backwards compaitble apis, and understand your bounded contexts from your first iteration before you try. They end up creating chatty nano services with tons of version fixed cross dependencies.
        tdeck 6y ago
        Interesting because I always thought SOA was just a slightly older term for microservices.
  - jblwps 6y ago
    Doesn't a "service" handle a domain?
    - UK-Al05 6y ago
      Putting micro in front of service was a bad idea. Lots of people have the wrong idea because of that.
bhouston 6y ago
> Anyway, it sounds like you have a distributed monolith. If you cannot maintain and deploy a microservice independently, it should not be a microservice. We can maintain and deploy them independently, but it was annoying to try to track which version was deployed where and having to check it out independently, etc. The overhead was incredibly high. So we plopped them all into a single monorepo as sub projects. We can still update each one individually but we know what is live on the website is what is in the head of that branch. As someone whose last website was a monolith (Clara.io), we do feel we are getting the benefits of micro services with little of their downsides now. It is like night and day. It may be we have a lot of micro services for the size of our team - 20+ micro services and a team size of around 12.

myzie 6y ago

+1 to this. In our case we say "deploy all" but use Zim[1] to automatically determine which services have associated changes. This keeps the overall deploy quick. This is comparable to CloudFormation or Terraform in terms of determining whether something is up-to-date, but more general purpose. [1] https://github.com/fugue/zim/ https://github.com/fugue/zim/

lovedswain 6y ago

The biggest difficulty I've experienced is "librification", where some common code ends up in a little library, and soon that library is not so little any more, and not long after starts to look like half of every service. I can maintain discipline when working on small systems alone, but on a team there will always be one lazy person or urgent need which means eventually some shared component gains enough gravity to start sucking code out of their nice isolated homes Giving up and dumping everything into a monorepo, that's not going to help at all. At that point probably better off just giving up any hope of carefully split up and individually managed services

mewpmewp2 6y ago
I don't get the first paragraph you are saying. This lazy person puts some random code into a shared component, or... ? Wouldn't this urgent need mean that they put this code into the microservice that needs this urgent update as opposed to going through the effort to make it available for everyone to use?
- deleted 6y ago
  [deleted]
bhouston 6y ago
These libraries already exist whether you write them or you use someone else's. In our case most of our micro services are node.js based so Koa is in every microservice and we use middleware for authentication -- and thus if the authentication system evolves (moving to JWT or a microservice gateway) we have to evolve that middleware everywhere. Same with our consistent logging system. Libraries are better than unique code everywhere for the same task - allows you to fix a bug once and to do consistency checking.
- rgoulter 6y ago
  The problem isn't "some code which different services use is in a library". The problem is an not-ideal "the code which is in libraries shared by different services is tightly-coupled to particular services". e.g. changing the shared library might break some service which depends on it. Obviously, you don't want code like that. But it's easy to write code which is slightly coupled; and then when you're in a hurry, to increase the coupling.

nicoburns 6y ago

Perhaps they shouldn't be microservices. What would be the disadvantage if you combined your microservices into a monolith? Or perhaps 4-5 "macroservices"?

jayd16 6y ago
In this case I think the disadvantages would be you're locked into one machine type and your blast radius is a bit wider.

BurningFrog 6y ago

One "wisdom" I hear is that the benefit of microservices is organizational: One microservice per team, so you cut down on intra-team friction, and the team can manage their own releases.

beastcoast 6y ago
What people miss is that micro services/SOA is an organizational concept more than anything. At Amazon, SOA is tied to the concept of the two pizza team. Each 2PT completely owns a collection of related services, owns the roadmap for those services, and can make deployments independently of any other team. If your company doesn’t have enough engineers to justify at least say 5-10 scrum teams then you might not be large enough to need microservices.
- ex_amazon_sde 6y ago
  Spot on! This is the right granularity.
dfcowell 6y ago
Microservices are a solution for scaling teams, not software or infrastructure. (In other words, you're 100% spot on!)

taneq 6y ago

I was going to make some sarcastic response to the effect of "iT's EvErGReeN" but this is basically the only answer. You don't do individual releases of your microservices any more than you do individual releases of the classes/functions in your C++ project.