6 ms·

> A requirement of a specific framework for all services. Eh, I don't see this as an antipattern. Building disparate services but using the same frameworks/lan

by rco8786 10y ago

> A requirement of a specific framework for all services. Eh, I don't see this as an antipattern. Building disparate services but using the same frameworks/languages has tons of advantages and relatively few(none?) disadvantages. A few: - Engineers can move between teams and features more seamlessly - Infrastructure and common functionality can be shared - You will inevitably end up debugging someone else's code when it comes to on-call, that's gonna suck if it looks completely different/foreign to you than what you use day to day.

marcosdumay 10y ago
Yet, that negates one of the few advantages services have for most people, that is the capacity of migrating between development tools without porting all the code, so they can use the best tool for the problem, or change away from obsolete tooling. As often is the case, the best place is normally between those extrema. You probably want to restrict languages and frameworks, but you probably do not want to dictate any single one. Or, if you want to dictate a single one, you'll probably want a monolith.
philipov 10y ago
Teams are highly coupled by their dependence on a common framework: they can't choose their own tools, and you are at high risk of having to coordinate with another team (the framework team) to release a new feature, all of which are things microservices are supposed to eliminate. Therefore, it's an antipattern.
- quantumhobbit 10y ago
  I've seen this happen where you develop a micro service and everything is working fine but the framework team makes a breaking change and doesn't tell you. Now your micro service is broken and it is somehow your fault because only your team is responsible for the micro service.
  - yeukhon 10y ago
    Yes, dependency management is never fun. I think the current approach we have in all languages fail short because we all depend on a text file declaring dependencies. We need to be able track the dependencies and versions. As part of the build process before merging code into a release branch or master branch, it's probably worth reading the flat file, parse the content, and check with a service (backed by a database). -> depends A -> B B -> C C -> nothing D -> A If A has changed, then on merging A, we should run D with new A. If C changed, then A, B, C, D are need to be tested. A flag or a tag for "non-backward compatible" should be added so on merging we can notify the developers (both producer of the library and consumer of the library) aware of breaking changes in their review queue. If breaking changes keep popping up, time for the tech leads and team managers of both sides to meet and understand how to avoid breaking changes so often. I don't know, someone working with large tech stack should comment on their experience. But we can't just use a text file and an email hoping someone would follow up or realize.
    - z3t4 10y ago
      in my experience its always worth doing extra work to avoid circular dependencies and couplings.
jrs95 10y ago
My experience with this requirement was that each of our "microservices" ended up consuming between 0.5 to 1 GB of RAM just to start up and connect to a database and a message bus. And these were simple CRUD services. Developers with older laptops couldn't even run all of the dependencies for what they were working on, and even those with better hardware were pushing the limits of their machines just a few months after adopting this architectural strategy.
- user5994461 10y ago
  "laptop" => Don't expect to run distributed systems on old laptop.
  - jrs95 10y ago
    I don't really think 3-4 micro services ought to be something one can't run locally relatively easily. Even with a brand new MBP I couldn't effectively develop full stack using just a handful of services without running out of memory. Though I suppose this is less about locking yourself into a single framework for your services, and more about not shipping insane amounts of bloat with each of your services.
    - user5994461 10y ago
      The "micro-service" name is a fallacy, there is no reason for services to be "micro" in size. The language runtimes and dependencies already add a lot of boilerplate, even for the simplest of services. You will also need databases and data sources in the same box. Laptop have little memory. MacBook are no exceptions.
    - majewsky 10y ago
      > I don't really think 3-4 micro services ought to be something one can't run locally relatively easily. To put things in perspective: There are in fact dozens of microservices running on every laptop out there. They're called "system processes" or "daemons".
- virmundi 10y ago
joshdick 10y ago
Sharing a framework for logging, routing, and other boring things is fine; sharing a framework with domain-specific logic is when you start getting into trouble. Now if you want to change something in that framework, you have to change and deploy every last one of your services.
- 3pt14159 10y ago
  I don't know that many frameworks with domain-specific logic. It almost seems like a contradiction in terms.
  - NathanKP 10y ago
    A classic example that I've encountered would be using some custom web socket RPC protocol for communication between microservices instead of just using plain HTTP. It can be tempting because an engineer thinks "I can optimize this and reduce the network overhead using this creative protocol." But now they have put themselves in a situation where if anything in that custom protocol changes they will have to update every single microservice in their backend ecosystem.
    - Falling3 10y ago
      That's really not domain specific though. It's just a proprietary protocol.
    - rco8786 10y ago
      How is that not a problem in HTTP? This is just API versioning, that needs to happen regardless of the protocol you choose. edit I see you mean the protocol itself (like if gRPC goes from version 1 to 1.2 or something). Yes, that's a thing... most protocol developers are careful about backwards compatibility to allow for some services to be behind a few minors to account for this. Also, HTTP still isn't invulnerable to this...HTTP/2 is very much a thing.
