So you want to learn Microservices? | Hacker News Reader

So you want to learn Microservices?

dev.to

90 pointscharlysl29 comments

One of the points listed as the promises of microservices is: "Easy to test"

A microservice might be easy to test in isolation, but testing a microservices based system is FAR more difficult than testing a monolith - personally, I find that to be the worst part of microservices architecture. I would put "easy to test" as probably the main advantage of monoliths.

Have you tried using client driven contract testing? Like pact.

Testing becomes way faster too because you don’t need to spin up the full distributed system (parts of which you probably wont own anyway) and it can all be done in parallel.

I never tried that, but my understanding is that those tests wouldn't check if the distributed business logic works. To do that, you would need to set up the state for the various services, and I don't see any easy way to do that. Am I missing anything?

Question: isn't that integration testing, and wouldn't you have to do as much of that on a monolith as you would on a microservice? I mean you still need a staging environment somewhere? Oh, or am I misunderstanding - were microservices sold on the idea that you could do away with a single staging environment, and publish all the bits and pieces asynchronously?

With many "monolithic" frameworks - eg Ruby on rails - you can do end to end automated testing without having to create a staging environment.

https://www.codewithjason.com/rails-integration-tests-rspec-...

Totally agree. In a monolith, you get these wonderful things called stack traces any time your program errors out.

With microservices, you need to log EVERYTHING. then you need to consolidate the logs using an extra microservice. Then you sort of get a half-baked stack trace.

You're looking for https://opentracing.io/

We don't just use it for traces across services but also as a means of profiling in production. Going from "latency is too high" to "this exact database query is taking too long" in a few clicks is amazing. I wouldn't want to work on a new project without it.

Also check out https://opentelemetry.io/

Not to mention the challenge of using a debugger. I can drop a trace in a monolith and hop around in control flow to explore stuff more easily than in a service cluster with each service potentially written in a different language.

Microservices architecture is the modern equivalent of "works on my machine". It's making every other job more difficult for a small productivity boost for the individual developer.

This only makes sense if that's your bottleneck. It usually isn't. Most orgs I come across have deployment issues that they make worse by creating so much more things that need deployments done in sync.

I also want to see how a major refactor of a micro services architecture looks especially if services uses different stacks. It seems a little naive to think that you can design perfect interfaces that will stay stable forever. More likely at some point in the future there will be a major change that requires changes to a lot of services and their clients. This seems a nightmare to coordinate.

I think the other listed advantages of microservices also aren't entirely serious. "Easier deployment than monoliths" are you sure? "Polyglot persistence" why is that a good thing? "Scalable" no idea what it means. "High performance" now you're just messing with me.

In my experience, you can have a huge binary doing tons of things that's nevertheless quick to build and run. And it will be easier to step through, which is super important.

> "Scalable" no idea what it means.

Generally refers to the idea that a microservice should be designed to scale horizontally (with more instances) vs. vertically (more compute power). If you can scale horizontally you're more likely to be able to meet changes demand at a lower price.

You should actually try microservices in a larger team before dismissing all these. Having large feature sets behind a load balancer and having the rest of the app fail gracefully when a feature goes down, means you can have worry free deployments. You can deploy a single feature, you can do a tiered role out on a feature, without impacting any other service. You can also easily deploy more instances of a service. As long as you've done the work to make your internal requests stateless then you should be able to maintain high perf by scaling instances.

Beyond Polygot, I would instead phrase it as new features can roll out without dealing a large legacy tier of code. Most of your code can be Java with a single high performance service written in C++, lets say. If you're compressing video in an async manner, do you really want to throw that in your RESTful Spring service?

you can check that one for more context :)

https://www.slideshare.net/aahoogendoorn/designing-and-build... , slide 26 ;)

https://garden.io/ could help with those tests too.

Agreed.

I've had tech managers who haven't touched an IDE in years read the whitepapers and hype, and tell me that things like Docker will solve all this. And in theory, it should work. Each service maintainer is required to maintain their Docker Compose file in the source so we can figure out how to create the necessary configuration with all needed services for our own needs.

