6 ms·

Yeah, the problem with microservices is because the organisation structure is wrong. I’ve literally heard every excuse about microservices at this point. My arc

Yeah, the problem with microservices is because the organisation structure is wrong. I’ve literally heard every excuse about microservices at this point. My architecture is better but it doesn’t have a snappy name; it’s called the smallest possible number of services that can be reasoned about and network partitions are NOT necessary to create bounded contexts in a codebase, often just a directory is FINE.

yowlingcat 7y ago
I agree. I hate the term microservice for the same reason I hate superlative infected clickbait titles. There's no need for half of the word to exist. Service. What's wrong with service?
- lllr_finger 7y ago
  I agree with you, but I find some value in people using that term - it signals to me that I should consider the the architecture was prematurely split-up and could suffer from the various pitfalls associated with microservices.
- cturner 7y ago
  Microservice implies systems that are decoupled for deployment purposes. For example, Microservice A could restart to a new version while Microservice B keeps running. This is a more complicated interaction contract than services where their deployment is coordinated in concert.
  - xorcist 7y ago
    But this was true in the middleware type of products too, and you can't get more monolithic than that.
  - brown9-2 7y ago
    I don’t think this is accurate. I’ve worked at companies that did “service-oriented architecture” long before the rise of the term “microservice” and it was clearly recognized that different “services” shouldn’t be so coupled together you can’t redeploy them separately.
    - deleted 7y ago
      [deleted]
    - scaryclam 7y ago
      Yes, you're right. A system that requires services to be deployed together is just a distributed monolith.
    - cturner 7y ago
      This thread considered an issue: whether services and microservices are equivalent concepts. They are not. There is a quality that is held by Microservices, yet which is not universally held by Services. You have observed that other services also have that quality. Indeed. Nowhere did I say, "all services with decoupled deployment are microservices".
      - cturner 7y ago
        Revisit. I can where brown9 is coming from. I could have avoided leaving that interpretation open by writing, "here is an example of a quality that is held by all X, yet not by all Y".
- vorpalhex 7y ago
  There was a period of time when Service had a different meaning than microservice. A service traditionally may exist across bounded contexts and be almost a mini-monolith whereas a strict microservice should touch very few data models and exist strictly in a bounded context. Of course real life is messy and plenty of people realized writing small single purpose services was valuable, and plenty of people build giant "microservices" that have nothing to do with the original term and are just badly constructed monoliths.
- corpMaverick 7y ago
  It is probably too late to change the name. But you have a good point, the "micro" prefix is highly misleading. Furthermore, there is little guidance in the literature on how big the microservices are.
- JohnL4 7y ago
  Plenty. A subroutine is a service. A library is a service. A Windows daemon is a service. The vendor I just inked a contract with provides a service. A web service is a service. I really hate that word when used without further definition.
  - wtetzner 7y ago
    > A subroutine is a service. Which makes the term "microservice" even weirder, given that any microservice is going to be bigger than a single subroutine.
- rumanator 7y ago
  > There's no need for half of the word to exist. Yes there is. A service is a very generic concept to the point it's only relevant as a high-level concept. The concept of a microservice makes all the sense in the world if you look back to where we came from: web services. When compared with all the work and requirements and complications of using SOAP and WSDL and UDDI and everything around, just sending small JSON payloads around, and the ability to peel off smaller services leveraging that architecture approach, was a far lighter and uncomplicated way of doing business. I mean, the name microservices becomes obvious once you look back and all that you see is macroservices.
jrochkind1 7y ago
That's not what the person you are replying to said though, "the organizational structure is wrong". More like: It is a mistake to use microservices UNLESS you have a certain organizational structure/capacity already. I think they were saying something more aligned with your opinion than you read it as.
- Retric 7y ago
  We are dealing with poorly defined terms. However, services mapping ~1:1 teams was generally called service oriented architecture not micro services. Micro services involved breaking things into even smaller chunks, so backing off of that idea really just means SOA as originally defined is a bad idea.
  - parasubvert 7y ago
    That’s not quite right, SOA as originally defined had no mapping to team structure or deployment runtime, it was mostly about defining discrete service interfaces and ensuring your clients used that contract rather than back channels to communicate. Most often you had a dozen services running in a single app server cluster. Conway’s law was rarely discussed (with some exceptions). Microservices tended towards a single runtime per service, ensuring the deployment lifecycle was tied to the build lifecycle and thus allowing for independent evolution.
    - deleted 7y ago
      [deleted]
    - Retric 7y ago
      I am not saying that’s how SOA was defined, just that it was used to refer to such team organization around architecture. EX: Amazon famously uses a Service-oriented architecture where a service often maps 1:1 with a team of 3 to 10 engineers. https://en.wikipedia.org/wiki/Microservices https://en.wikipedia.org/wiki/Microservices At the beginning Microservice was generally viewed as more granular than SOA, though that’s been backed off of.
