3 ms·

My problem with microservices is the word 'micro'. It should just be services. Problem domains (along with organizational structures) inherently create natural

My problem with microservices is the word 'micro'. It should just be services. Problem domains (along with organizational structures) inherently create natural architectural boundaries... certain bits of data, computation, transactional logic, and programming skill just naturally "clump" together. Microservices ignore this natural order. The main driving architectural principle seems to be "I'm having trouble with my event-driven dynamically-typed metaprogrammed ball-of-mud, so we need more services!".

neuromantik8086 8y ago
It took me longer than it probably should have to realize that the term microservices was made by analogy to the term microkernel. I think that part of my main issue with the "microservices" is that it conflates highly technical semantics with word forms that are a bit more wishy washy in meaning (i.e., a service is something formed more of human perception, not rooted directly in operating system abstractions).
- bewo001 8y ago
  I wonder if microservices will have a similar evolution as microkernels. While some microkernels almost closed the performance gap to monolith kernels, the communication overhead killed them. It turned out that the kernel's complexity could be reduced by moving some functions to the applications ("library OS"). Linux kernel drivers are only accepted when the functionality can't be done in user space. The extreme version is running single purpose, highly specialized unikernels on a hypervisor.
  - lmm 8y ago
    > The extreme version is running single purpose, highly specialized unikernels on a hypervisor. Which, strangely enough, ends up looking almost the same thing as running services on a microkernel.
ex_amazon_sde 8y ago
> Problem domains (along with organizational structures) inherently create natural architectural boundaries The "natural" order is very often bad for reliability, speed and efficiency. It forces the "critical path" of a requests to jump through a number of different services. In well built SOA you often find that the problem space is segmented by criticality and failure domains, not by logical function.

neuromantik8086 8y ago

It took me longer than it probably should have to realize that the term microservices was made by analogy to the term microkernel. I think that part of my main issue with the "microservices" is that it conflates highly technical semantics with word forms that are a bit more wishy washy in meaning (i.e., a service is something formed more of human perception, not rooted directly in operating system abstractions).

bewo001 8y ago
I wonder if microservices will have a similar evolution as microkernels. While some microkernels almost closed the performance gap to monolith kernels, the communication overhead killed them. It turned out that the kernel's complexity could be reduced by moving some functions to the applications ("library OS"). Linux kernel drivers are only accepted when the functionality can't be done in user space. The extreme version is running single purpose, highly specialized unikernels on a hypervisor.
- lmm 8y ago
  > The extreme version is running single purpose, highly specialized unikernels on a hypervisor. Which, strangely enough, ends up looking almost the same thing as running services on a microkernel.

ex_amazon_sde 8y ago

> Problem domains (along with organizational structures) inherently create natural architectural boundaries The "natural" order is very often bad for reliability, speed and efficiency. It forces the "critical path" of a requests to jump through a number of different services. In well built SOA you often find that the problem space is segmented by criticality and failure domains, not by logical function.