In my last post, I presented the concept of the data mesh. One thing that is often discussed in regards to the data mesh is how to make an agile architecture with data and microservices. To understand where this needs to go to, we must first discuss the architectural quantum.
What is the architectural quantum?
The architectural quantum is the smallest possible item that needs to be deployed in order to run an application. It is described in the book “Building Evolutionary Architectures“. The traditional approach with data lakes was to have a monolith, so the smallest entity was the datalake itself. The goal of the architectural quantum is to reduce complexity. With microservices, this is achieved by decoupling services and making small entities in a shared-nothing approach.
The goal is simplification and this can only be achieved if there is little to no shared service involved. The original expectation with SOA was to share commonly used infrastructure in order to reduce the effort in development. However, it lead to higher, rather than lower, complexity: when a change to a shared item was necessary, all teams depending on the item had to be involved. With the shared-nothing architecture, items are rather copied than shared and then independently used from each other.
Focus on the business problem
Each solution is designed around the business domain and not around the technical platform. Consequently, this also means that the technology fit for the business problem should be chosen. As of now, most IT departments have a narrow view on the technology, so they try to fit the business problem to the technology until the business problem becomes a technical problem. However, it should be vice versa.
With the data mesh and the architectural quantum, we focus fully on the domain. Since the goal is to reduce complexity (small quantum size!) we won’t re-use technology but select the appropriate one. The data mesh thus only works well if there is a large set of tools available, which can typically be found by large cloud providers such as AWS, Microsoft Azure or Google Cloud. Remember: you want to find a solution to the business problem, not create a technical problem.
Why we need data microservices
After microservices, it is about time for data microservices. There are several things that we need to change when working with data:
- Focus on the Business. We don’t solve technical problems, we need to start solving business problems
- Reduce complexity. Don’t think in tech porn. Simplify the architecture, don’t over-complicate.
- Don’t build it. It already exists in the cloud and is less complicated to use than build and run it on your own
- No Monoliths. We used to build them for decades for data, replacing a DWH with a Datalake didn’t work out.
It is just about time to start doing so.
If you want to learn more about the data mesh, make sure to read the original description of it by Zhamak Dehghani in this blog post.