I don't like the phrase "microservice" because it now has a certain amount of baggage, similar to "service oriented architecture" which it was meant to be somew

I don't like the phrase "microservice" because it now has a certain amount of baggage, similar to "service oriented architecture" which it was meant to be somewhat of a counter-point to. Whereas the issue with SOA was its association with maligned/feared technologies (SOAP, WSDLs, CORBA), the issue with microservices is the implied granularity. SOA was a good idea, but people (particularly in start-ups) don't want to say they're doing SOA because it has old-school, corporate connotations. On the other hand, the granularity of microservices seems too extreme for what most products would actually need but the concept is associated with more modern technologies which are attractive to developers, like gRPC or Avro or Kubernetes (or even something as simple as HTTP). So I would say the most pragmatic approach for a greenfield web product (rather than a corporate IT integration) is have a fairly standard core (probably a REST API, a server-side MVC framework, or a GraphQL backend if you're nasty) and factor out services that make sense to the team (maybe a service that handles push notifications, or a service that does image processing, or a service that is the secret sauce of your product) because they need to scale independently or handle async/computational tasks that should have dedicated resources or they pull from a data source that is orthogonal to the rest of the system. You need to strike a balance between "micro" and "service". There is this idea that you either have microservices or you have a monolith, while its really more of a gradient. I guess what I'm advocating for is "modern service-oriented architecture" or "chunky services" vs "microservices"; reasonably sized, well-considered services that use modern technologies for inter-service communication.