7 ms·

One should probably not even think of microservices if one employs fewer than 100 programmers. In many cases microservices are introduced because of fashion and

by cjfd 5y ago

One should probably not even think of microservices if one employs fewer than 100 programmers. In many cases microservices are introduced because of fashion and/or resume driven design not because it actually makes sense. I prefer refactoring a poorly structured monolith to refactoring poorly structured microservices in every case.

solmag 5y ago
I like them for modularity, message queues and asynchronous events. But you are correct, esp. last one.
- cjfd 5y ago
  Things like message queues and asynchronous events are available for your favorite programming language for in-executable use. You can then do things like running them on a thread pool that has the same number of threads as your machine has cores.
  - jayd16 5y ago
    So you're not only suggesting monolith, but single instance? In process and non-shared queues only? No load balancing across monoliths?
    - imwillofficial 5y ago
      I didn’t read any of that. I read it as more tools in the toolbox.
      - jayd16 5y ago
        Without single instance, an in process queue doesn't provide the same kind of functionality that a shared queue does and would probably introduce split brain kind of problems, no?
        imwillofficial 5y ago
        Right, you’re taking it as a suggestion, as in a positive nudge to single instance monolithism. However, I read it as merely making GP aware of other options that are on the table.
    - cjfd 5y ago
      Not necessarily. That one can have these tools in-application doesn't mean one cannot combine this with some form of RPC as well. Especially whether one needs load balancing or not seem to be a completely orthogonal issue. On the other hand, why not a monolith and single instance? If one uses a performant language one would be amazed how much can run on a single machine. If one expects growth one should have some plan to scale, sure, but if one does not go for shenanigans like running queues and the like between applications using some form of RCP one might get amazed how much your single monolith can actually do. All this extra networks stuff and so on is not exactly free.
      - jayd16 5y ago
        >On the other hand, why not a monolith and single instance? Single points of failure are bad. I agree its orthogonal, which is why I inquired further about the, imo, odd suggestion.
        ratww 5y ago
        Running a single instance doesn’t mean not having a backup.
- wongarsu 5y ago
  Plenty of languages offer modularity, message queues and asynchronous events within a monolith. They are quite idiomatic in go, rust and elixir
  - foobarian 5y ago
    Splitting a system into microservices can help individual teams be better stewards of their part of the system. They can release on their own schedule, they can use their own linting rules, heck even a different language, and they can have better control of incoming code changes. With a monolith any random developer can go and flip some private method to public, import it way across the modules, and presto you are now building a ball of mud. Need an out of cycle release? Hopefully you have CI/CD or now you have to beg the SRE in charge to do it for you.
    - Sebb767 5y ago
      > Splitting a system into microservices can help individual teams be better stewards of their part of the system. Team being the keyword here. If you have 3-5 developers per microservice, you're absolutely okay. If you have 3-5 microservices per developer, that's when it gets ugly.
    - yakshaving_jgt 5y ago
      Given your negative characterisation of the "ball of mud", I'm guessing you haven't actually read the original paper. > heck even a different language There's nothing about writing software in different languages that necessitates separating functionality with HTTP calls.
      - foobarian 5y ago
        > There's nothing about writing software in different languages that necessitates separating functionality with HTTP calls I mean it's only computers and the only limit to what we can make them do is our imagination. In this case though for the sake of argument what options would I have if I, say, needed to let a remote team add some functionality to my, say, Spring backend but they really prefer to write C# and have their own CI/CD system. I'm not sure how I would accomplish this in a monolith.
BoorishBears 5y ago
To me microservices should not be an architecture. You can have pieces of functionality in a monolith that make sense to scale independently, and those should not be micro, they should be meaningful pieces of functionality that justify the overhead of spinning them out. In a way your comment reflects this, a lot of the places that justified microservices were at a scale where their "microservice" was serving more requests than the average company's entire codebase. It's "big data" with 10 GBs of logs all over again.
belter 5y ago
The whole problem starts with calling them microservices. Just call it a service oriented architecture please. The whole micro thing is already an indication of the kind of trouble you are getting yourself into. More respect to the monolith please.
- cjfd 5y ago
  Well, a service-oriented architecture is a more general category then microservices and has been around much longer. In many cases it is much more justifiable on technical grounds. Just to give one example. You have an API that is not the most stable thing in the world and when it misbehaves you do not want it to take the whole application down with it. So you put it in a separate service that can easily be restarted. That is a good technical reason for a separation of executables. Problems arise when people introduce these separations for no good reason. Then one gets all of the problems of RPC and none of the benefits. I.e., one is making things more complicated for no good reason.
  - jjoonathan 5y ago
    > and has been around much longer There's your problem. People understood the tradeoffs, so it needed a rebranding before it could go through another hype cycle.
- UglyToad 5y ago
  I'm going to build a lucrative personal brand / consulting business by hyping mesoservices, neither micro nor macro, just right.
  - belter 5y ago
    Reality and Fiction mingle together... "Mesoservices: Architecture for optimal trade-off between engineering and operations efficiency" https://www.codemotion.com/talks/mesoservices-architecture-for-optimal-trade-off-between-engineering-and-operations-efficiency-5774 https://www.codemotion.com/talks/mesoservices-architecture-f...
  - 5y ago
