Hacker News Reader

Comment by simplotek | Hacker News Reader

> Exactly, microservices make things unnecessarily complex and are often just a poor way for a team to avoid implementing design patterns, namespacing in a codebase.

This is simply not true. Microservices are a solution primarily to an organizational problem and secondarily to the problem of allocating and managing computational resources. The organizational problem is solved by the hard boundaries and loose coupling imposed by operating and consuming independent services. Allowing a team to own and operate their services allows them to have more control over all aspects of a their life cycle, reducing the scope of other stakeholders to what contract their interfaces need to comply with.

Those who naively shit on microservices seem to be totally oblivious to what it would be like if all we had were monoliths. We tried that already. It's awful, and we learned from that mistake. Well, some of us did.

View on HN

> Microservices are a solution primarily to an organizational problem and secondarily to the problem of allocating and managing computational resources.

"A" solution does not mean the only solution or the best solution. They're often treated as the only solution though.

> "A" solution does not mean the only solution or the best solution. They're often treated as the only solution though.

They are often, and by far, the best solution though, specially taking into account the tradeoffs of whatever alternative you come up with.

Specially massive monoliths in a monorepo.

It makes no sense to mindlessly crap on operating services, specially when compared with alternatives. I get that some people feel the need to vent their personal frustrations, but this does not mean they have a point.

What problem are you solving with microservices? Scaling? You can run the same service everywhere but route traffic to specific endpoints to pools of the same thing. These are devops problems and don't necessarily need to be reflected in the code.

Are you trying to solve a problem with code organization? I've heard of folders, they do a pretty good job. Most of the time though, microservices tend to get in the way of delivering VALUE to the company I work for ... because someone thinks 'this is the way.' I was hired to deliver VALUE, not beautiful code, not code that follows this year's 'best practices' that aren't, or even bad code.

I will always write easy, simple, and clear code that delivers VALUE. Microservices usually get in the way of doing that, for basically arbitrary reasons.

> What problem are you solving with microservices?

As I've already said in this thread, microservices solve primarily organizational problems. They define concrete organizational barriers and limit discussions with stakeholders on issues pertaining to service contracts, and ensure that service owners have complete freedom, responsibility, and clear accountability, on all aspects of their design, maintenance, and operation.

Scalability is a welcomed benefit but lower in importance, below reliability and perceived performance.

Any other discussion on microservices boil down to strawmen.

The GP of this discussion talks about 10 devs where each dev is working on more than one microservice. I've seen a lot worse.

If I could pick one thing to talk about when it comes to microservices it would be the name. Micro implies microscope, implies there should be millions to billions of them.

If we could switch to the term two-pizza-services as your comment implies where their main point is in working around Conway's Law, I would feel a lot better about them.

I would agree with you that it could be useful for organizational problems but I would resist this as long as possible. In any case, I prefer to not split engineering teams but for practical reasons (e.g. keeping onboarding times into the team reasonable) you are quite forced to do so.

Once your team loses the rapid feedback of "did this break user-facing functionality yes/no?" your reliability and speed of shipping features deteriorates rapidly as now most engineers will start to fear shipping to production.

Ideally, you break the team into subteams and follow the natural fault-lines in the codebase. Most codebases have areas that do not interact much (or not at all) with each other and they lend themselves well to assigning to a specific subteam.

I'm sure there's a point where this breaks also but I haven't reached it yet.

> They are often, and by far, the best solution though, specially taking into account the tradeoffs of whatever alternative you come up with.

They are not better than modules. The problem is that dynamically typed languages can't support proper modules, so microservices are their only alternative (so far).

> They are not better than modules.

They are. You don't control your runtime environment with modules, nor your deployment. You create problems due to the need to manage releases and deployments. You can break everyone's work if you make a mistake, which worsens the problem. You are unable to pick and choose what technologies you use. Etc etc etc.

With a service, you just tell everyone where it is and what's the interface, and leave it to everyone else to work around that.

> You create problems due to the need to manage releases and deployments. You can break everyone's work if you make a mistake, which worsens the problem.

These problems still exist with microservices, you just don't see the problems at build time but in failures at runtime. You yourself admitted this in your last paragraph:

> With a service, you just tell everyone where it is and what's the interface, and leave it to everyone else to work around that.

So basically you've moved code problems into infrastructure problems, and eliminated standardized build and testing pipelines in favour of a free-for-all/not-my-problem.

And if you think microservices are special in some way, I could also say "with modules you just tell everyone where to download the package, the interface and documentation is bundled with it, and leave everyone else to link to it and use it how they see fit".

The only real difference is that the module is guaranteed to work according to the interface specification you're expecting because this is enforced by the language. Not so with deploying runtime services.

Edit: I also don't understand this at all:

> You don't control your runtime environment with modules, nor your deployment.

Why would you need to control your runtime or deployment with modules? The language already specifies the semantics of modules' runtime behaviour and their linking requirements, and the standard build process is deployment.

What exactly is the problem with a "massive monolith in a monorepo"?

Having it all together is perfect for code re-use and testability.

It's also very easy to know if you broke the bigger picture while working on a subsystem of the monolith because the test-suite will tell you.

In my humble opinion, monoliths are unpopular because not much thought went into the original design of the code and as a consequence there are large chunks of technical debt interfering with everybody's work. It certainly doesn't help that many popular frameworks don't give you the design architecture to grow big apps.

But the good news is that if you don't split your teams, you also have more engineers on hand to refactor the codebase to be more manageable.

Reply on news.ycombinator.com