From Client server to MVC to microservices there has been a steady progression in application architectures. The core driver for these paradigm shifts are
- Questions on coupling and cohesion within the components of the software.
- Where do we expect changes and how can the software that we build today adapt to those changes tomorrow?
MVC has championed a few ideas for these questions : three core component types : models, views, controllers are ‘identified’ i.e. explicitly labeled. Given this PoV, you can now think of the problems/characteristics of these 3 components in a more focused manner. Please note that all three components may be needed/present in the same architectural layer ex: a web app written in Angular, let’s say, may have all 3 components.
Microservices has championed a few ideas too : modularize your application using ‘domain driven design’. Identify ‘modules’. Deploy a module along with its API and persistence components together. Scale them together. What does this achieve?
- Significant benefits for application: tailored scalability based on module’s usage patterns.
- Resilience for production issues. Quick isolation of faulty modules, optimized business continuity with the rest of the modules.
- Nimble practices in new feature development, packaging/release, rollout and rollback if needed.
Microservices has ventured beyond component ‘design patterns’ and gone into enterprise application patterns. There are several of them now that span more than one architectural layer.
And then the idea of DataMesh.
DataMesh addresses the core challenges in data traceability, slow adaptability of architectures to continuous real-world changes. It does this by putting back focus on data. Consider ‘Data’ as ‘Product’. Let ‘Teams’ own ‘Data’ throughout the data lifecycle. Of course each product/data needs to be interconnected : should reference others, notify others when it changes and adapt to changes in other products/data. However the paradigm shift is : let one team deal with all possible usage patterns for the data/product. This is an ‘organization’ pattern not just an ‘enterprise application’ pattern.
The enabler in each of the above architectural transition phases (and many many more) is ubiquitous availability of necessary technology ex: internet for MVC.
For DataMesh the necessary ingredients are already in-place :
- Cloud and cloud services. This includes not just monitoring, logging, analytical services but newer abilities like ‘data catalog’.
- Ability to write/repeat IaC templates to support various architectural blueprints across your organization.
- And a bigger enabler is the containerization of the application’s features/modules.
These enablers can help an organization realize the tremendous benefits of viewing data-as-your-organization’s-product.
This post was later published on LinkedIn here.