3 ms·

> You can already share and resuse components, modules, stores, functions? You're absolutely right that we can, but the issue is that most teams are too large

by ratww 6y ago

> You can already share and resuse components, modules, stores, functions? You're absolutely right that we can, but the issue is that most teams are too large or too disorganised to share complex codebases, so they choose to do a hard division: splitting the code itself. Here's an argument that I love: Microservices and microfrontends are (most of the time) a failure of encapsulation [1]. Of course there are other benefits, such as separate deployment processes and ability to use different frameworks. [1] https://michaelfeathers.silvrback.com/microservices-and-the-failure-of-encapsulaton https://michaelfeathers.silvrback.com/microservices-and-the-...

k__ 6y ago
To me, microservices were more about scalability than encapsulation. Maybe that's the reason that I find serverless more promising.
- rumanator 6y ago
  Sometimes it appears that microservices contrarians are just focused on nitpicking while turning a blind eye to the myriad of advantages that justify their existence and widespread adoption. It's similar to how it's fashionable to criticize Java or C++ just for the heck of it. Sure, the architecture style is not a panacea and there are plenty of downsides and some projects made poor decisions and some evangelists try to make a career selling their snake lard. However, one just need to understand that vertical scaling is not a panacea or effective in reducing latency or providing reliability to understand the need for microservices.
  - JamesBarney 6y ago
    I feel like the debate between the microservices evangelists and the contrarians are "Microservices are a best practice you should almost always use" and "Microservices are a tool for primarily splitting up development teams when they get too large to manage, i.e. a technical solution to an organization problem".
    - rumanator 6y ago
      The organizational part is just one of the many advantages, and arguably the least relevant of the bunch as it's only relevant for huge projects requiring dozens of developers working concurrently
      - JamesBarney 6y ago
        Is modularity a huge benefit when most languages allow you to compose applications into modules which have keywords to enforce encapsulation? And scalability seems like an incremental benefit at best. If you're cpu bound you can load balance without microservices. And if you're database bound (and have already cached, optimized, and scaled up your db) you can scale up your db to multiple instances. Even Stackoverflow runs their entire infrastructure on just 4 db machines.
rumanator 6y ago
> an argument that I love: Microservices and microfrontends are (most of the time) a failure of encapsulation [1] There are plenty of problems and challenges with microservices, but that rant makes no sense at all. The blogger does not understand the upside of running separate processes? And then although he presents himself totally oblivious to the problem somehow asserts that "programming languages give us all we need to encapsulate state and environment", claiming that any shortcoming is due to people doing it wrong? Quite frankly, that article is just a rant devoid of any rational point, and it surprised me how it has been presented as some sort of argument on an entire architecture style.
- deleted 6y ago
  [deleted]

by ratww 6y ago

k__ 6y ago

To me, microservices were more about scalability than encapsulation. Maybe that's the reason that I find serverless more promising.

rumanator 6y ago
Sometimes it appears that microservices contrarians are just focused on nitpicking while turning a blind eye to the myriad of advantages that justify their existence and widespread adoption. It's similar to how it's fashionable to criticize Java or C++ just for the heck of it. Sure, the architecture style is not a panacea and there are plenty of downsides and some projects made poor decisions and some evangelists try to make a career selling their snake lard. However, one just need to understand that vertical scaling is not a panacea or effective in reducing latency or providing reliability to understand the need for microservices.
- JamesBarney 6y ago
  I feel like the debate between the microservices evangelists and the contrarians are "Microservices are a best practice you should almost always use" and "Microservices are a tool for primarily splitting up development teams when they get too large to manage, i.e. a technical solution to an organization problem".
  - rumanator 6y ago
    The organizational part is just one of the many advantages, and arguably the least relevant of the bunch as it's only relevant for huge projects requiring dozens of developers working concurrently
    - JamesBarney 6y ago
      Is modularity a huge benefit when most languages allow you to compose applications into modules which have keywords to enforce encapsulation? And scalability seems like an incremental benefit at best. If you're cpu bound you can load balance without microservices. And if you're database bound (and have already cached, optimized, and scaled up your db) you can scale up your db to multiple instances. Even Stackoverflow runs their entire infrastructure on just 4 db machines.

rumanator 6y ago

> an argument that I love: Microservices and microfrontends are (most of the time) a failure of encapsulation [1] There are plenty of problems and challenges with microservices, but that rant makes no sense at all. The blogger does not understand the upside of running separate processes? And then although he presents himself totally oblivious to the problem somehow asserts that "programming languages give us all we need to encapsulate state and environment", claiming that any shortcoming is due to people doing it wrong? Quite frankly, that article is just a rant devoid of any rational point, and it surprised me how it has been presented as some sort of argument on an entire architecture style.

deleted 6y ago
[deleted]