afarrell 5y ago
It is worth thinking about them before you need them because by the time you gain the skill and infra needed to support them, you’ll have scaled so large that your ability to coordinate and communicate will be overwhelmed.
- papito 5y ago
  How many startups out there have run into the problem of "oh no, we got too big too fast"?
  - afarrell 5y ago
    A fraction of the ones that are successful. I suppose what I really mean is: If your leadership subordinates (especially new joiners) are starting to struggle to coordinate, consider the possibility that you might already be at that point yet emotionally attached to the notion of staying small as you double or quadruple in population.
    - papito 5y ago
      I can guarantee you that most systems out there could serve production traffic on an old laptop, with well-written code and lean database queries. I have done things in MySQL v3 in 2006 that should not be done with a modern database even today (a taxonomy search engine 3 levels deep. Never again). In the age when database trips and network trips are treated as "free", we somehow arrived at MORE complicated solutions, like microservices. A "hello, world" problem in 99% of the cases is a "hello, world" problem. At Google - it is not. It's a scale problem. Everything is a scale problem at Google first, and a business logic problem second. The FAANG alumni has convinced the new generation of developers that everything is a scale problem.
m0llusk 5y ago
This doesn't match my experience at all. In particular, in the case where a small team is working on a series of small projects it can make a lot of sense to split up the components so that any one of the small projects can be built with one or two existing generalized components along with some custom machinery and some glue code to bring it all together. That way development of all of the small products can contribute to some well honed components that get shared by multiple products and development cycles. It seems like this is not coming up because the most common context of application is one or more teams working on a single large project probably forced to grow as fast as possible because of the funding structure involved. Increasingly, though, there are companies doing software development without the need for focus and scale that is so common to venture capital powered groups.
- mason55 5y ago
  The major difference is whether the small projects are independent applications that use some shared libraries (what I think you mean by "existing generalized components") or whether the small projects all talk to each other to create a single large application. If it's the former then you're just talking about refactoring functionality into a shared library, but at the end of the day you're still just building little monoliths. You don't have to worry about most of the problems that come up with microservices.
codyb 5y ago
A coworker at a previous four person startup was always advocating microservices. Having to push back on that over and over was frustrating. We didn’t even have a real devops guy, or a vpc with properly partitioned CIDR blocks to segregate our databases from the public web and we’re going to start adding the complexity of a microservice architecture? For what! We didn’t even have _users_ yet. But try to get folk to dogfood our application since we had no actual users besides the founder and it was like pulling teeth. Totally backwards to me.

by cjfd 5y ago

solmag 5y ago

I like them for modularity, message queues and asynchronous events. But you are correct, esp. last one.

cjfd 5y ago
Things like message queues and asynchronous events are available for your favorite programming language for in-executable use. You can then do things like running them on a thread pool that has the same number of threads as your machine has cores.
- jayd16 5y ago
  So you're not only suggesting monolith, but single instance? In process and non-shared queues only? No load balancing across monoliths?
  - imwillofficial 5y ago
    I didn’t read any of that. I read it as more tools in the toolbox.
    - jayd16 5y ago
      Without single instance, an in process queue doesn't provide the same kind of functionality that a shared queue does and would probably introduce split brain kind of problems, no?
      - imwillofficial 5y ago
        Right, you’re taking it as a suggestion, as in a positive nudge to single instance monolithism. However, I read it as merely making GP aware of other options that are on the table.
  - cjfd 5y ago
    Not necessarily. That one can have these tools in-application doesn't mean one cannot combine this with some form of RPC as well. Especially whether one needs load balancing or not seem to be a completely orthogonal issue. On the other hand, why not a monolith and single instance? If one uses a performant language one would be amazed how much can run on a single machine. If one expects growth one should have some plan to scale, sure, but if one does not go for shenanigans like running queues and the like between applications using some form of RCP one might get amazed how much your single monolith can actually do. All this extra networks stuff and so on is not exactly free.
    - jayd16 5y ago
      >On the other hand, why not a monolith and single instance? Single points of failure are bad. I agree its orthogonal, which is why I inquired further about the, imo, odd suggestion.
      - ratww 5y ago
        Running a single instance doesn’t mean not having a backup.
