Some time before attending some really interesting sessions about microservices and SOA during the Tech Event 2017 last month, a dilemma popped up in my mind: Is there still room for Canonical Data Model in a Microservices architecture? Fortunately, the Tech Event was very helpful! During the session: Microservices and Canonical Data Models: Friends or Foes? Ronald van Luttikhuizen tried to answer almost the exact same question. So what did I learn from this event?
This is not another blog about microservices. However, I will need to explain microservices a bit before I can delve into the problem described here. So here we go:
Microservice architectural style
The most common approach to develop a single application as a suit of small services, which are each running in their own process and communicating with lightweight mechanisms, most often use a HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment” – Martin Fowler.
Now we have a clear understanding of Microservices, let’s start with answering the question in the title of this blogpost.
From SOA to Microservices
When we look at the “traditional’ SOA” way, we see that companies mostly prefer to use the “lasagna style”. The “lasagna style” is a monolith with web services, where all services have a central governance, typically employed on a single platform and with a lot of dependencies. Scaling is an all-or-nothing effort. A canonical data model is normally used here. In my opinion, this approach isn’t very effective: we are still looking at the application-functionality in terms of technical horizontal layers.
A Microservices Architecture, at the other hand, is exactly the opposite: it has vertical layers. This means that the team which implement the microservices, are also directly responsible for the entire architecture, including the choice of tools, supporting and fixing issues in production. Another important aspect of this architecture is the shared platform. On this platform you can expose all your services as microservices, but you can also consider a hybrid architectural approach: “microservices within a monolith”.
Microservices impact to Canonical Data Model
The Canonical Data Model is a design pattern used to communicate between different data formats. It’s a semantic model for catching all the definitions and entities. In the last 15 years, this model was expected to work for all the services. But it ended up to be too big and hard to maintain and also very context sensitive.
Microservices are extremely decoupled in terms of technology, based on event-driven and asynchronous messaging. It’s just in their nature. At this moment, the answer to my question is still yes. But on the condition that it’s not forced to function as a common model between all the services. The Canonical Data Model should only better exist on the outside, where we publish events or call a service – and shouldn’t be pulled into the implementation.
Continuous integration is the key to a successful implementation of CDM and microservices. Since you need to automate all the process and run regression testing automatically to find out if your change is correct. Another important practice for microservice is to create it for domain. In this way, the team will be able to create the ad-hoc CDM and also to implement the microservice. CDM is also still a useful semantic tool, helping us to better understand the data which we are exchanging or changing during our implementation. There won’t be a central team or owner anymore, who’s managing the Canonical Data Model, but a small CDM, which is only for the information that we are really exchanging, defined by the events.
