Microservices (as a topic) are alive & wiggling. I assume you know what they are about & you've got some clue about the substance of criticism that has hit them. I'm not really that much interested in MS as such, but I'm far more concerned with the general issue of building complex, integrated solutions in a maintainable (long-term) way:
- testable
- modular - to distinguish cohesive business services
- with multiple, intertwined streams of work
In short ways - I intent to use the practices of Continuous Delivery in ever-growing, integrated, scalable IT landscape.
Thus spoke Udi
I've got some thoughts on MS applicability in such scenarios, but it's always good to hear other people opinions - recently I've seen a very interesting presentation by Udi Dahan (there was a link to it on InfoQ few days ago):
"An Integrated Services Approach"
I highly recommend watching whole presenation, but for the purpose of this blog post I want to focus on just few interesting observations (Udi's, not mine):
- people tend to forget that reducing the coupling shouldn't be a target itself, it's the balance between keeping low coupling & high cohesion, that you should watch closely
- there will always be some coupling, it's needed to keep the interfaces precise, clear & well defined
Live with it
And I totally agree with what has been said:
There's no MAGIC way to integrate products / systems / applications / services so they are 100% separately testable, releasable, maintainable. No silver-bullet framework / library & there will never be -> because coupling is required for proper (beneficial) application integration.
Of course there are techniques to help (that you should befriend, if you haven't already):
- asynchronous, message-oriented, brokered communication
- open API / contract specification
- DTO
- design for failure & fail fast
- tiered servicing
- infrastructure-agnostic deployment model
- mocking / stubbing / faking responses
- fp-like side effect free functions
but at least some of them (especially the technology-related ones) can't be applied freely (in any kind of application / service).
Consequences
Don't treat the coupling & dependencies as an excuse:
- I can't do automated testing, because ...
- I can't have an isolated test environment, because ...
- I can't have a separated release cycle, because ...
- This tech debt focal point can't be removed, because ...
It's wrong to have all of these postponed just until you get rid of excessive coupling / dependencies. The problem is that it will never fully happen - start where you are & keep applying the principles that make sense in your scenario.
I keep my suggestion as a motto on my own wall:
