Hacker News Reader

Comment by lijok | Hacker News Reader

> If you think that microservices solve the "spaghetti code problem", well, good luck to you, you'll need it.

That is a very good point. In fact, good monolithic code layout is a precursor for microservices, as only once you have identified your boundaries and isolated your concerns can you begin splitting them out into their own services.

I will say this however - microservices might not solve the "spaghetti code problem", but it definitely helps isolate it. When we get consultants in to speedboat a new system, we give them their own separate service. Saves a lot of time and de-risks our beautiful monolith.

View on HN

That is a very strategic and appropriate use of this pattern, and it's not even "microservices" - it's just goddamned "services"!

It also seems like an intentional wielding of Conway's Law.

Compartmentalization.

Have your teams use façade pattern and you no longer need microservices to "isolate it"

Facade doesn't help with poor tests, scripts, new dependencies, cicd workflows, repo settings, etc

Yep and people you do not trust should not have access to CI/CD workflows and repo settings. Your CI/CD workflows should prevent everything else you mentioned.

Micro services don’t solve any of those either.

What specifically do they not solve? Because in this thread we're, very specifically, discussing isolating the well maintained monolith from risky product produced by consultants, which microservices absolutely do solve.

I think the hot trend these days is to bash on microservices. I hear that a lot here, random blogs, youtube videos by self proclaimed top guns.

If hacker news is correct, microservices is the #1 worst idea of software engineering.

And whoever promotes them is either a kid with no experience or a complete moron.

Well, speaking for myself, I was against them from the start. Maybe the rejection of distributed objects (when it came) was a hot trend also but it didn't make it wrong.

Any of the problems above.

If you have a problem with bad consultants then solve that. Trying to solve it by jumping into microservices you will just have bad consultants writing your microservices equally badly, or even worse.

If it's that bad, you might be better off paying extra to avoid shitty outsourcing companies.

But you're probably not the person I should telling this, developers aren't usually in charge of that.

You wont know how bad the product produced by consultants will be until it already had effect.

And on pricing specifically, both shitty and good consultancies charge about the same. The ones that charge well below market are an outlier that will guarantee bad product - those are to be avoided.

Who mentioned outsourcing?

> Who mentioned outsourcing?

lijok wrote:

When we get consultants in to speedboat a new system, we give them their own separate service. Saves a lot of time and de-risks our beautiful monolith.

Can your "facade" "isolate" interns making change in your service as well so that the whole service which powers the system doesn't go down. Microservices can.

Elixir can. I’m not in any hurry to use it, but I suspect there’s a lot we still have to learn from its design.

I don’t understand how micro services prevent a system from “going down”. I pushed an infinite loop to the auth service, oops. Now nothing works. How did micro services prevent this?

You let interns push to production without code review?

Totally missed the point. Even with Code reviews, Unit/Integration Testing, Automated CI/CD and more can a person broke the prod.

One intern was told to deploy the app and I guess he made a mistake and updated k8 configs which deleted all the pods. Tell me how code reviews are supposed to catch it.

If you think "why not restrict config actions" etc, it's because the dev can go there and tweak those actions too. And each step added means less velocity of development. It's a game of cat and mouse. With isolation, you can limit the blast radius and loss of revenue.

> One intern was told to deploy the app and I guess he made a mistake and updated k8 configs which deleted all the pods. Tell me how code reviews are supposed to catch it.

So you don’t have a staging environment to check config changes before deploying to prod? Or you don't put k8s manifests (or helm charts or whatever)in source control and just update prod through CLI? And you let interns do it alone?

Your problem isn't interns, it's a terrible deployment processs with weak controls. Even senior engineers are going to break prod regularly in conditions like that.

> Automated CI/CD

[...]

> One intern was told to deploy the app and I guess he made a mistake and updated k8 configs which deleted all the pods. Tell me how code reviews are supposed to catch it.

These sound contradictory to me. Part of having automated CI/CD, is not having to manually deal with k8s to do a regular deploy.

If that happens it's an organizational problem (lack of mentoring, code reviews, access control), not an architectural problem...

Sure with proper CI/CD in place which you need regardless of app being a monolith or a set of micorservices. It's also infinitely simpler to setup proper CI/CD for a monolith.

Reply on news.ycombinator.com