Dark energy force: multiple technology stacks

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.

Summary

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

Follow @MicroSvcArch

Microservice Architecture

Dark energy force: multiple technology stacks

a dark energy, dark matter force

A subdomain might need a specific technology stack

A subdomain’s technology stack requirements might change over time

The elements of a technology stack evolve

What this means for architecture

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

Summary

About Microservices.io

MICROSERVICES WORKSHOPS

LEARN about microservices

Get the book: Microservices Patterns

Example microservices applications

Remote consulting session

Virtual bootcamp: Distributed data patterns in a microservice architecture

Learn how to create a service template and microservice chassis

BUILD microservices

Consulting services

The Eventuate platform

ASSESS your architecture

Consulting services

Topics

Posts