5 ms·

I don't think microservices are silent majority. They seem like more of a blogger architect who likes to tinker with stuff thing. I would expect the true sile

I don't think microservices are silent majority. They seem like more of a blogger architect who likes to tinker with stuff thing. I would expect the true silent majority just uses monoliths. If it works and doesn't make people complain every day when they work on it, why use a microservice? That's more work. Everyone likes to think of microservices as a modern high tech thing, but to me it seems like old fashioned unix stuff, that appeals to people who enjoy doing simple weekend projects, trying to make their job into a series of tiny projects of the type they might do at home for fun. The focus seems more on individual parts than on the vision of the complete project. Of course it seems to just mostly move complexity into the high level gluing it all together, and spread it out in bits of interface code, but if you are more interested in working on simple but interesting challenges, and don't mind the more hands on dev ops maintenance work, and aren't that into building complex systems, I imagine you would like it.

powerhour 4y ago
> but to me it seems like old fashioned unix stuff It's exactly this for me. Unix has been around longer than I've been around and will outlive my career if not my life. Components have been successfully updated and replaced mostly without significant disruption. Unix is a model for producing and maintaining complicated systems.
giancarlostoro 4y ago
I forget the exact quote I read on HN once, but it made me laugh, all concurrent systems will eventually recreate Erlang. If you think of Microservices and even Kubernetes Clusters and company, they're all barely doing a fraction of what Erlang can do, because Erlang had the right concept, it was just 40 years ahead of its time.
- OkayPhysicist 4y ago
  Virding's First Rule of Programming: "Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang."
  - giancarlostoro 4y ago
    That's the one! Thank you! I didn't realize it was from one of the founders of the language, which actually makes a LOT of sense. I wonder what tech he saw back then that made him think of it, I can only come up with more modern examples.
    - OkayPhysicist 4y ago
      He was writing in 2008, so probably some Java thing http://erlang.org/pipermail/erlang-questions/2008-January/032226.html http://erlang.org/pipermail/erlang-questions/2008-January/03...
      - giancarlostoro 4y ago
        I saw the quote attributed to a book they wrote back in the late 90s as well, but I'm not sure how accurate the attribution is... If it is accurate, I'm genuinely curious what project in the 90s was remotely comparable. The answer could be as simple as whatever they were using prior to creating Erlang.
P5fRxh5kUvp2th 4y ago
I feel the same way about OAuth2. It's very complex. It has it's business use cases, but if you don't need it (or don't need full-blown OAuth2) then don't use it. If you're worried about the future separate auth user from account internally in your application (SSO ready) and move on. It sometimes feels like there's a cabal of people who think the more complex something is, the more skilled they are for being able to implement it. That's not really where the skill lies for an engineer.
cestith 4y ago
Microservices vs monoliths with nothing in between is a false dichotomy itself of course. There's been SOA and n-layer applications for decades now. Not every service is a microservice and not everything bigger than a microservice is written as one big application. From the discourse on forums these days, someone fresh to the field might think there's no such thing as an internal API or an ongoing ETL layer without breaking each feature down to its own container and throwing the whole thing on Kubernetes. All those systems that are two to four layers and decomposed into half a dozen or so parts at the outer interface still exist in the world, even if they're not on track to be one container per feature.
EdwardDiego 4y ago
I've joined a company with a silent majority monolith, and joined at the inflection point where they realise their monolith is strangling them... If your dev guide in the wiki says "to run unit tests, use docker-compose exec monolith test some.package.test_class", you're in danger. This company needs to start breaking the monolith down into, well maybe not microservices, but at least smaller monoliths, if they want to achieve what they want to achieve.
- Tainnor 4y ago
  No, you just need a sane test architecture. I've worked on monoliths, and none of them required docker compose for unit tests. Now, you may need some extra infrastructure for integration tests, depending on how you architect them, but that's also not a requirement. You could also use mock services, test containers, ... - essentially there's enough ways to make this sane. It's annoying that people take badly written monoliths as an excuse to proceed to write badly written microservices.
  - EdwardDiego 4y ago
    Let me just say, Django was designed to be a monolith. Also, people who put code that reaches out to external systems in __init__.py are the devil, but the people who decided "sure, let's execute code when we import a module or package, even if we're just importing it to use a class, that sounds reasonable" are the super-devil.
- lytefm 4y ago
  The hard part is to recognize when to start moving towards microservices. As long as the team is small enough and the core product is still undergoing rapid development, I think it's premature to use microservices. Too much overhead without any tangible benefit. But with multiple teams working on different parts of a profit-generating system, it makes sense to the transition - ideally, having a relatively stable core monolith and developing new services around it, occasionally extracting some core functionality as needed.
