5 ms·

Microservices grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too That made me laugh. The microservices

Microservices grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too That made me laugh. The microservices madness of the past decade is now starting to settle down to more mature understandings, but there are still a lot people biting off large testing, operational, and data transactionality/ reporting costs. People often don't recognise beforehand the magnitude of extra complexity & associated productivity costs. I've seen companies architecting 50 microservices with 50 separate datastores when they actually needed 5 midi services.. Then lose half their productivity trying to work with all this.

strix_varius 4y ago
I don't know if this is universal, but in my circles "microfrontends" are now all the rage. How do you bring up concerns with that in good faith? It's so obviously terrible that I've no idea where to begin.
- ryanmcbride 4y ago
  GOD I hate microfrontends. Had a client that had a single, relatively simple application that they wanted as 3 separate angular apps. The reasoning was that they wanted to be able to autoscale them separately? Was unable to convince them that the gains from that would be negligible, especially for an internal tool, and that scaling the whole frontend instead of a single part of it would have virtually no downside since each app was basically a single form, but tons of upsides like less code complexity, easier data persistence, and fewer versioning issues, faster build time. But they didn't care. To this day I don't know what manager was sold so firmly on building 3 apps when one would do, but not my problem anymore.
  - 3np 4y ago
    Could you have done "the monorepo approach" and just have the same code deployed in 3 instances with different `APP_MODE` configuration value or something like that? :P
    - ryanmcbride 4y ago
      Possibly but that client is actually what made me quit the firm so I don't even know where that project ended up (probably in the trash). I quit not just because of their weird code requirements but also because I had a 5am standup every day because their engineering team was in the IST timezone, and also had to drive to Palo Alto (about 2 hours in the morning) every day because even though the rest of their team was in Bangalore, they had a requirement that all external contractors only work on prem. The firm I worked for couldn't or wouldn't reassign me and I just so happened to get an email from a company I really wanted to work for. So I reassigned myself.
- pixelrevision 4y ago
  Sounds like a big brained term for web pages. I’d lean into that.
- codethief 4y ago
  Oh lawd, at our client people recently pushed that idea, too. Unfortunately, managers were all on board ("Every team will be able to release autonomously and much faster!!!11") and it became politically impossible to argue for alternatives that won't result in dependency and infrastructure hell. So here we are now, splitting off every single page of a god damn legacy web shop into a separate micro frontend, each of which will be running on a completely different stack (some SPA, some traditional SSR with jQuery), living in a separate repository and with a separate microservice in the backend. But how does one share common UI components, you ask? Well, obviously by enabling Server-Side Includes on the ingress server. Duh.
  - wildrhythms 4y ago
    we are slowly returning to iframes :)
  - uwuemu 4y ago
    Oh no... you know what, maybe we don't deserve to cross the great firewall as a species.
- strikelaserclaw 4y ago
  microfront ends work well for self contained components that need to be used in multiple pages, they don't even need to have a "separate" backend, as long as there is an area or code file for the backend code that deals with whatever data the microfront end needs.
  - strix_varius 4y ago
    In such a component-oriented circumstance, what is the motivation for choosing a “microfrontend” approach instead of, say, a component?
    - weq 4y ago
      The longer you are a developer, the more you see fads a cylic just like anything else in this world. rebranding happens every 5 to 10 years for most things.
      - nevercomments 4y ago
        2008: Website with jQuery 2022: Server side rendering using island-based architecture for client-side rehydration of interactive components
  - morelisp 4y ago
    Please stop.
  - collyw 4y ago
    What kind of component are you talking about? Could you give an example, because as a backend dev, I have no idea what sort of thing would require that level of separation.
- 3np 4y ago
  First time I encounter the term, immediate reaction "hmm, maybe we're already kind of doing this?", thinking about mapping a dozen or so services to different HTTP endpoints/prefixes under the same root. Then I did a search. Oh lord. One of the top results[0] is an illustrative guide on how to split out a Button component into an independent deployment... I can only hope that applying this on a Button is not supposed to be taken literally but I can also only assume that thousands of professional have now made it their calling to split out every component into its own "microfrontend"... EDIT: Nope, looks idiomatic. [1] [0] https://levelup.gitconnected.com/micro-frontends-step-by-step-using-react-webpack-5-and-module-federation-e4b9d840ec71 https://levelup.gitconnected.com/micro-frontends-step-by-ste... [1] https://microfrontends.info/microfrontends/ https://microfrontends.info/microfrontends/
