Balancing Technology Heterogeneity in Microservice Architectures

Note: This is an opinionated summary of a research paper by the first author. The opinions expressed exceed the scientific insights from the study. You can download the original study here.

The Promise and the Problem

Microservices offer an enticing promise: use the best tool for each job. Need machine learning? Use Python. Building a high-performance video renderer? Go with C++. Processing massive datasets? Reach for Scala or Go. Classic web backend? Use Java or JavaScript.

But here is what practitioners actually told us in our research:

Technology heterogeneity behaves like many things. The value curve is a parabola, logically speaking. It has a sweet spot. Too little is not good; too much isn’t good either.

So the challenge is to strike a balance. A balance between the perks and issues of uniformity and the perks and issues of heterogeneity. A balance between the extremes of all microservices using the same technology, versus every microservice using a different one.

Key Insights from the Research

1. Technology Heterogeneity Lives on a Spectrum

We conceptualized technological heterogeneity (TH) as an n-dimensional spectrum. Each dimension represents a technology type:

• Application technology: Programming languages, frameworks, libraries, databases
• Deployment technology: CI/CD pipelines, deployment platforms, service configuration
• Cross-cutting aspects: APIs, logging, monitoring, documentation, testing, authentication

There is no one size fits all: You can be uniform in one dimension while being heterogeneous in another. For example, you might standardize on HTTP for APIs while allowing diverse programming languages.

2. The Trade-Off Is Complex and Context-Dependent

The benefits of technological heterogeneity include:

• Using best-fitting technology for each use case
• Learning which technologies work best in specific scenarios
• Avoiding technology lock-in
• Maintaining long-term flexibility

But heterogeneity also brings costs:

• Increased maintenance complexity
• Loss of code reuse opportunities
• Higher onboarding and learning efforts
• Reduced ability to move engineers between teams
• Increased operational overhead

The optimal balance depends on your project’s environmental factors:

• Software engineers’ skills: Experienced teams handle heterogeneity better
• Company culture: Does it value innovation or stability?
• Project phase: Early-stage projects benefit from experimentation; mature projects need stability
• Project domain: Regulated industries (healthcare, finance) have stricter constraints

3. Essential vs. Accidental Heterogeneity

We distinguish between two types of technological diversity:

Essential heterogeneity: Technology introduced with clear goals (e.g., using Python for machine learning because it has superior libraries)

Accidental heterogeneity: Technology introduced for technology’s sake (e.g., because it’s fun or a developer’s favorite)

The goal of governance is to encourage essential heterogeneity while preventing accidental heterogeneity.

4. Technology Governance

In practice, the degree of technological heterogeneity is often governed by meaningful standardization. Standardization means agreeing on certain technologies that everyone can use without a second thought, allowing for essential heterogeneity. Whether deviations from standardization are even feasible—that is, using technologies outside the approved pool—depends on environmental factors such as organizational culture.

We found governance techniques that help to create the standardization (who is even responsible?), how to disperse knowledge about it (create awareness but also the skills within the teams), and how to consistently stick to the standardization (by enforcement or incentives):

See the appendix of the original publication for the details of each technique.

5. Standardize Interfaces, Not Always Technology

A crucial insight: Sometimes you should standardize the interface rather than the underlying technology.

Examples:

• Standardize HTTP for microservice communication, not the programming language
• Standardize logging to stdout, not the logging library
• Standardize container images for deployment, not the build process

This allows flexibility while maintaining interoperability.

What This Means for Practitioners

1. There’s no one-size-fits-all solution. Your approach should adapt to your project’s context. For example, early fast-moving projects can benefit from more heterogeneity; projects working towards stability and maintenance mode benefit from more uniformity.

2. Don’t let technological heterogeneity emerge by chance: Make it a habit to speak about it and make everyone understand that adding technologies can lead to serious costs. Make it an intentional trade-off decision instead of just letting it happen and govern proactively!

3. Get everyone on board: Make sure the people who work with the technologies on a daily basis are at least heard before agreeing on standardization. Giving people a chance to contribute to the decision decreases the chance of the decisions being not backed by the individual teams.

4. Invest in organizational mechanisms: Inter-team communities, documentation, education programs, and collaborative tools are as important as technical solutions.

5. Incentivize sticking to the standardization: Besides regulated industries, giving the microservice teams more responsibilities in their decisions helps to scale development. Instead of enforcing technologies (e.g., via audits), try to govern with incentives. For example, a service template can provide a head start with a new microservice because monitoring, logging, configuration, deployment, and CI/CD come with it for free. Using different technologies remains feasible, but teams must implement those functionalities themselves—something typically only done when there’s a compelling reason, especially under feature pressure.

6. Revisit regularly: As your project evolves, so should your technology governance. What worked in the innovation phase may not work in the maturity phase.

Learn More

📄 Download the full paper (PDF)

Published in Empirical Software Engineering, Volume 30, 2025.

Full Citation:

Schwarz, G.-D., Heltweg, P., & Riehle, D. (2025).
Balancing technology heterogeneity in microservice architectures.
Empirical Software Engineering, 30, 127.
https://doi.org/10.1007/s10664-025-10684-4

License: This article is licensed under the CC BY 4.0 license, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original authors and source.

Supplementary Materials: The complete research materials including interview summaries, code system, and all 13 best practices are available on Zenodo.

This research was conducted at Friedrich-Alexander-Universität Erlangen-Nürnberg, examining how industry practitioners balance technological diversity in microservice projects. The study was funded by the German Federal Ministry of Education and Research (Software Campus 2.0) and the German Research Foundation.