5 ms·

To me, microservices address for many the continuing need for structures that hide complexity behind small, understandable interfaces. Black boxes if you will.

by aryehof 11y ago

To me, microservices address for many the continuing need for structures that hide complexity behind small, understandable interfaces. Black boxes if you will. Unlike components, which have no standard for connecting to and among each other, microservices do - in a relatively standard and easy to understand way. That's why they are so attractive. I find myself very much agreeing with the author, but being involved in modeling complex business problems into object-oriented code, I'm more frustrated that in a problem domain, we have no effective modular concept for groups of collaborating objects. We can't walk up to an object graph and immediately understand the functionality it performs and the services it provides.

crdoconnor 11y ago
>To me, microservices address for many the continuing need for structures that hide complexity behind small, understandable interfaces. You can have loosely coupled software with or without micro-services and you can have tightly coupled (ball of mud) software with or without micro-services. All microservices do is multiply the problems caused by creating that ball of mud. If you want to hide complexity behind small, understandable interfaces that's laudable goal, but it is not one that distributing your application across a network is going to help you with.
- DropkickM16 11y ago
  I think your first point is obvious, but I disagree with your second, at least 'at-scale'. In the case where you have loose coupling but are representing multiple entities that scale in different ways, microservices allow you to separate concerns and separately scale those concerns relative to their requirements in terms of memory/CPU/disk/network/etc. The best factored code running in a single horizontally-scaled layer will be inefficient if 90% of requests are manipulating entity A, and entities B, C, and D have a lot of intricate business logic but are rarely touched (they are better off if separated and scaled individually) The overhead you allude to is definitely something to take into account. If you're a 5-20 person startup without a serious need to scale up or lacking people who have built the tools that make microservices easy, you should avoid the issue for now. But ultimately, decoupling services so they can horizontally scale independently is a huge win.
  - crdoconnor 11y ago
    True, but if you prematurely divide your services up based upon what you think their performance requirements might be you will be wrong. That's premature optimization, which is, as we all know, the root of all evil. If you've loosely coupled your services until the point where it becomes obvious that two parts of the code have markedly different performance requirements and then you decide to split them into two separate services then yes, that could work, provided you understand the trade off you're making. I don't think that's typically what people mean by 'microservices' however. There's a good chance it'll still be wasted effort, too. Hardware is cheap. Developers are not. That applies to large businesses and small.
    - mfjordvald 11y ago
      I always saw the point of micro services as not having to figure out the scaling part yet. If you focus on grouping by purpose rather than what resource they might use then you can keep them on small instances until you better understand what kind of resource they require. Once you learn their usage pattern you can adapt more quickly (if scale is needed at all) and not have to first split up the code.

by aryehof 11y ago

crdoconnor 11y ago

>To me, microservices address for many the continuing need for structures that hide complexity behind small, understandable interfaces. You can have loosely coupled software with or without micro-services and you can have tightly coupled (ball of mud) software with or without micro-services. All microservices do is multiply the problems caused by creating that ball of mud. If you want to hide complexity behind small, understandable interfaces that's laudable goal, but it is not one that distributing your application across a network is going to help you with.

DropkickM16 11y ago
I think your first point is obvious, but I disagree with your second, at least 'at-scale'. In the case where you have loose coupling but are representing multiple entities that scale in different ways, microservices allow you to separate concerns and separately scale those concerns relative to their requirements in terms of memory/CPU/disk/network/etc. The best factored code running in a single horizontally-scaled layer will be inefficient if 90% of requests are manipulating entity A, and entities B, C, and D have a lot of intricate business logic but are rarely touched (they are better off if separated and scaled individually) The overhead you allude to is definitely something to take into account. If you're a 5-20 person startup without a serious need to scale up or lacking people who have built the tools that make microservices easy, you should avoid the issue for now. But ultimately, decoupling services so they can horizontally scale independently is a huge win.
- crdoconnor 11y ago
  True, but if you prematurely divide your services up based upon what you think their performance requirements might be you will be wrong. That's premature optimization, which is, as we all know, the root of all evil. If you've loosely coupled your services until the point where it becomes obvious that two parts of the code have markedly different performance requirements and then you decide to split them into two separate services then yes, that could work, provided you understand the trade off you're making. I don't think that's typically what people mean by 'microservices' however. There's a good chance it'll still be wasted effort, too. Hardware is cheap. Developers are not. That applies to large businesses and small.
  - mfjordvald 11y ago
    I always saw the point of micro services as not having to figure out the scaling part yet. If you focus on grouping by purpose rather than what resource they might use then you can keep them on small instances until you better understand what kind of resource they require. Once you learn their usage pattern you can adapt more quickly (if scale is needed at all) and not have to first split up the code.