wongarsu 5y ago
Plenty of languages offer modularity, message queues and asynchronous events within a monolith. They are quite idiomatic in go, rust and elixir
- foobarian 5y ago
  Splitting a system into microservices can help individual teams be better stewards of their part of the system. They can release on their own schedule, they can use their own linting rules, heck even a different language, and they can have better control of incoming code changes. With a monolith any random developer can go and flip some private method to public, import it way across the modules, and presto you are now building a ball of mud. Need an out of cycle release? Hopefully you have CI/CD or now you have to beg the SRE in charge to do it for you.
  - Sebb767 5y ago
    > Splitting a system into microservices can help individual teams be better stewards of their part of the system. Team being the keyword here. If you have 3-5 developers per microservice, you're absolutely okay. If you have 3-5 microservices per developer, that's when it gets ugly.
  - yakshaving_jgt 5y ago
    Given your negative characterisation of the "ball of mud", I'm guessing you haven't actually read the original paper. > heck even a different language There's nothing about writing software in different languages that necessitates separating functionality with HTTP calls.
    - foobarian 5y ago
      > There's nothing about writing software in different languages that necessitates separating functionality with HTTP calls I mean it's only computers and the only limit to what we can make them do is our imagination. In this case though for the sake of argument what options would I have if I, say, needed to let a remote team add some functionality to my, say, Spring backend but they really prefer to write C# and have their own CI/CD system. I'm not sure how I would accomplish this in a monolith.

BoorishBears 5y ago

To me microservices should not be an architecture. You can have pieces of functionality in a monolith that make sense to scale independently, and those should not be micro, they should be meaningful pieces of functionality that justify the overhead of spinning them out. In a way your comment reflects this, a lot of the places that justified microservices were at a scale where their "microservice" was serving more requests than the average company's entire codebase. It's "big data" with 10 GBs of logs all over again.

belter 5y ago

The whole problem starts with calling them microservices. Just call it a service oriented architecture please. The whole micro thing is already an indication of the kind of trouble you are getting yourself into. More respect to the monolith please.

cjfd 5y ago
Well, a service-oriented architecture is a more general category then microservices and has been around much longer. In many cases it is much more justifiable on technical grounds. Just to give one example. You have an API that is not the most stable thing in the world and when it misbehaves you do not want it to take the whole application down with it. So you put it in a separate service that can easily be restarted. That is a good technical reason for a separation of executables. Problems arise when people introduce these separations for no good reason. Then one gets all of the problems of RPC and none of the benefits. I.e., one is making things more complicated for no good reason.
- jjoonathan 5y ago
  > and has been around much longer There's your problem. People understood the tradeoffs, so it needed a rebranding before it could go through another hype cycle.
UglyToad 5y ago
I'm going to build a lucrative personal brand / consulting business by hyping mesoservices, neither micro nor macro, just right.
- belter 5y ago
  Reality and Fiction mingle together... "Mesoservices: Architecture for optimal trade-off between engineering and operations efficiency" https://www.codemotion.com/talks/mesoservices-architecture-for-optimal-trade-off-between-engineering-and-operations-efficiency-5774 https://www.codemotion.com/talks/mesoservices-architecture-f...
- 5y ago

afarrell 5y ago

It is worth thinking about them before you need them because by the time you gain the skill and infra needed to support them, you’ll have scaled so large that your ability to coordinate and communicate will be overwhelmed.

papito 5y ago
How many startups out there have run into the problem of "oh no, we got too big too fast"?
- afarrell 5y ago
  A fraction of the ones that are successful. I suppose what I really mean is: If your leadership subordinates (especially new joiners) are starting to struggle to coordinate, consider the possibility that you might already be at that point yet emotionally attached to the notion of staying small as you double or quadruple in population.
  - papito 5y ago
    I can guarantee you that most systems out there could serve production traffic on an old laptop, with well-written code and lean database queries. I have done things in MySQL v3 in 2006 that should not be done with a modern database even today (a taxonomy search engine 3 levels deep. Never again). In the age when database trips and network trips are treated as "free", we somehow arrived at MORE complicated solutions, like microservices. A "hello, world" problem in 99% of the cases is a "hello, world" problem. At Google - it is not. It's a scale problem. Everything is a scale problem at Google first, and a business logic problem second. The FAANG alumni has convinced the new generation of developers that everything is a scale problem.

m0llusk 5y ago

This doesn't match my experience at all. In particular, in the case where a small team is working on a series of small projects it can make a lot of sense to split up the components so that any one of the small projects can be built with one or two existing generalized components along with some custom machinery and some glue code to bring it all together. That way development of all of the small products can contribute to some well honed components that get shared by multiple products and development cycles. It seems like this is not coming up because the most common context of application is one or more teams working on a single large project probably forced to grow as fast as possible because of the funding structure involved. Increasingly, though, there are companies doing software development without the need for focus and scale that is so common to venture capital powered groups.

mason55 5y ago
The major difference is whether the small projects are independent applications that use some shared libraries (what I think you mean by "existing generalized components") or whether the small projects all talk to each other to create a single large application. If it's the former then you're just talking about refactoring functionality into a shared library, but at the end of the day you're still just building little monoliths. You don't have to worry about most of the problems that come up with microservices.

codyb 5y ago

A coworker at a previous four person startup was always advocating microservices. Having to push back on that over and over was frustrating. We didn’t even have a real devops guy, or a vpc with properly partitioned CIDR blocks to segregate our databases from the public web and we’re going to start adding the complexity of a microservice architecture? For what! We didn’t even have _users_ yet. But try to get folk to dogfood our application since we had no actual users besides the founder and it was like pulling teeth. Totally backwards to me.