- lugg 10y ago
  > sharing domain specific logic Isn't that just called a business requirement? > you have to change and deploy every last one of your services. How is that different to code duplication as the article recommends? When business requirements change all affected code points needs to change.. you can't just wish that away. - The real problem here is mismanaging seperation of concerns. Cqs mostly solves the hard problems. But having shared read objects will, at times, require multiple systems to make use of the same domain logic. Whether you're better off with code duplication or a hard shared dep is a trade off up to you to figure out. I tend to go with a mix that makes sense based on expected frequency of change and how breaking the changes are likely to be. Another microservices is also one answer but can be an unworkable bottleneck for a lot of these types of situations.
quantumhobbit 10y ago
We have one of these and it is just a terrible internally developed framework, but we are stuck with it because all teams use it. If there was more freedom on the team level to pick better solutions, then the whole company would have likely standardized on something better by now.
- yeukhon 10y ago
  But the argument is you have a poor framework which was internally developed. This is considered a technical debt, and not a fault of sticking with one framework. I don't think people are arguing for only one framework is allowed, but rather the point is to establish a platform approved list of software/libraries. If you have reasons to believe moving to another framework is better in the long run, talk and bring up a plan how to address it. But I will say often people (both developers and managements) will dismiss rewrite / attempt to replace components because they think it's better off to leave things alone. This is a double sword: low morale and excitement to work on a project despite the product is unstable, but fear of failure after replacing / rewriting. strong technical leadership is often absence. This is actually quite important from both licensing and security point of view, and having such list available encourages discussions. I'd like to write one of my services in Go, but does my company have the resource to maintain Go application after I depart? What are the strong technical reasons that the service must be written in Go rather than in Python or in Java? If Go is approved, then I need to make sure management offers training / materials for developers to learn Go, and that I am available to train others (have good documentation, brown bag sessions and what not).
  - quantumhobbit 10y ago
    "I don't think people are arguing for only one framework is allowed" Read the post I replied to. It advocates requiring a single framework. Yes I am worse off because the framework sucks but there is no incentive for it to improve because everyone is forced to use it. I would love an approved list as you suggest because at least that would allow some choice, but even better than that would be working at a place that trusted me as an engineer to make those decisions myself.
- 10y ago

by rco8786 10y ago

marcosdumay 10y ago

Yet, that negates one of the few advantages services have for most people, that is the capacity of migrating between development tools without porting all the code, so they can use the best tool for the problem, or change away from obsolete tooling. As often is the case, the best place is normally between those extrema. You probably want to restrict languages and frameworks, but you probably do not want to dictate any single one. Or, if you want to dictate a single one, you'll probably want a monolith.

philipov 10y ago

Teams are highly coupled by their dependence on a common framework: they can't choose their own tools, and you are at high risk of having to coordinate with another team (the framework team) to release a new feature, all of which are things microservices are supposed to eliminate. Therefore, it's an antipattern.

quantumhobbit 10y ago
I've seen this happen where you develop a micro service and everything is working fine but the framework team makes a breaking change and doesn't tell you. Now your micro service is broken and it is somehow your fault because only your team is responsible for the micro service.
- yeukhon 10y ago
  Yes, dependency management is never fun. I think the current approach we have in all languages fail short because we all depend on a text file declaring dependencies. We need to be able track the dependencies and versions. As part of the build process before merging code into a release branch or master branch, it's probably worth reading the flat file, parse the content, and check with a service (backed by a database). -> depends A -> B B -> C C -> nothing D -> A If A has changed, then on merging A, we should run D with new A. If C changed, then A, B, C, D are need to be tested. A flag or a tag for "non-backward compatible" should be added so on merging we can notify the developers (both producer of the library and consumer of the library) aware of breaking changes in their review queue. If breaking changes keep popping up, time for the tech leads and team managers of both sides to meet and understand how to avoid breaking changes so often. I don't know, someone working with large tech stack should comment on their experience. But we can't just use a text file and an email hoping someone would follow up or realize.
  - z3t4 10y ago
    in my experience its always worth doing extra work to avoid circular dependencies and couplings.

jrs95 10y ago

