Comment by d_watt | Hacker News Reader

Comment by d_watt | Hacker News Reader

Parent Full thread

In my experience, most of the time the right decision for the business is investing the time into the core product. If you have 6 months (as stated in the article), what could you do with that time if you could dedicate it to improve the core codebase, rather than a rewrite? Worse case scenario is after 6 months you don't have a perfect codebase, but you've made it better, and you don't have yet another layer to deal with.

Certainly, there are times where that's not reasonable. Maybe the core codebase is on a proprietary technology. Maybe it's built around an EoL framework. Maybe it's built on on a FOTM language that you can't hire for at all anymore.

In those cases, which are more rare than developers like to admit, I think a piecemeal migration makes sense. In my experience, it's better to do it by altering the consumers. Whether it's a frontend that can point to another endpoint, or an API gateway that can switch out the service it's pointed to, or making a shim layer (proxy), that can serve that purpose.

Having a service that is both the proxy and the new application is a poor separation of concerns, very difficult to reason about, and makes it too easy to intermingle the logic between the old and the new. In my experience.

Your guidance is true. However our industry is unfortunately also littered with well intended refactorings that resulted in any more bugs, feature changes, and customer impacts than the original developer intended, or even conceptualized as possible. So it matters a lot.

For example, refactoring "to provide abstraction so future work is easier" is 90% of the time an error.

At some point it starts to sound a bit like 'whatever you do, don't touch a keyboard'. Rewriting everything from scratch? Very risky, please don't. Strangling you old application? Some comments here tell us that we should not. Perhaps they are right. Refactor your current application? 90% of the time it is an error.

Had the pleasure of working at a company like this. Don't rewrite, don't you do refactor, and a proxy? How do you even spell that?

The end result was me losing my "mojo" after a year of producing effectively nothing. I'm back together now but my god it's a terrifying feeling when you've been programming for over ten years and one day you can't make the code flow out of your hands anymore.

> Having a service that is both the proxy and the new application is a poor separation of concerns

I must have missed that in the first read. Yes, do not do this.

If anything survives the hype cycle for microservices, I hope it’s this: if your company isn’t surviving more than a couple of technology cycles, especially when they seem to be getting faster, then what are you doing this for?

Stop trying to replace one system with another one. Yours will be old and busted someday too. And certainly don’t let one system be the gateway to the other. Put them both behind a thin layer that handles only a couple of concerns (say, auth, making sure all requests have a correlation ID, perf statistics, maybe pick 2).

What we are both suggesting, I have still always called the strangler pattern. It just has three actors instead of two.

> What we are both suggesting, I have still always called the strangler pattern. It just has three actors instead of two.

That makes sense, in practice I've seen multiple situations where it was one "monolith" directly in front of another, and rather than a strangler, it was a tumor that ended up with things intertwined. Treating it like a service oriented architecture is a good way to think about it.

You still end up in situations where logic needs to be shared. Do you duplicate Auth? What happens when a new user signs up, do you sync users over? Do they read from the same database(s)? I'll also agree with the over hyped ness of microservices, but I think breaking out services and "rewriting" them to me is the way to achieve the overall goal. Even in the strangler pattern, you'll end up needing to share functionality, and either you have to monolith services calling into each other, or a service oriented architecture.

First big system I worked on, we did authentication at the border, setting a header (which we stripped off of any incoming requests, of course).

Authorization gets duplicated, but that’s going to happen at some point anyway (and how many times does it get duplicated in a microservice architecture?)

I’ve seen the tumor thing too. A few of the most egregious services (memory hungry, least coherent to the whole, etc) get split off to be independent, but lots of things do not. And sometimes the old team sheds people due to it not being the cool thing anymore and then you’re really fucked.

[edit to add] I have developed some very serious resistance to the 'low hanging fruit' model of development. I think it is the direct cause of the Lava Flow Antipattern.

If the point is to completely remove a problem from the system, starting with the most popular one and working toward the more boring ones means that at some point you will lose the argument in a prioritization meeting, the lava will cool and you'll be stuck with both. I would expect a higher likelihood of success if you start at one 'end' of the system and guarantee that high priority examples are evenly distributed throughout the effort.

That’s not the worst case scenario. The worst case scenario is that the rebuilt system is worse and full of a bunch of new weird bugs. There is no guarantee that a rewrite ends up better.

Reply on news.ycombinator.com