Dark energy force: multiple technology stacks

microservice architecture   architecting   dark energy and dark matter  

New public workshop: Architecting for fast, sustainable flow - enabling DevOps and Team Topologies thru architecture. Learn more and enroll.

a dark energy, dark matter force

A subdomain is implemented using a technology stack, which consists of various technology elements, such as frameworks, libraries and a language runtime. Different subdomains might need to use different technology stacks. Also, an application’s technology stack(s) might change over time due to upgrades or changing requirements. Let’s look at how the need to use and evolve multiple technology stacks acts as a repulsive force between subdomains.

A subdomain might need a specific technology stack

A subdomain might use a technology stack simply because it’s the one chosen for the entire application. A Java application might, for example, use Java 17, Spring Boot 3.x, etc. But sometimes, a subdomain might have distinct needs that require a specific stack. A machine learning subdomain might, for instance, need to use Python.

A subdomain’s technology stack requirements might change over time

Sometimes, a subdomain might outgrow its current technology, due to changing requirements. For example, as your application scales you might discover that Python is too slow and that you need to reimplement a subdomain using a high-performance language, such as Java or Rust.

The elements of a technology stack evolve

The technology elements that comprise a technology stack evolve over time. New versions of a technology element are released and replace older versions. Also, sometimes a technology is replaced by a different technology. It’s essential that the technology stack remains current, both in terms of versions and its importance in the market.

What this means for architecture

There are three concerns related to technology stacks:

  • Subdomains using different technology stacks should be packaged as separate components
  • Packaging subdomains as separate services make technology upgrades easier
  • Experimentation to discover new technology is useful

Let’s look at each of these in turn.

Subdomains using different technology stacks should be packaged as separate components

A component can typically only use single technology stack. As a result, if two subdomains are implemented using different technology stacks then it’s likely that they would need to be packaged as separate components. For example, a Java-based subdomain and a Rust-based subdomain could not be packaged together in the same component.

Moreover, unless you are using exotic technology, a Java component has a single classpath. There can be only a single version of a given (Maven) dependency on that classpath. As a result, all of a component’s subdomains must use the same versions of all dependencies. As a result, two Java-based subdomains that use different versions of the same library must be packaged as different components.

Packaging subdomains as separate services make technology upgrades easier

As described earlier, technologies evolve and it’s important to keep an application’s technology stacks current. An application can be upgraded one component at a time. But, a component must be upgraded in its entirely - it cannot be upgraded incrementally. The effort required to upgrade a component is proportional to its size. Small upgrade tasks are less risky and much easier to schedule than a single big bang upgrade.

Consequently, it’s far easier to maintain an application if it consists of small components. In other words, you should strive to package subdomains as separate components.

Experimentation to discover new technology is useful

Managing is an application’s technology stacks involves more than just upgrading to the latest versions. From time to time, you need to replace technologies that have become obsolete due to market trends. Or, you might need to change a subdomain’s implement technology stack to meet changing requirements.

To find a replacement technology, it’s best to experiment with candidate technologies. For example, let’s imagine that to improve performance you need to reimplement a Python-based service using a high performance language. There are lots of potential candidates: Java/JVM, Python or Rust. If your organization doesn’t have an experience with those candidate languages then experiment: write some production code in one or more of those languages and evaluate the results.


  • Subdomains that use different technology stacks need to be packaged as different components/services.
  • Smaller components (groups of subdomains) makes technology stack evolution easier
  • A significant drawback of the Monolith Architecture is that since it consists of a single component there’s a single technology stack and the entire application must be upgraded in its entirely. Conversely, a significant benefit of the Microservice Architecture is that different services can use different technology stacks, the application can be upgraded one service at a time, and experimentation is easier.

microservice architecture   architecting   dark energy and dark matter  

Copyright © 2024 Chris Richardson • All rights reserved • Supported by Kong.

About Microservices.io

Microservices.io is brought to you by Chris Richardson. Experienced software architect, author of POJOs in Action, the creator of the original CloudFoundry.com, and the author of Microservices patterns.

New workshop: Architecting for fast, sustainable flow

Enabling DevOps and Team Topologies thru architecture

DevOps and Team topologies are vital for delivering the fast flow of changes that modern businesses need.

But they are insufficient. You also need an application architecture that supports fast, sustainable flow.

Learn more and register for my June 2024 online workshops....


I help organizations improve agility and competitiveness through better software architecture.

Learn more about my consulting engagements, and training workshops.

LEARN about microservices

Chris offers numerous other resources for learning the microservice architecture.

Get the book: Microservices Patterns

Read Chris Richardson's book:

Example microservices applications

Want to see an example? Check out Chris Richardson's example applications. See code

Virtual bootcamp: Distributed data patterns in a microservice architecture

My virtual bootcamp, distributed data patterns in a microservice architecture, is now open for enrollment!

It covers the key distributed data management patterns including Saga, API Composition, and CQRS.

It consists of video lectures, code labs, and a weekly ask-me-anything video conference repeated in multiple timezones.

The regular price is $395/person but use coupon MJXJDTBJ to sign up for $95 (valid until May 22nd, 2024). There are deeper discounts for buying multiple seats.

Learn more

Learn how to create a service template and microservice chassis

Take a look at my Manning LiveProject that teaches you how to develop a service template and microservice chassis.

Signup for the newsletter

BUILD microservices

Ready to start using the microservice architecture?

Consulting services

Engage Chris to create a microservices adoption roadmap and help you define your microservice architecture,

The Eventuate platform

Use the Eventuate.io platform to tackle distributed data management challenges in your microservices architecture.

Eventuate is Chris's latest startup. It makes it easy to use the Saga pattern to manage transactions and the CQRS pattern to implement queries.

Join the microservices google group