The Rise of Microservices in the Enterprise

Microservices have moved well beyond early-adopter circles. Database development and management are changing significantly as organizations at scale migrate away from monolithic architectures toward fine-grained, independently deployable services. The shift is not happening in isolation: it arrives alongside Kubernetes, software containers, DevOps practices, cloud computing, domain-driven design (DDD), and NoSQL databases—all of which share a common goal of getting new applications into production faster and updating them more frequently.

Microservices bear a conceptual resemblance to the earlier service-oriented architecture (SOA) movement. Both aim to decompose large, tightly coupled systems into smaller, more manageable units. The key difference is that microservices lean much harder into independent deployment, decentralized data ownership, and fine-grained service boundaries defined by business domains.

Industry Signals: M&A Activity Points to Microservices’ Influence

The architectural shift has had observable effects on the industry’s deal-making. The move to microservices—and the container and orchestration ecosystem around it—was cited as a contributing factor in IBM’s plans to acquire Red Hat, as well as in the merger of Hadoop ecosystem vendors Cloudera and Hortonworks. When large incumbents reorganize around a technology trend, it is a strong signal that the trend has reached mainstream enterprise relevance.

Domain-Driven Design: Business Problems First, Technology Second

Zhamak Dehghani, who spent roughly 20 years working as a software engineer and architect in distributed computing, embedded systems, and communications before joining ThoughtWorks, has focused her consulting work on applying domain-driven design (DDD) concepts to operational systems.

The DDD approach inverts a common anti-pattern. Rather than selecting a technology stack first and then bending a business problem to fit it, teams start by deeply understanding the business domain and let that understanding drive architectural and technology decisions. In practice, Dehghani explained, this has pushed organizations toward NoSQL databases that are optimized for specific access patterns, rather than relying on a single general-purpose relational database to serve every use case. ThoughtWorks contributed to this shift, helping drive adoption of purpose-fit data stores and, more recently, low-latency globally distributed SQL databases.

Dehghani also contributes to the ThoughtWorks Technology Radar, a regularly updated technology assessment that many engineering teams use as a reference when evaluating open-source tools and architectural patterns, including microservices options.

From Monoliths to Microservices: Decentralizing Database Ownership

One of the most consequential organizational changes driven by microservices adoption is the movement of database responsibility away from a centralized DBA team and toward the developers embedded in individual business domains.

“Businesses used to put the developers in one tier and the users in another. Now, as you see a move from monoliths to microservices, you see a change in how we organize IT. What used to happen was that operational data was owned by DBAs or database experts that integrated all the applications into one layer of a database.”

— Zhamak Dehghani, Principal Consultant, ThoughtWorks

The old model created a predictable bottleneck. Every schema change, every new data requirement, meant filing a request with a separate team and joining a queue. Developers lost velocity; business units lost agility.

“With microservices, we have changed the model so that the people that own the application or service are also responsible for the database, the data itself, and the schema in which it resides.”

— Zhamak Dehghani

This is a fundamental shift in how data governance works day-to-day: accountability moves to the team closest to the domain, reducing handoff friction and making the feedback loop between software behavior and data model much tighter.

The Big Data Gap: Why Analytical Workloads Lagged Behind

While microservices transformed operational data management, big data and analytical workloads largely developed along a separate, more monolithic track. Open-source frameworks like Hadoop and Apache Spark represented real progress away from proprietary systems, but Dehghani argued that they were mostly implemented as centralized, monolithic platforms rather than domain-aligned services.

The consequences have been practical and painful: these big data projects have been difficult to move into general production, and, in her assessment, they often failed to fully meet organizational needs. Analytical and machine learning data pipelines remained, as she put it, “centralized and disconnected from the business domains” that generated the underlying data.

Data lakes—once the defining artifact of enterprise big data strategy—have frequently devolved into data silos: large, ungoverned repositories where data enters but value struggles to exit.

Data Mesh: Applying Microservices Thinking to Big Data

Dehghani outlined an alternative in a post on Martin Fowler’s widely read technology blog (martinfowler.com), where she introduced the concept of the data mesh—a distributed data architecture paradigm that applies domain-driven, decentralized ownership principles to analytical data, much as microservices did for operational data.

The core idea: instead of funneling all analytical data into a central lake or warehouse owned by a data engineering team, each business domain owns and serves its own analytical data as a product. Consumers—other domains, data scientists, ML pipelines—access domain data through well-defined interfaces, just as they would call a microservice API.

“The way we broke down operational capabilities around domains has to come to big data, too.”

— Zhamak Dehghani

What a Successful Convergence Requires

Dehghani identified several prerequisites for microservices and big data to converge effectively in practice:

• Infrastructure abstraction: Individual application teams should not be expected to own and maintain the infrastructure their services run on. Cloud providers and platform/infrastructure teams must provide self-service capabilities that abstract away that complexity.
• Organizational maturity: The transition is a journey, not a weekend project. Teams that attempt to run microservices on cloud infrastructure overnight without building foundational skills and processes tend to fail.
• Incremental adoption: Dehghani specifically cautioned against big-bang migrations. Many failures she observed were attributable to organizations not recognizing that the architectural shift requires an incremental approach, with skills and processes maturing in step with the architecture.
• Respecting existing skill sets: The path an organization takes must account for what its teams already know. Copying another organization’s microservices playbook without adjusting for your own capability gaps is a recipe for trouble.

“Respecting organization maturity is important. I see a lot of people that want to run microservices on the cloud overnight. But that change is a journey in itself. A lot of failures I see are due to not recognizing that—not having an incremental approach.”

— Zhamak Dehghani

Key Takeaways for Data and DevOps Engineers

• Microservices shift database ownership from centralized DBA teams to domain-aligned development teams—a significant governance and organizational change, not just a technical one.
• Big data and analytical architectures are beginning to follow the same decentralization path, with the data mesh pattern offering a concrete model.
• Data lakes without domain ownership tend to become silos. Domain-aligned data products are the proposed antidote.
• Kubernetes, containers, cloud platforms, DDD, and NoSQL are all part of the same wave. Understanding how they reinforce each other is essential for architects designing modern data platforms.
• Incremental adoption and honest assessment of organizational maturity are more reliable predictors of success than raw ambition or technology choices alone.