4 ms·

You are not getting more reusability from a bunch of microservices, compared to one big service, I don't see where you got that?

fleitz 10y ago
It's especially fun when you get to write the monolith 3 times over for web, ios and android.
- carterehsmith 10y ago
  Why would you write it three times? You write it once, have it expose an API. Have your Web, IOS and Adroid client use the said API. Easy pease. Optional: allow your customers to use the API, too.
  - fleitz 10y ago
    That's not 'microservices'
vog 10y ago
I also don't see how microservices are more reusable. However, the replacability is usually much better due to being forced to define sharp boundaries with clear interfaces.
- pjmlp 10y ago
  But that is the thing. It just means that instead of using the language features and creating clean interfaces across modules, they were witting spaghetti code. With microservices they get to write spaghetti REST calls with the added fun of distributed computing failures.
- sanmon3186 10y ago
  > the replacability is usually much better due to being forced to define sharp boundaries with clear interfaces If by "sharp boundaries with clear interfaces", you mean API specification, how is it a microservice thing? I thought the benefits of microservices lie in behind-the-scenes details.
- IshKebab 10y ago
  Normal software libraries also have sharp boundaries with clear interfaces. Why use shitty RPC-over-HTTP? At the very least you can use something sane like Thrift.
_pmf_ 10y ago
I think it's the old loose coupling vs. late binding discussion. Some people confuse the former with the latter. You can very mechanically achieve late binding with microservices, but it takes extra effort to actually achieve loose coupling; and guess what, the effort might or might not be less than doing loose coupling within the components of a monolith.
- kevinr 10y ago
  I was just reading the other day this article about the Backend for Frontend pattern (BFF) which suggests the best way to avoid tight coupling is for services you don't want tightly coupled to be owned by different teams, and to allow reasonable duplication of functionality between them. Everybody knows how hard it is to get another team to implement functionality for you. This is where I got the BFF pattern from: http://samnewman.io/patterns/architectural/bff/ http://samnewman.io/patterns/architectural/bff/
  - _pmf_ 10y ago
    I fully agree with this. If a system cannot be extended by some external team using only external extension points, all claims of modularity and architecture are idle talk. I tend to use MEF (on .NET) and OSGi (on the JVM) not because I actually need extensibility, but because I want to enforce certain architectural constraints.
onion2k 10y ago
You are if you care about whether you're deploying things that aren't necessary. With microservices you can take a single specific service that two projects share and reuse it. With a monolith you can't unless you deploy everything else as well. That can easily fail a requirements check (say, hardware requirements are too costly) and force you to redevelop the service for the second project.
- deleted 10y ago
  [deleted]
- weego 10y ago
  I'm not trying to be facetious, but isn't that just called a library?
  - onion2k 10y ago
    Not as I understand microservices. A library would be something that's compiled or included in to your application code. A microservice is a separate process that the application communicates with over a protocol (eg http).
    - sbov 10y ago
      I think the point is you can achieve the same result by just using a library. There are potential benefits and downsides to services over libraries of course, but unless there are specific requirements that make a library unsuitable, all else equal I would rather just use a library.
      - zby 10y ago
        With some work you can have the some behaviour - but the microservice is also about the data (like user ids and passwords for a login microservice).
      - onion2k 10y ago
        Microservices also enable you to scale individual parts of your application. If you need better performance for, say, image compression then it's much easier to add resources to a service that lives in its own process space (or its own server, or rack of servers, or data centre..) than it is to improve the performance of a specific library in a larger application.
rodgerd 10y ago
From experience at the classic ball o' mud web servicey end of the spectrum, because it gets to hard to manage and deploy and test services that you end up standing up new services to do "the same thing only slightly different" because reusing existing services is too hard.
lobster_johnson 10y ago
You missed my point. I did not say reusability is the only factor that dictates the use of microservices. If we wrote everything as one big service, we'd lose the dozen-or-so benefits of microservices. Hypothetically, if we rewrote what we have today as one big monolith: * We couldn't selectively open-source parts of it. * It'd really all have to be a single language, as opposed to the three we use right now. * ...and if we decided to change the language (like we're in the process of doing with a transition from Ruby to Go + Node.js), we'd have to rewrite all of it. * Deployment would be potentially more brittle since you're deploying a single codebase. Our apps are designed to gracefully tolerate partial unavailability. * We'd have to be careful to control individual services' resource footprint. We have some services which are super light and have very few dependencies — they don't carry a monolith on their back. * We'd have to jam in product-specific stuff for N different products into a single codebase. Some of our microservices aren't reusable; they're completely product-specific. Squishing lots of unrelated concerns into a single codebase is not feasible. * Developers would be trying to tightly couple services and violate separation of concerns faster than you can spell "technical debt". ...and so forth. Maybe I didn't articulate it well enough, but my original point was that microservices are great for all sorts of reasons, but also a too-often missed point is the benefits of reusability if you just design thing right. Put differently, microservices are a lot less powerful if you don't design them for reusability (and, as a prerequisite, multi-tenancy)

fleitz 10y ago

It's especially fun when you get to write the monolith 3 times over for web, ios and android.

carterehsmith 10y ago
Why would you write it three times? You write it once, have it expose an API. Have your Web, IOS and Adroid client use the said API. Easy pease. Optional: allow your customers to use the API, too.
- fleitz 10y ago
  That's not 'microservices'

vog 10y ago

I also don't see how microservices are more reusable. However, the replacability is usually much better due to being forced to define sharp boundaries with clear interfaces.

pjmlp 10y ago
But that is the thing. It just means that instead of using the language features and creating clean interfaces across modules, they were witting spaghetti code. With microservices they get to write spaghetti REST calls with the added fun of distributed computing failures.
sanmon3186 10y ago
> the replacability is usually much better due to being forced to define sharp boundaries with clear interfaces If by "sharp boundaries with clear interfaces", you mean API specification, how is it a microservice thing? I thought the benefits of microservices lie in behind-the-scenes details.
IshKebab 10y ago
Normal software libraries also have sharp boundaries with clear interfaces. Why use shitty RPC-over-HTTP? At the very least you can use something sane like Thrift.

_pmf_ 10y ago

I think it's the old loose coupling vs. late binding discussion. Some people confuse the former with the latter. You can very mechanically achieve late binding with microservices, but it takes extra effort to actually achieve loose coupling; and guess what, the effort might or might not be less than doing loose coupling within the components of a monolith.

kevinr 10y ago
I was just reading the other day this article about the Backend for Frontend pattern (BFF) which suggests the best way to avoid tight coupling is for services you don't want tightly coupled to be owned by different teams, and to allow reasonable duplication of functionality between them. Everybody knows how hard it is to get another team to implement functionality for you. This is where I got the BFF pattern from: http://samnewman.io/patterns/architectural/bff/ http://samnewman.io/patterns/architectural/bff/
- _pmf_ 10y ago
  I fully agree with this. If a system cannot be extended by some external team using only external extension points, all claims of modularity and architecture are idle talk. I tend to use MEF (on .NET) and OSGi (on the JVM) not because I actually need extensibility, but because I want to enforce certain architectural constraints.

onion2k 10y ago

You are if you care about whether you're deploying things that aren't necessary. With microservices you can take a single specific service that two projects share and reuse it. With a monolith you can't unless you deploy everything else as well. That can easily fail a requirements check (say, hardware requirements are too costly) and force you to redevelop the service for the second project.

deleted 10y ago
[deleted]
weego 10y ago
I'm not trying to be facetious, but isn't that just called a library?
- onion2k 10y ago
  Not as I understand microservices. A library would be something that's compiled or included in to your application code. A microservice is a separate process that the application communicates with over a protocol (eg http).
  - sbov 10y ago
    I think the point is you can achieve the same result by just using a library. There are potential benefits and downsides to services over libraries of course, but unless there are specific requirements that make a library unsuitable, all else equal I would rather just use a library.
    - zby 10y ago
      With some work you can have the some behaviour - but the microservice is also about the data (like user ids and passwords for a login microservice).
    - onion2k 10y ago
      Microservices also enable you to scale individual parts of your application. If you need better performance for, say, image compression then it's much easier to add resources to a service that lives in its own process space (or its own server, or rack of servers, or data centre..) than it is to improve the performance of a specific library in a larger application.

rodgerd 10y ago

From experience at the classic ball o' mud web servicey end of the spectrum, because it gets to hard to manage and deploy and test services that you end up standing up new services to do "the same thing only slightly different" because reusing existing services is too hard.

lobster_johnson 10y ago

You missed my point. I did not say reusability is the only factor that dictates the use of microservices. If we wrote everything as one big service, we'd lose the dozen-or-so benefits of microservices. Hypothetically, if we rewrote what we have today as one big monolith: * We couldn't selectively open-source parts of it. * It'd really all have to be a single language, as opposed to the three we use right now. * ...and if we decided to change the language (like we're in the process of doing with a transition from Ruby to Go + Node.js), we'd have to rewrite all of it. * Deployment would be potentially more brittle since you're deploying a single codebase. Our apps are designed to gracefully tolerate partial unavailability. * We'd have to be careful to control individual services' resource footprint. We have some services which are super light and have very few dependencies — they don't carry a monolith on their back. * We'd have to jam in product-specific stuff for N different products into a single codebase. Some of our microservices aren't reusable; they're completely product-specific. Squishing lots of unrelated concerns into a single codebase is not feasible. * Developers would be trying to tightly couple services and violate separation of concerns faster than you can spell "technical debt". ...and so forth. Maybe I didn't articulate it well enough, but my original point was that microservices are great for all sorts of reasons, but also a too-often missed point is the benefits of reusability if you just design thing right. Put differently, microservices are a lot less powerful if you don't design them for reusability (and, as a prerequisite, multi-tenancy)