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 Monoliths and microservices, Samer and Russell spoke again—this time about the implications of data when you’re building microservices and monoliths.


Download our latest Platform Thinking guide today, and get a head start on your competition by differentiating your business through custom platform engineering.

How Do Microservices and Monoliths 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, a 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 on a subject area by subject areas basis. For example “a consistent, single view of the Customer” may be more critical to the enterprise than “a consistent single view of Supplier”. And if you’re working on a microservice that touches Customer, you 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 the Data Model Challenges, What’s the Conclusion to the Monoliths 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.

Monoliths 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 learn more about our own processes, check out our free ebook, Platform Thinking: Creating Real-World, Scalable Platforms.

New Call-to-action

Click to Comment