Still Struggling Between Platforms and Microservices? Think About Your Data Models
In a conversation between engineering and strategy professionals, we take a look at digital transformation and the interaction between platforms and microservices.
Join the DZone community and get the full member experience.Join For Free
Wouldn’t it be nice if every enterprise technology decision was black and white? We all know digital transformation requires us to be agile and move quickly—but it’s not that simple.
In a perfect world, you might be able to leave your legacy-laden monolith IT infrastructure behind to achieve greater agility. However, a recent discussion between our own Samer Fallouh (VP of Engineering) and Russell Villemez (Head of Technology Strategy) showed just how complicated that would be.
To further solidify the common ground between platforms and microservices, Samer and Russell spoke again—this time about the implications of data when you’re building microservices and monoliths.
How Do Microservices and Platforms Impact Data Models?
Russell: "Microservices architectures take a decentralized approach towards data management. There is no unifying schema. Every microservice implements it’s own data model and view. While that reinforces the objectives of agile and lets developers move quickly, it does not solve the very real need to have a single, enterprise view of certain types of data."
In contrast, a platform approach can be used to deliver that single, enterprise view. It starts with the canonical data model for data at rest, and very often carries over that same canonical data model for data in motion. In other words, the platform provides access to enterprise master databases - whether from microservices or otherwise - and enforces consistent adherence to the canonical model as data moves into and out of those databases.
Samer: "You’re right, you build a platform with microservices architecture in the name of agility. Your data will be distributed in most cases to the different microservices, but as you add more and more across the organizations a centralized data, one place of truth, might not happen. At that point, there’s just too much rework and refactoring that needs to be done because of varied data structures."
But at the same time, having a common model comes with its own challenges. When you work on a single data model, individual teams looking to meet agile demands start to step on each other’s toes. And as the technology infrastructure changes, it’s hard to get everyone to agree on the single best approach.
There’s more overlap in this discussion that many people tend to consider.
Russell: "You have to know where it makes more sense to sacrifice consistency and where it makes more sense to sacrifice speed and agility. There are many business operations and many industries in which 'eventual consistency' doesn’t cut it. In those cases, we need to know the state of things across the enterprise this very millisecond - before we execute the next line of code. Therefore we must have a predetermined architecture that provides that capability. And 'predetermined' means slowing down and designing for the bigger picture before jumping in and writing code around a highly localized data model."
I think we can decide which type of approach is most appropriate in a subject area by the subject area's basis. For example “a consistent, single view of the customer” may be more critical to the enterprise than “a consistent single view of the supplier.” And if you’re working on a microservice that touches the customer, you'd better adhere to the enterprise canonical. So ideally, every team should be aware of the enterprise data strategy so that rogue implementations are prevented.
Given Data Model Challenges, What’s the Conclusion to the Platforms and Microservices Debate?
Samer: "No matter what you’re building, you need a team that can zoom into and out of the situation to understand the short-term and long-term needs- a skill we can all learn from designers. Your business model will evolve to provide more value to your customers, you need to empower your business with technology that can adapt to your changes; which is why you need to know the value of microservices while integrating the virtues of monoliths. It’s never going to be one answer to all problems, you need to define the problem well and tailor your technology solution to address today’s need and be flexible enough to grow in the future."
Russell: "It’s not an 'either/or.' You have to use the right tools to solve the specific problem. Do you need to quickly experiment and innovate rapidly? Lean into microservices with the expectation of eventual integration down the road. Do you need to integrate with COTS, legacy, or enterprise-wide applications? Take the time to develop a data strategy and platform requirements before you start. Note that in the case of the latter, this doesn’t mean that you have to sacrifice a loosely-coupled implementation. It simply requires more upfront planning and architecting to determine whether or not there’s a canonical model and an enterprise platform, and how to use them."
Platforms or Microservices? It’s All About Strategy
At first glance, it might seem easy to choose between microservices or monoliths based on the data model you want to work with, but in reality, the decision is all about a healthy balance with the right strategy in mind.
If you want to start leveraging enterprise technology to drive digital transformation, download our free eBook, Enterprise Technology for Business Outcomes.
Published at DZone with permission of Doug Platts. See the original article here.
Opinions expressed by DZone contributors are their own.