5 ms·

"microservice" is certainly a buzzword, but it's not just service-oriented architecture. Mircoservice architecture is modular design, with all the advantages of

"microservice" is certainly a buzzword, but it's not just service-oriented architecture. Mircoservice architecture is modular design, with all the advantages of effectively infinite scale, incredibly flexible orchestration, and the resilience provided by the public cloud providers. It has it's own set of challenges, and it isn't the right solution for every problem. But it can be fantastic when used properly. I've written plenty of well performing API endpoints in microservices, and I've also done a fair bit of business process automation with them.

hueving 9y ago
It has nothing to do with the resilience of cloud providers. If the cloud providers were resilient, then you wouldn't need all of the wonderful scheduling tooling from stuff like kubernetes to deal with unstable individual machines. You can also certainly have a microservice architecture without running anything on the cloud at all. Microservices make it possible to simply deal with unstable environments. Cattle, not pets.
oblio 9y ago
And how is that not also service oriented architecture? That's also supposed to be modular and one of the reasons for splitting out service is to scale. You can then place those services in a cloud...
- bonesss 9y ago
  Microservice architectures are a sub-category of SOA. Many of the same reasons to use them apply to both, but with a finer granularity on what is being hosted where and how it is scaling with microservices. Scaling a service with multiple facets going through it gets tricky, hence a desire for a more appropriate modularity. "Placing services in the cloud" kinda papers over why microservices and cloud-native apps hang together so tightly... Leveraging cloud-provider capabilities (message queues, streaming services, specialized DBs, etc), often introduces new kinds of scaling, new requirements, and new deployment needs at the component level. Particularly if you're working in multiple clouds or a hybrid environment or with teams in different organizations... Tech stacks might diverge at the component level, developer competencies diverge, maintenance routines and monitoring and the rest of it too. A thin service wrapper in front of DynamoDB is gonna have a different scalability story than a DoItAll service on a VM that can also write to DynamoDB. Especially if the service is used by multiple apps, or customers in addition to apps. For a SaaS outfit that can be make or break.
  - oblio 9y ago
    Yes, I agree. My concern is more that microservices (as a sub-category of SOA) are a fad that few people will care about or use 10-20 years from now. Most services probably don't ever go beyond monolith, the rest move to SOA and probably a minuscule minority actually needs microservices.
  - cookiecaper 9y ago
    "Message queues, streaming services, specialized DBs, etc" have no intrinsic properties making them "cloud-provider capabilities". All of these "cloud-provider capabilities" are just normal software that you can run on your own hardware. In one or two cases, the software was first exposed via a particular provider's platform, but similar, and very likely superior software that accomplishes the same goals, is now available for self-hosting (Dynamo -> Cassandra or Riak, for example). That's about as strong as the connection gets. It doesn't follow that "microservices and cloud-native apps hang together" because the cloud provider charges you a lot of money to access their Redis server, when you could run your own Redis server.
manigandham 9y ago
All software is modular, whether those modules are individual functions or separate processes called over the network. Like I said, the computer doesn't care so it's really up to the dev team and organization to divide functionality as they see fit. There's no inherent "infinite scale" that magically shows up; proper architecture and design does that. "Microservices" again just goes back to being a rather badly defined description of a certain way of deployment. Every time I've seen these used (in smaller companies), there's no benefit over just having separate assemblies talking in the same process instead.

hueving 9y ago

It has nothing to do with the resilience of cloud providers. If the cloud providers were resilient, then you wouldn't need all of the wonderful scheduling tooling from stuff like kubernetes to deal with unstable individual machines. You can also certainly have a microservice architecture without running anything on the cloud at all. Microservices make it possible to simply deal with unstable environments. Cattle, not pets.

oblio 9y ago

And how is that not also service oriented architecture? That's also supposed to be modular and one of the reasons for splitting out service is to scale. You can then place those services in a cloud...

bonesss 9y ago
Microservice architectures are a sub-category of SOA. Many of the same reasons to use them apply to both, but with a finer granularity on what is being hosted where and how it is scaling with microservices. Scaling a service with multiple facets going through it gets tricky, hence a desire for a more appropriate modularity. "Placing services in the cloud" kinda papers over why microservices and cloud-native apps hang together so tightly... Leveraging cloud-provider capabilities (message queues, streaming services, specialized DBs, etc), often introduces new kinds of scaling, new requirements, and new deployment needs at the component level. Particularly if you're working in multiple clouds or a hybrid environment or with teams in different organizations... Tech stacks might diverge at the component level, developer competencies diverge, maintenance routines and monitoring and the rest of it too. A thin service wrapper in front of DynamoDB is gonna have a different scalability story than a DoItAll service on a VM that can also write to DynamoDB. Especially if the service is used by multiple apps, or customers in addition to apps. For a SaaS outfit that can be make or break.
- oblio 9y ago
  Yes, I agree. My concern is more that microservices (as a sub-category of SOA) are a fad that few people will care about or use 10-20 years from now. Most services probably don't ever go beyond monolith, the rest move to SOA and probably a minuscule minority actually needs microservices.
- cookiecaper 9y ago
  "Message queues, streaming services, specialized DBs, etc" have no intrinsic properties making them "cloud-provider capabilities". All of these "cloud-provider capabilities" are just normal software that you can run on your own hardware. In one or two cases, the software was first exposed via a particular provider's platform, but similar, and very likely superior software that accomplishes the same goals, is now available for self-hosting (Dynamo -> Cassandra or Riak, for example). That's about as strong as the connection gets. It doesn't follow that "microservices and cloud-native apps hang together" because the cloud provider charges you a lot of money to access their Redis server, when you could run your own Redis server.

manigandham 9y ago

All software is modular, whether those modules are individual functions or separate processes called over the network. Like I said, the computer doesn't care so it's really up to the dev team and organization to divide functionality as they see fit. There's no inherent "infinite scale" that magically shows up; proper architecture and design does that. "Microservices" again just goes back to being a rather badly defined description of a certain way of deployment. Every time I've seen these used (in smaller companies), there's no benefit over just having separate assemblies talking in the same process instead.