microservice architecture   architecting   dark energy and dark matter  

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  


Copyright © 2023 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.

Chris helps organizations improve agility and competitiveness through better software architecture. Learn more about his consulting engagements, and training workshops.

PREMIUM CONTENT

Premium content and office hours is now available for paid subscribers at premium.microservices.io.

MICROSERVICES WORKSHOPS

Chris teaches comprehensive workshops for architects and developers that will enable your organization use microservices effectively.

Avoid the pitfalls of adopting microservices and learn essential topics, such as service decomposition and design and how to refactor a monolith to microservices.

Learn more

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

Remote consulting session

Got a specific microservice architecture-related question? For example:

  • Wondering whether your organization should adopt microservices?
  • Want to know how to migrate your monolith to microservices?
  • Facing a tricky microservice architecture design problem?

Consider signing up for a two hour, highly focussed, consulting session.

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 KQAWEXBH to sign up for $120 (valid until November 21st, 2023). 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.

ASSESS your architecture

Assess your application's microservice architecture and identify what needs to be improved.

Consulting services

Engage Chris to conduct an architectural assessment.



Join the microservices google group

Topics

Note: tagging is work-in-process

Microservices adoption   ·  ancient lore   ·  anti-patterns   ·  application api   ·  application architecture   ·  architecting   ·  architecture   ·  architecture documentation   ·  assemblage   ·  beer   ·  books   ·  containers   ·  dark energy and dark matter   ·  deployment   ·  design-time coupling   ·  developer experience   ·  development   ·  devops   ·  docker   ·  eventuate platform   ·  generative AI   ·  glossary   ·  health   ·  hexagonal architecture   ·  implementing commands   ·  implementing queries   ·  inter-service communication   ·  kubernetes   ·  loose coupling   ·  microservice architecture   ·  microservice chassis   ·  microservices adoption   ·  microservicesio updates   ·  modular monolith   ·  multi-architecture docker images   ·  observability   ·  pattern   ·  refactoring to microservices   ·  resilience   ·  sagas   ·  security   ·  service api   ·  service architecture   ·  service collaboration   ·  service design   ·  service discovery   ·  service granularity   ·  service template   ·  software delivery metrics   ·  success triangle   ·  tacos   ·  team topologies   ·  transaction management   ·  transactional messaging

All content


Posts

24 Jul 2017 » Revised data patterns