Data Management-Ask any IT leader about the future of enterprise application development, and they’ll likely say “microservices.” Made popular by large web companies, the microservices model is finding its way into many businesses.
Microservices are lightweight, fine-grained modules that each do one thing well and are connected to create larger applications. They go well with cloud native environments.
It’s easy to see the appeal of microservices. Developers can work in parallel using their choice of programming language, frameworks and data formats. Developers can deploy and scale the components of applications built around microservices without having to coordinate with others.
From a business perspective, the appeal is more functionality, delivered faster.
But early adopters have found there’s a big mountain to climb: data management. Typical enterprise applications share information by sharing a database. In the microservices world, that’s a big no-no; everything is ideally done with APIs (application programming interfaces), events, and message passing.
An ideal microservice would completely isolate its data (data encapsulation) from the outside world and only expose it using an API. The larger goal is to avoid “data coupling,” whereby a change in how one microservice represents its data must then be communicated and coordinated with other microservice developers.
As anyone who has upgraded a big enterprise application knows, data coupling and data dependencies can slow the introduction of new features.
But insisting that microservices can’t share data under any circumstances will inevitably cause more cost and complexity than allowing certain forms of controlled data sharing. It’s possible—even desirable—to meet the needs of developers to work independently, while meeting the broader needs of the larger application team.
Challenges with Data Encapsulation
It helps to think in terms of a typical large application, such as a retail website, where frequent updates are needed. First, we’ll look at the typical data management problems encountered with microservices, and then we’ll suggest a simpler way.
It’s often the case that certain data elements, such as customer and product information, are used in many places in a large application. In a pure microservices design, a single microservice would be responsible for a single topic, such as customer information, and the associated data elements, with all others requesting access and updates only via an API owned by the microservice.