quickthrower2 7y ago
Or an NPM package works nicely (or .NET assembly, Ruby Gem, Java whatever, etc.)
- andy_ppp 7y ago
  Library code for sensibly defined pieces 100%... but if you aren't sure of the abstraction, copying code can be more forgiving than making a mess.

yowlingcat 7y ago

I agree. I hate the term microservice for the same reason I hate superlative infected clickbait titles. There's no need for half of the word to exist. Service. What's wrong with service?

lllr_finger 7y ago
I agree with you, but I find some value in people using that term - it signals to me that I should consider the the architecture was prematurely split-up and could suffer from the various pitfalls associated with microservices.
cturner 7y ago
Microservice implies systems that are decoupled for deployment purposes. For example, Microservice A could restart to a new version while Microservice B keeps running. This is a more complicated interaction contract than services where their deployment is coordinated in concert.
- xorcist 7y ago
  But this was true in the middleware type of products too, and you can't get more monolithic than that.
- brown9-2 7y ago
  I don’t think this is accurate. I’ve worked at companies that did “service-oriented architecture” long before the rise of the term “microservice” and it was clearly recognized that different “services” shouldn’t be so coupled together you can’t redeploy them separately.
  - deleted 7y ago
    [deleted]
  - scaryclam 7y ago
    Yes, you're right. A system that requires services to be deployed together is just a distributed monolith.
  - cturner 7y ago
    This thread considered an issue: whether services and microservices are equivalent concepts. They are not. There is a quality that is held by Microservices, yet which is not universally held by Services. You have observed that other services also have that quality. Indeed. Nowhere did I say, "all services with decoupled deployment are microservices".
    - cturner 7y ago
      Revisit. I can where brown9 is coming from. I could have avoided leaving that interpretation open by writing, "here is an example of a quality that is held by all X, yet not by all Y".
vorpalhex 7y ago
There was a period of time when Service had a different meaning than microservice. A service traditionally may exist across bounded contexts and be almost a mini-monolith whereas a strict microservice should touch very few data models and exist strictly in a bounded context. Of course real life is messy and plenty of people realized writing small single purpose services was valuable, and plenty of people build giant "microservices" that have nothing to do with the original term and are just badly constructed monoliths.
corpMaverick 7y ago
It is probably too late to change the name. But you have a good point, the "micro" prefix is highly misleading. Furthermore, there is little guidance in the literature on how big the microservices are.
JohnL4 7y ago
Plenty. A subroutine is a service. A library is a service. A Windows daemon is a service. The vendor I just inked a contract with provides a service. A web service is a service. I really hate that word when used without further definition.
- wtetzner 7y ago
  > A subroutine is a service. Which makes the term "microservice" even weirder, given that any microservice is going to be bigger than a single subroutine.
rumanator 7y ago
> There's no need for half of the word to exist. Yes there is. A service is a very generic concept to the point it's only relevant as a high-level concept. The concept of a microservice makes all the sense in the world if you look back to where we came from: web services. When compared with all the work and requirements and complications of using SOAP and WSDL and UDDI and everything around, just sending small JSON payloads around, and the ability to peel off smaller services leveraging that architecture approach, was a far lighter and uncomplicated way of doing business. I mean, the name microservices becomes obvious once you look back and all that you see is macroservices.

jrochkind1 7y ago

That's not what the person you are replying to said though, "the organizational structure is wrong". More like: It is a mistake to use microservices UNLESS you have a certain organizational structure/capacity already. I think they were saying something more aligned with your opinion than you read it as.

Retric 7y ago
We are dealing with poorly defined terms. However, services mapping ~1:1 teams was generally called service oriented architecture not micro services. Micro services involved breaking things into even smaller chunks, so backing off of that idea really just means SOA as originally defined is a bad idea.
- parasubvert 7y ago
  That’s not quite right, SOA as originally defined had no mapping to team structure or deployment runtime, it was mostly about defining discrete service interfaces and ensuring your clients used that contract rather than back channels to communicate. Most often you had a dozen services running in a single app server cluster. Conway’s law was rarely discussed (with some exceptions). Microservices tended towards a single runtime per service, ensuring the deployment lifecycle was tied to the build lifecycle and thus allowing for independent evolution.
  - deleted 7y ago
    [deleted]
  - Retric 7y ago
    I am not saying that’s how SOA was defined, just that it was used to refer to such team organization around architecture. EX: Amazon famously uses a Service-oriented architecture where a service often maps 1:1 with a team of 3 to 10 engineers. https://en.wikipedia.org/wiki/Microservices https://en.wikipedia.org/wiki/Microservices At the beginning Microservice was generally viewed as more granular than SOA, though that’s been backed off of.

quickthrower2 7y ago

Or an NPM package works nicely (or .NET assembly, Ruby Gem, Java whatever, etc.)

andy_ppp 7y ago
Library code for sensibly defined pieces 100%... but if you aren't sure of the abstraction, copying code can be more forgiving than making a mess.