In reality, once a service becomes 'stable' nobody touches the code for months or even years. And then one day I try to setup my composition and it's dependency hell where each service and its dozen transitive services are all referencing different releases and even snapshot builds.

Sometimes I look back fondly on the days of these huge 'enterprise' Java apps that included everything along with another huge Oracle or SQL Server VM. Once you got it working, it tended to stay working.

With Microservices, half my time is now spent figuring out every little glitch with 20 different services. It takes weeks for new developers to even get a stable environment running, though the promise was that they'd be able to run a 'git pull && docker-compose up'.

And since we're supposed to be able to use Docker for dev, testing, etc, they now turn off the development environments in the cloud at 5pm, keep it off on weekends, etc to save money.

“once a service becomes 'stable' nobody touches the code for months or even years”

That’s what a lot of people seem to be forgetting. They seem to believe that active development on their code will continue forever and always be kept up to date.

Microservices can be easier to test in that your tests need far less boilerplate to mimic whatever fixture your feature is running in inside the monolith.

If your monolith is huge, having to run all unit tests could take quite a while (and only running the tests you think were touched is disingenuous).

So unit testing is easier in a microservice (or just as hard).

In terms of integration testing, it kind of depends. If you believe microservices lead to more clearly defines abstractions and a cleaner separation of duties then it makes sense why you might think testing that is easier. But you're also testing more complex API boundaries. You're thinking about external (perhaps http?) error codes instead of library exceptions in your monolith language and that can be considered more complex I suppose.

If you ignore the organizational benefits it brings to a large team and assume your monolith will be just as clean or cleaner, then sure monoliths will be easy to test.

You don't create the fixtures... because you're not testing that the system works as expected in the situations that those fixtures would simulate. Having that kind of tests takes time, but I find them invaluable.

Sure. It still takes time to unroll the inter-dependencies.

But if you don't have any and your code is nicely decoupled, then you've already done most of the hard work to break things out into microservices.

I have created that collection of resources about microservices on dev.to.

I fully agree with you. If you are doing tests in isolation it is easy. But testing multiple microservices is really hard.

What we can do about it?: contract testing / consumer driven contracts, chaos engineering, e2e tests (for short term) Soo... nothing easy here ;)

Actually the blog post is structured in a way to move from promises to challenges.

And the promises might be true, but company need to invest a lot to achieve that.

I've been working on a tool to help with these sorts of cross-service boundary tests. Something that can help validate configuration, code, and runtimes are valid while providing all the traditional things you'd expect from unit testing (code coverage, tracing, etc).

I've got the very basic implementation of the testing framework in place (actually just finished the landing page ~3 hr ago) on https://bunt.build. On the GitLab profile I should have a listing of "Planned Features" which are things I've prototyped/toyed around with and I'm pretty sure I can get them to work.

Let me know if you think this would simplify your testing workflow. I'm at the stage where I need some (very harsh) feedback.

Very vague article. I would say that the #1 reason to split a monolith is if your engineering team has grown too big. The main advantage in my experience of “microservices” is that they allow groups of engineers to build & deploy with much less inter-group communication. It’s a great way to scale an organization.

There are other reasons to split a monolith of course, like in high-availability high-traffic services, where isolating specific call patterns on separate fleets makes the system behavior much easier to predict. But primarily I think microservices solve organizational problems.

Article is thin but had loads of links. It's more of a compendium than an article.

I completely agree that microservices are more organizational related than tech related.

Yes, this is just the collection of links or compendium. Not really an article.

btw. This is why I mentioned there "Microservices solve organizational problems and cause technical problems"

Admittedly off-topic, but the GIF they have on that site on the right side of the page with Mac from The Nightman Cometh episode of Sunny to promote the site's dark mode is just too perfect to not mention.

I find it interesting that for every article on HN about the power of Microservices there are 10 more discussing the complexity and difficulty of getting them to work sustain-ably. What is the best usage pattern of Microservices?

microservices are event loops with network boundaries. a gateway to serverless and maximizing your cloud provider profitability

Reply on news.ycombinator.com