My experience with this requirement was that each of our "microservices" ended up consuming between 0.5 to 1 GB of RAM just to start up and connect to a database and a message bus. And these were simple CRUD services. Developers with older laptops couldn't even run all of the dependencies for what they were working on, and even those with better hardware were pushing the limits of their machines just a few months after adopting this architectural strategy.

user5994461 10y ago
"laptop" => Don't expect to run distributed systems on old laptop.
- jrs95 10y ago
  I don't really think 3-4 micro services ought to be something one can't run locally relatively easily. Even with a brand new MBP I couldn't effectively develop full stack using just a handful of services without running out of memory. Though I suppose this is less about locking yourself into a single framework for your services, and more about not shipping insane amounts of bloat with each of your services.
  - user5994461 10y ago
    The "micro-service" name is a fallacy, there is no reason for services to be "micro" in size. The language runtimes and dependencies already add a lot of boilerplate, even for the simplest of services. You will also need databases and data sources in the same box. Laptop have little memory. MacBook are no exceptions.
  - majewsky 10y ago
    > I don't really think 3-4 micro services ought to be something one can't run locally relatively easily. To put things in perspective: There are in fact dozens of microservices running on every laptop out there. They're called "system processes" or "daemons".
virmundi 10y ago

joshdick 10y ago

Sharing a framework for logging, routing, and other boring things is fine; sharing a framework with domain-specific logic is when you start getting into trouble. Now if you want to change something in that framework, you have to change and deploy every last one of your services.

3pt14159 10y ago
I don't know that many frameworks with domain-specific logic. It almost seems like a contradiction in terms.
- NathanKP 10y ago
  A classic example that I've encountered would be using some custom web socket RPC protocol for communication between microservices instead of just using plain HTTP. It can be tempting because an engineer thinks "I can optimize this and reduce the network overhead using this creative protocol." But now they have put themselves in a situation where if anything in that custom protocol changes they will have to update every single microservice in their backend ecosystem.
  - Falling3 10y ago
    That's really not domain specific though. It's just a proprietary protocol.
  - rco8786 10y ago
    How is that not a problem in HTTP? This is just API versioning, that needs to happen regardless of the protocol you choose. edit I see you mean the protocol itself (like if gRPC goes from version 1 to 1.2 or something). Yes, that's a thing... most protocol developers are careful about backwards compatibility to allow for some services to be behind a few minors to account for this. Also, HTTP still isn't invulnerable to this...HTTP/2 is very much a thing.
lugg 10y ago
> sharing domain specific logic Isn't that just called a business requirement? > you have to change and deploy every last one of your services. How is that different to code duplication as the article recommends? When business requirements change all affected code points needs to change.. you can't just wish that away. - The real problem here is mismanaging seperation of concerns. Cqs mostly solves the hard problems. But having shared read objects will, at times, require multiple systems to make use of the same domain logic. Whether you're better off with code duplication or a hard shared dep is a trade off up to you to figure out. I tend to go with a mix that makes sense based on expected frequency of change and how breaking the changes are likely to be. Another microservices is also one answer but can be an unworkable bottleneck for a lot of these types of situations.

quantumhobbit 10y ago

We have one of these and it is just a terrible internally developed framework, but we are stuck with it because all teams use it. If there was more freedom on the team level to pick better solutions, then the whole company would have likely standardized on something better by now.

yeukhon 10y ago
But the argument is you have a poor framework which was internally developed. This is considered a technical debt, and not a fault of sticking with one framework. I don't think people are arguing for only one framework is allowed, but rather the point is to establish a platform approved list of software/libraries. If you have reasons to believe moving to another framework is better in the long run, talk and bring up a plan how to address it. But I will say often people (both developers and managements) will dismiss rewrite / attempt to replace components because they think it's better off to leave things alone. This is a double sword: low morale and excitement to work on a project despite the product is unstable, but fear of failure after replacing / rewriting. strong technical leadership is often absence. This is actually quite important from both licensing and security point of view, and having such list available encourages discussions. I'd like to write one of my services in Go, but does my company have the resource to maintain Go application after I depart? What are the strong technical reasons that the service must be written in Go rather than in Python or in Java? If Go is approved, then I need to make sure management offers training / materials for developers to learn Go, and that I am available to train others (have good documentation, brown bag sessions and what not).
- quantumhobbit 10y ago
  "I don't think people are arguing for only one framework is allowed" Read the post I replied to. It advocates requiring a single framework. Yes I am worse off because the framework sucks but there is no incentive for it to improve because everyone is forced to use it. I would love an approved list as you suggest because at least that would allow some choice, but even better than that would be working at a place that trusted me as an engineer to make those decisions myself.
10y ago