- dc-programmer 4y ago
  I must run in different circles because I had to Google it. Probably the only thing that made me laugh audibly today.
- deleted 4y ago
  [deleted]
- ngc248 4y ago
  MicroFrontEnds (MFE) solve an actual problem, but it becomes a problem if developers do it for the sake of RDD (Resume Driven Development) or just because. My Company has a Cloud platform which is kinda like a marketplace and users can install and uninstall apps/services. In our case MFEs are a perfect fit.
  - Torn 4y ago
    iframes also work pretty well for this kinda thing :D
  - strix_varius 4y ago
    I have yet to see such a scenario where either web components or iframes would not have been a better fit.
greatpostman 4y ago
I actually disagree. I think people disparaging micro services are working at companies or on problems that are too small for that solution
- hrayn3 4y ago
  Agreed. My company has a (relatively) mature MFE platform, and it rocks. The MFE team handles builds, deployment, and can build features like experimentation into the platform, so the teams can focus on the MFEs. The MFEs are not arbitrarily small - they are related to specific experiences. A single MFE might be a collection of pages in a flow, for example. It means less work for devs, more consistency across a big company, and much safer deployments - the worst thing that can happen if you ship a bug is to tank your MFE because they're all isolated. At a big company, being able to change something small on your MFE and push to prod without worrying about every other page in the site is awesome.
- collyw 4y ago
  I disparage them, because most companies including my own don't need them. My team are keen, but I can only see it adding complexity. If your company genuinely operates at that scale go for it. But remember that Stack overflow runs on a pretty classical architecture. https://stackexchange.com/performance https://stackexchange.com/performance
geekbird 4y ago
This. Premature and excessive fragmenting into unmaintainable and operationally microse5rvices is the bane of my existence. It's often done by zealots, who see microservice architecture as a matter of religious faith, not operability convenience. Sure, some monoliths are harder to debug if there are multiple distinct packages that need to operate together if they are all in the same container. But fragmenting a simple set of services into a dozen microservices each in their own disconnected container is excessive too. If any of those fragments depend too closely on other fragments to operate (like, say, a timer service and a session renewal service that depends on the timer) it will easily fall over and be nearly impossible to tell why. If you are going to shard up your application into microservices, be sure to split out your functions conservatively, so that like goes with like. It's easier to split stuff out more later than to try to split every little jot and tittle into its own dinky container. That way you don't end up with little containers of nothing wasting processor and I/O just for the sake of dogma.
- wildrhythms 4y ago
  i can't tell you how many teams I've seen spend months and months engineering some vast microservice system only to end up serving maybe 500 DAU. It could have been a single executable on a $5 VPS
  - nevercomments 4y ago
    Up above there’s a great thread about the perverse incentives in project management roles. This is a great example of perverse incentives in development roles - resume driven development practices.
  - sethd 4y ago
    Wouldn't replacing that with a single point of failure be going a bit too far in the other direction? Perhaps three $5 instances?
BlargMcLarg 4y ago
>The microservices madness of the past decade is now starting to settle down Meanwhile, I feel it has just started outside SV. Is the remainder of the world just perpetually 5-10 years behind?
- porker 4y ago
  Yes. It's why keeping up with the latest on HN isn't essential for most of us - we've got 5 years to see if it's worth adopting :)
- rovek 4y ago
  Depends what you mean by "the remainder of the world". Most mid-tier companies I've worked at or know people who work at in London started moving on from microservices some time ago. So I guess, unsurprisingly, no.
  - Nextgrid 4y ago
    > Most mid-tier companies I've worked at or know people who work at in London started moving on from microservices some time ago Are we talking about the same London? The market is still flooded with engineering playgrounds and microservices are still considered a perk and bragging point by many companies. Finding a company with a sane tech stack that doesn't do complexity for the sake of complexity is impossible. It makes sense though - those companies already have their developers, they are happy and the company doesn't need to hire more.