- snovv_crash 4y ago
trasz 4y ago
>The focus seems more on individual parts than on the vision of the complete project. Quite the opposite - they think about architecture as opposed to a crappy unmaintainable hodgepodge that the vast majority of web applications are. Inferiority of web-based apps doesn’t come from nowhere.
packetlost 4y ago
The silent majority are mostly corporate devs building internal tooling. Microservices are a fantastic method for building distributed, horizontally scaling, dynamic services in a way that's sane. But the overwhelming vast majority of services would be perfectly ok with a simple monolith that occasionally gets a VM spec bump.
- marcosdumay 4y ago
  > horizontally scaling I have never seen services (of any size) succeed in a place that wasn't using them to do vertical partitioning of a system. I imagine you are probably talking about horizontally scaling each of those vertical partitions, but the phrasing is really confusing.
  - packetlost 4y ago
    Yeah, I'm probably just explaining poorly. That's what I was thinking: horizontally scaling subsets of your verticals that need it (they don't usually all need to scale at the same rate)
    - marcosdumay 4y ago
      Oh, it's not you explaining it poorly. That's just the usual idiom, that anybody that already knows the meaning will instantly understand. My criticism is more general, that the usual idiom is confusing and misleading for people that don't know it already. Maybe it shouldn't be usual.

powerhour 4y ago

> but to me it seems like old fashioned unix stuff It's exactly this for me. Unix has been around longer than I've been around and will outlive my career if not my life. Components have been successfully updated and replaced mostly without significant disruption. Unix is a model for producing and maintaining complicated systems.

giancarlostoro 4y ago

I forget the exact quote I read on HN once, but it made me laugh, all concurrent systems will eventually recreate Erlang. If you think of Microservices and even Kubernetes Clusters and company, they're all barely doing a fraction of what Erlang can do, because Erlang had the right concept, it was just 40 years ahead of its time.

OkayPhysicist 4y ago
Virding's First Rule of Programming: "Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang."
- giancarlostoro 4y ago
  That's the one! Thank you! I didn't realize it was from one of the founders of the language, which actually makes a LOT of sense. I wonder what tech he saw back then that made him think of it, I can only come up with more modern examples.
  - OkayPhysicist 4y ago
    He was writing in 2008, so probably some Java thing http://erlang.org/pipermail/erlang-questions/2008-January/032226.html http://erlang.org/pipermail/erlang-questions/2008-January/03...
    - giancarlostoro 4y ago
      I saw the quote attributed to a book they wrote back in the late 90s as well, but I'm not sure how accurate the attribution is... If it is accurate, I'm genuinely curious what project in the 90s was remotely comparable. The answer could be as simple as whatever they were using prior to creating Erlang.

P5fRxh5kUvp2th 4y ago

I feel the same way about OAuth2. It's very complex. It has it's business use cases, but if you don't need it (or don't need full-blown OAuth2) then don't use it. If you're worried about the future separate auth user from account internally in your application (SSO ready) and move on. It sometimes feels like there's a cabal of people who think the more complex something is, the more skilled they are for being able to implement it. That's not really where the skill lies for an engineer.

cestith 4y ago

Microservices vs monoliths with nothing in between is a false dichotomy itself of course. There's been SOA and n-layer applications for decades now. Not every service is a microservice and not everything bigger than a microservice is written as one big application. From the discourse on forums these days, someone fresh to the field might think there's no such thing as an internal API or an ongoing ETL layer without breaking each feature down to its own container and throwing the whole thing on Kubernetes. All those systems that are two to four layers and decomposed into half a dozen or so parts at the outer interface still exist in the world, even if they're not on track to be one container per feature.

EdwardDiego 4y ago

I've joined a company with a silent majority monolith, and joined at the inflection point where they realise their monolith is strangling them... If your dev guide in the wiki says "to run unit tests, use docker-compose exec monolith test some.package.test_class", you're in danger. This company needs to start breaking the monolith down into, well maybe not microservices, but at least smaller monoliths, if they want to achieve what they want to achieve.

Tainnor 4y ago
No, you just need a sane test architecture. I've worked on monoliths, and none of them required docker compose for unit tests. Now, you may need some extra infrastructure for integration tests, depending on how you architect them, but that's also not a requirement. You could also use mock services, test containers, ... - essentially there's enough ways to make this sane. It's annoying that people take badly written monoliths as an excuse to proceed to write badly written microservices.
- EdwardDiego 4y ago
  Let me just say, Django was designed to be a monolith. Also, people who put code that reaches out to external systems in __init__.py are the devil, but the people who decided "sure, let's execute code when we import a module or package, even if we're just importing it to use a class, that sounds reasonable" are the super-devil.
lytefm 4y ago
The hard part is to recognize when to start moving towards microservices. As long as the team is small enough and the core product is still undergoing rapid development, I think it's premature to use microservices. Too much overhead without any tangible benefit. But with multiple teams working on different parts of a profit-generating system, it makes sense to the transition - ideally, having a relatively stable core monolith and developing new services around it, occasionally extracting some core functionality as needed.
snovv_crash 4y ago

trasz 4y ago

>The focus seems more on individual parts than on the vision of the complete project. Quite the opposite - they think about architecture as opposed to a crappy unmaintainable hodgepodge that the vast majority of web applications are. Inferiority of web-based apps doesn’t come from nowhere.

packetlost 4y ago

The silent majority are mostly corporate devs building internal tooling. Microservices are a fantastic method for building distributed, horizontally scaling, dynamic services in a way that's sane. But the overwhelming vast majority of services would be perfectly ok with a simple monolith that occasionally gets a VM spec bump.

marcosdumay 4y ago
> horizontally scaling I have never seen services (of any size) succeed in a place that wasn't using them to do vertical partitioning of a system. I imagine you are probably talking about horizontally scaling each of those vertical partitions, but the phrasing is really confusing.
- packetlost 4y ago
  Yeah, I'm probably just explaining poorly. That's what I was thinking: horizontally scaling subsets of your verticals that need it (they don't usually all need to scale at the same rate)
  - marcosdumay 4y ago
    Oh, it's not you explaining it poorly. That's just the usual idiom, that anybody that already knows the meaning will instantly understand. My criticism is more general, that the usual idiom is confusing and misleading for people that don't know it already. Maybe it shouldn't be usual.