Hacker News Reader

Comment by twhitmore | Hacker News Reader

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.

View on HN

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.

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

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.

Wouldn't replacing that with a single point of failure be going a bit too far in the other direction? Perhaps three $5 instances?

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.

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.

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

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.

Sounds like a big brained term for web pages. I’d lean into that.

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.

we are slowly returning to iframes :)

Oh no... you know what, maybe we don't deserve to cross the great firewall as a species.

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.

In such a component-oriented circumstance, what is the motivation for choosing a “microfrontend” approach instead of, say, a component?

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.

2008: Website with jQuery

2022: Server side rendering using island-based architecture for client-side rehydration of interactive components

Please stop.

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.

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-ste...

[1] https://microfrontends.info/microfrontends/

I must run in different circles because I had to Google it. Probably the only thing that made me laugh audibly today.

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.

iframes also work pretty well for this kinda thing :D

I have yet to see such a scenario where either web components or iframes would not have been a better fit.

>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?

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 :)

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.

> 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.

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

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.

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

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.

Reply on news.ycombinator.com