Tabular-Iceberg 4y ago
Also my biggest worry when a client wants to transition to microservices what the state of their current monolith is. An out-of-control monolith doesn't inspire confidence that they will be much better at building a distributed system.

strix_varius 4y ago

I don't know if this is universal, but in my circles "microfrontends" are now all the rage. How do you bring up concerns with that in good faith? It's so obviously terrible that I've no idea where to begin.

ryanmcbride 4y ago
GOD I hate microfrontends. Had a client that had a single, relatively simple application that they wanted as 3 separate angular apps. The reasoning was that they wanted to be able to autoscale them separately? Was unable to convince them that the gains from that would be negligible, especially for an internal tool, and that scaling the whole frontend instead of a single part of it would have virtually no downside since each app was basically a single form, but tons of upsides like less code complexity, easier data persistence, and fewer versioning issues, faster build time. But they didn't care. To this day I don't know what manager was sold so firmly on building 3 apps when one would do, but not my problem anymore.
- 3np 4y ago
  Could you have done "the monorepo approach" and just have the same code deployed in 3 instances with different `APP_MODE` configuration value or something like that? :P
  - ryanmcbride 4y ago
    Possibly but that client is actually what made me quit the firm so I don't even know where that project ended up (probably in the trash). I quit not just because of their weird code requirements but also because I had a 5am standup every day because their engineering team was in the IST timezone, and also had to drive to Palo Alto (about 2 hours in the morning) every day because even though the rest of their team was in Bangalore, they had a requirement that all external contractors only work on prem. The firm I worked for couldn't or wouldn't reassign me and I just so happened to get an email from a company I really wanted to work for. So I reassigned myself.
pixelrevision 4y ago
Sounds like a big brained term for web pages. I’d lean into that.
codethief 4y ago
Oh lawd, at our client people recently pushed that idea, too. Unfortunately, managers were all on board ("Every team will be able to release autonomously and much faster!!!11") and it became politically impossible to argue for alternatives that won't result in dependency and infrastructure hell. So here we are now, splitting off every single page of a god damn legacy web shop into a separate micro frontend, each of which will be running on a completely different stack (some SPA, some traditional SSR with jQuery), living in a separate repository and with a separate microservice in the backend. But how does one share common UI components, you ask? Well, obviously by enabling Server-Side Includes on the ingress server. Duh.
- wildrhythms 4y ago
  we are slowly returning to iframes :)
- uwuemu 4y ago
  Oh no... you know what, maybe we don't deserve to cross the great firewall as a species.
strikelaserclaw 4y ago
microfront ends work well for self contained components that need to be used in multiple pages, they don't even need to have a "separate" backend, as long as there is an area or code file for the backend code that deals with whatever data the microfront end needs.
- strix_varius 4y ago
  In such a component-oriented circumstance, what is the motivation for choosing a “microfrontend” approach instead of, say, a component?
  - weq 4y ago
    The longer you are a developer, the more you see fads a cylic just like anything else in this world. rebranding happens every 5 to 10 years for most things.
    - nevercomments 4y ago
      2008: Website with jQuery 2022: Server side rendering using island-based architecture for client-side rehydration of interactive components
- morelisp 4y ago
  Please stop.
- collyw 4y ago
  What kind of component are you talking about? Could you give an example, because as a backend dev, I have no idea what sort of thing would require that level of separation.
3np 4y ago
First time I encounter the term, immediate reaction "hmm, maybe we're already kind of doing this?", thinking about mapping a dozen or so services to different HTTP endpoints/prefixes under the same root. Then I did a search. Oh lord. One of the top results[0] is an illustrative guide on how to split out a Button component into an independent deployment... I can only hope that applying this on a Button is not supposed to be taken literally but I can also only assume that thousands of professional have now made it their calling to split out every component into its own "microfrontend"... EDIT: Nope, looks idiomatic. [1] [0] https://levelup.gitconnected.com/micro-frontends-step-by-step-using-react-webpack-5-and-module-federation-e4b9d840ec71 https://levelup.gitconnected.com/micro-frontends-step-by-ste... [1] https://microfrontends.info/microfrontends/ https://microfrontends.info/microfrontends/
dc-programmer 4y ago
I must run in different circles because I had to Google it. Probably the only thing that made me laugh audibly today.
deleted 4y ago
[deleted]
ngc248 4y ago
MicroFrontEnds (MFE) solve an actual problem, but it becomes a problem if developers do it for the sake of RDD (Resume Driven Development) or just because. My Company has a Cloud platform which is kinda like a marketplace and users can install and uninstall apps/services. In our case MFEs are a perfect fit.
- Torn 4y ago
  iframes also work pretty well for this kinda thing :D
