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.
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.
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.
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.
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.
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.
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.
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?
https://www.slideshare.net/aahoogendoorn/designing-and-build... , slide 26 ;)
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.
https://www.codewithjason.com/rails-integration-tests-rspec-...
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.
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 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.
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'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.