Hacker News Reader

HNHacker News

Top New Best Ask Show Jobs

Comment by ericb | Hacker News Reader

Parent Full thread

ericb·

If you have a microservice, typically that means a REST API.

-Tests for all response codes

-Test for all failure modes (timeout, service down)

-Load tests both services.

-Two sets of deployments to test.

-Two healthchecks to test.

Seems harder to test, not easier.

View on HN

HTTP is pretty terrible at cancellation, retry, cluster load balancing, in-channel health checks, etc. Some form of RPC is better suited for non-web facing APIs.

And yeah, I agree that it's absolutely harder to test. (Integration test especially.) But you gain a lot for the trouble: independent deployability, scalability, dynamic traffic shifting, easy sevice boundaries and ownership (data stores, state, downstream deps, etc.). For a large company, this makes a lot of sense.

Edit: microservices are not the easy path.

Like with any tool, misapplying is worse than not having it. I think a big problem with microservices is that people that really don't need them think 'neat idea' and start implementing what would be otherwise trivial products using a whole slew of intercommunicating services. They get all the downsides and probably very little if any of the upsides that way. If you don't need it it's best left alone but if you do need it it can help structure a large project in ways that would be otherwise hard to achieve.

This is very true. I've seen it myself recently, and it can produce a nightmare. I've been detecting a tendency lately to over-engineer everything, especially when it comes to devops.

Reply on news.ycombinator.com