The hidden value of a monolith
In the rush towards microservices, some teams seem to be unaware of the value previously provided by their older monolithic architecture, particularly if a central relational database was used. With a monolithic architecture and especially with a central relational database, conflicts arising from competing product budget streams are resolved at compile time, data load time, or integration test time: at any rate, almost certainly before the software reaches Production.
However, in a microservices world, the coordinating effect of the monolith or central relational database are typically lost, potentially allowing changes that conflict at a fundamental business level to reach Production before the conflicts are detected.
Data strategy for microservices
Unless different product teams are using some kind of shared bus or event store for cross-service consistency, we predict that the lack of a monolith or central database could result in teams duplicating data and logical entities across different data silos.
The issue of pan-organizational data consistency and data integrity is something that cannot be ignored if business outcomes are to be met and sustained over the coming years, even as organizations adopt patterns such as microservices to help achieve more rapid and frequent software changes.
To read the full article, download the full CA DevOps Perspectives 3 report from: