Hacker News Reader

Comment by linkdd | Hacker News Reader

Microservices brings a lot of complexity. Yeah you're not analyzing a stack trace, instead you put correlation IDs in your requests and you analyze a network call stack.

And you'll need a centralized logging mechanism to not have to log to hundreds of servers (or pods if running on kubernetes) to get that sweet failing request with its correlation ID.

It's far more easier to do Service Oriented Architecture when you don't need the performance/flexibility/scaling of microservices. I would not recommend any startup to go through the microservice route until they have the resources *and the need* to do so.

View on HN

Ex-Amazon SDE here: SOA is good, team boundaries are good, tiny microservices are bad, distibuted monolith is really bad.

> performance/flexibility/scaling of microservices

Tiny microservices tend to perform and scale poorly due to their granularity.

>Ex-Amazon SDE here: SOA is good, tiny microservices are not.

Fully agree. Unless the strict granularity is needed, which it's usually not, services should align to the tasks that the upstream "user" needs to accomplish. If every task requires calling the same 4 microservices in sequence, you've done it wrong. At the very least, the granularity should exist only where it's needed.

Disagree with distributed monolith. It's a big team/small team thing.

We converted a big monolith batch processing application to streaming + Kafka using what might be described as a distributed monolith and it worked great.

Using a single framework abstraction (in this case Spring) helps eliminate a huge amount of incidental complexity. We don't want teams inventing their own ways to manage things like retries, topic creation / administration, dlq, partitioning,...

If I wasn't using Spring/Java, I'd be using Elixir for similar reasons. Frameworks are good for async/distributed programming.

If you work in big tech and have enormous amounts of resources to throw at it, sure, go with totally independent microservices. But, distributed monolith can be very productive and provide a significantly easier mental model.

Erlang/Elixir is a bad example because much of the microservice best practices come from (IMHO) the actor model implemented with OTP.

Put your microservices in a mono-repo, replace "microservice" by "erlang process", replace "orchestration" with "OTP supervisors", and that's it. Conceptually it's almost the same.

> We don't want teams inventing their own ways to manage things like retries, topic creation / administration, dlq, partitioning,...

Then enjoy all the pains of a planned economy-errr architecture

This article explicitly goes down the "micro" in microservices route, which does have the problems you identify. There's an alternative school of thought that regrets, or at least downplays the obsession with "micro". Much of the drive to microservices was a reaction against things like the Enterprise Service Bus in the SOA world becoming the big ball of mud no-one can easily change - SOA and microservices don't have to look a world apart.

I'm a big fan of Mark Richards and Neal Ford's emphasis of architecture being about trade-offs. No one thing is a silver bullet.

What I call a Service Oriented Architecture is much like the Microservice architecture but without worrying about the "micro" aspect.

Typical architecture in our projects:

- User Management Service with ORY[1] - Payment Service with Stripe[2] - Hasura[3] for the storage layer - GraphQL backend querying the above services - Frontend querying the GraphQL backend

Basically, we tend to delegate the boilerplate to third-parties (self-hosted whenever it's possible) and only implement the business logic ourselves.

[1] - https://ory.sh

[2] - https://stripe.com

[3] - https://hasura.io

Microservices: Instead of debugging a function, debug why it didn't even get called. What a waste of time.

Microservices done right help isolate issues though. If you have an ecosystem of 100 microservices, but blue-widget-microservice is throwing errors you know which codebase you need to look at. Of course it might turn out that the errors are coming from bad inbound REST calls, but regardless it helps to narrow things down.

I don't think that microservices work well with a pure server kind of architecture. For one you miss out on a fundamental microservice advantages, scalability and portability.

> If you have an ecosystem of 100 microservices, but blue-widget-microservice is throwing errors you know which codebase you need to look at.

If you have a system with 100 well-defined modules, but blue-widget-model is throwing errors, you know which codebase you need to look at.

No modularization technique has a monopoly on this characteristic.

It's a lot easier to violate that when it's just an import and a call away. I will concede that if the system is well designed and developers follow the patterns set it doesn't matter if it's a microservice based architecture or not.

I suppose it depends on your language.

For example, if you're working in Java 8 where everything's just one big jumbled globally visible classpath, sure. If, on the other hand, you're working in Java 9 or later, you have the ability to control your public interface. People can get around that with reflection, so it's technically more permeable than a service boundary, but, if you're letting shenanigans like that sail past code review, you get what you deserve.

Perhaps the dev culture I am in is skewing my perspective. There have been developers that have changed private methods to public just so that they can access them. You make a good point, it's a code review problem and by extension Architecture teams not communicating effectively with Dev Leads.

I agree, and packages and package private access is such a powerful tool in Java, that so many developers completely ignore.

Largely because it's not that powerful. It's got several shortcomings, but the main one is that Java doesn't actually understand Java package organization conventions. To Java, "com.mycompany.stuff" and "com.mycompany.stuff.specialized" are two completely unrelated packages, and so stuff that's package-private to "com.mycompany.stuff" is inaccessible from "com.mycompany.stuff.specialized".

That and a few other details make the feature annoying enough to use in practice that most people just find it's better to just stop using it.

Fortunately, if you're on Java 9 or later, there are modules, which are a much better fit for what kinds of access control tooling programmers actually need.

True. Microservice people would reply that microservice enforce modularization (as remote address spaces do not allow for dirty shortcuts). However that argument seems to me like drilling out a spark plug to help yourself with speed limits.

People in the monolith space call that "different JARs"

Does it though? If you're triaging an issue, in a microservice environment, errors become limitless red herrings. Reproducibility becomes an enormous undertaking, especially when you can't (quickly) recreate the entire stack ("won't fit on my laptop").

A monolith can be quite scalable and portable.

Not only can a monolithic code base be scaleable but you can make it into microservices by adjusting it's startup parameters:

    monolith --start-batch-jobs
    monolith --start-claim-processor
    monolith --start-graphql

And they would be interconnected probably via some clustering protocol with libraries that hide the complexity and runs a bus available in a litany of languages.

Need scale?

k8s replica count on the above pods.

Hmm, wouldn't it make more sense to keep batch jobs outside the monolith? Everything else makes sense to stay in a single binary.

The point of it is to be able to run it simply for developers developering things. If I run in prod with 12 different splits of code, that's fine. If I want to run this locally to develop new features, I would love to put in a breakpoint to see my puppeteer job run to do some screen scraping without having to have 15 VSCode windows open. (Which is what I sometimes have to do at my current company because we're a team of 6 doing microservices with 12 apps (more planned yay).

My experience is that monoliths tend to decay over time unless some serious discipline is enforced. It's possible to reference across boundaries, so that happens sooner or later.

By going down a microservice route, those boundaries are ruthlessly enforce because it's the only way. That trade off may or may not be worth it.

Not doing microservice does not mean doing monolith.

There is an in-between that you can aim for.

But you don't have to recreate the entire stack, that's the whole point.

Reply on news.ycombinator.com