Microservices, clearing up the definitions
In the previous article, we looked at how loose coupling can lead to more complexity.
In this article, we’ll attempt to establish a single method to reason about microservices that everyone can agree on.
In my experience, an informal definition for software boundaries like 'decoupled by domain’ is a square peg for a round hole. This is because software correctness criteria are formal, even if we don’t write them that way. Given enough load, we eventually come up against the hard truth of whether our software is stable or not and these bugs are usually hard to identify in testing. Having said this, I’m writing this article in good faith and actively looking for possible alternatives to my established opinion.
Since there is no formal definition for what constitutes a microservice, we’ll have to build on what comes up in the literature. We need to be very liberal around what we allow or some people could rightfully feel misrepresented. On the other hand, we need to be very strict about what we mean about the practicalities of each principle or this article will not be very useful in finding the truth we’re looking for.
Based on earlier readings, I’ve gathered some themes which were common to all definitions:
- Multiple, mostly independent teams with 10 people or less
- Domain driven separation of responsibilities
- Decentralised data (i.e.: no single central monolith)
- Each microservice participating in a larger software
If we’re going to work with these principles in good faith, we need to allow for some caveats, like logging or monitoring. If the microservices exist to be a part of some bigger software implementation, we need to excuse observability concerns from the “decentralised data” requirements. I don’t think anyone can or should expect front-line support to dig through two dozen microservice logs to find a problem with the client’s request. We’ll restrict the third point to mean “decentralised internal application state".
If microservices exist as part of some greater software, we’ll also need to define some services which touch on multiple microservices. Failing this, we would have standalone services like “reporting”, “sales support” and “bookkeeping”, where human intelligence with its flexibility (and tendency for mistakes) would be required to enter the same information into multiple systems. The impracticality of this practice was what gave rise to the concept of software integration in the late 90s, early 00s. It follows that unless we want to go back to this, microservices will need to share some data somehow.
This can happen by either
- one service querying the other,
- some shared database for some subset of the information, or
- through replicating some information from another,
or some combination of these.
Our new, more formal definition looks like this:
- Shared data between microservices (sharing, querying or replicating)
- Operations (potentially) reading and updating multiple microservices
- Some independently managed datastores with atomic events
I’m sure some people already disagree with the assessment so far, but I think we can all come together on the following statement.
For a software to be predictable, we need to make sure that single events from the client’s perspective are reflected as such throughout the whole system.
This means that if the client asks for a change, all its facets need to be accepted or rejected by the system as a single package, we can’t pick and choose which aspects to do or not to do, unless we have an intuitive way to prompt the user about what we have failed to achieve and that fault is translated back to the client. It’s easy to see that if we allow for such failures, we must design the corresponding 'translation' to the end user, and that this means understanding our client’s competence level with regards to that system. In other words, we can shift some of the responsibility on the end user, but only the ones we can expect them to manage appropriately and by providing them the right tools.
The above already spells out a useful framework to reason about microservices. We know that we
- maintain multiple state-stores,
- run operations working on this state,
- must be able to mitigate specific failure cases arising from this environment
In other words, we need to know where and how the whole, holistic software (the aggregate of all microservices) can behave differently than what we laid out in the requirements.
In the next article, we start formalising a simple framework to reason about application correctness based on the definitions established here.
https://andrasgerlits.medium.com/a-microservices-and-how-to-analyse-them-aa6d33f4dcf6
