4 ms·

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.

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.

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.