- strix_varius 4y ago
  I have yet to see such a scenario where either web components or iframes would not have been a better fit.

greatpostman 4y ago

I actually disagree. I think people disparaging micro services are working at companies or on problems that are too small for that solution

hrayn3 4y ago
Agreed. My company has a (relatively) mature MFE platform, and it rocks. The MFE team handles builds, deployment, and can build features like experimentation into the platform, so the teams can focus on the MFEs. The MFEs are not arbitrarily small - they are related to specific experiences. A single MFE might be a collection of pages in a flow, for example. It means less work for devs, more consistency across a big company, and much safer deployments - the worst thing that can happen if you ship a bug is to tank your MFE because they're all isolated. At a big company, being able to change something small on your MFE and push to prod without worrying about every other page in the site is awesome.
collyw 4y ago
I disparage them, because most companies including my own don't need them. My team are keen, but I can only see it adding complexity. If your company genuinely operates at that scale go for it. But remember that Stack overflow runs on a pretty classical architecture. https://stackexchange.com/performance https://stackexchange.com/performance

geekbird 4y ago

This. Premature and excessive fragmenting into unmaintainable and operationally microse5rvices is the bane of my existence. It's often done by zealots, who see microservice architecture as a matter of religious faith, not operability convenience. Sure, some monoliths are harder to debug if there are multiple distinct packages that need to operate together if they are all in the same container. But fragmenting a simple set of services into a dozen microservices each in their own disconnected container is excessive too. If any of those fragments depend too closely on other fragments to operate (like, say, a timer service and a session renewal service that depends on the timer) it will easily fall over and be nearly impossible to tell why. If you are going to shard up your application into microservices, be sure to split out your functions conservatively, so that like goes with like. It's easier to split stuff out more later than to try to split every little jot and tittle into its own dinky container. That way you don't end up with little containers of nothing wasting processor and I/O just for the sake of dogma.

wildrhythms 4y ago
i can't tell you how many teams I've seen spend months and months engineering some vast microservice system only to end up serving maybe 500 DAU. It could have been a single executable on a $5 VPS
- nevercomments 4y ago
  Up above there’s a great thread about the perverse incentives in project management roles. This is a great example of perverse incentives in development roles - resume driven development practices.
- sethd 4y ago
  Wouldn't replacing that with a single point of failure be going a bit too far in the other direction? Perhaps three $5 instances?

BlargMcLarg 4y ago

>The microservices madness of the past decade is now starting to settle down Meanwhile, I feel it has just started outside SV. Is the remainder of the world just perpetually 5-10 years behind?

porker 4y ago
Yes. It's why keeping up with the latest on HN isn't essential for most of us - we've got 5 years to see if it's worth adopting :)
rovek 4y ago
Depends what you mean by "the remainder of the world". Most mid-tier companies I've worked at or know people who work at in London started moving on from microservices some time ago. So I guess, unsurprisingly, no.
- Nextgrid 4y ago
  > Most mid-tier companies I've worked at or know people who work at in London started moving on from microservices some time ago Are we talking about the same London? The market is still flooded with engineering playgrounds and microservices are still considered a perk and bragging point by many companies. Finding a company with a sane tech stack that doesn't do complexity for the sake of complexity is impossible. It makes sense though - those companies already have their developers, they are happy and the company doesn't need to hire more.

Tabular-Iceberg 4y ago

Also my biggest worry when a client wants to transition to microservices what the state of their current monolith is. An out-of-control monolith doesn't inspire confidence that they will be much better at building a distributed system.