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 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.
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 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.
There are three concerns related to technology stacks:
Let’s look at each of these in turn.
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.
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.
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.
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 clients around the world adopt the microservice architecture through consulting engagements, and training 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 moreChris offers numerous other resources for learning the microservice architecture.
Want to see an example? Check out Chris Richardson's example applications. See code
Got a specific microservice architecture-related question? For example:
Consider signing up for a two hour, highly focussed, consulting session.
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 MECNPWNR to sign up for $120 (valid until May 16th, 2023). There are deeper discounts for buying multiple seats.
Take a look at my Manning LiveProject that teaches you how to develop a service template and microservice chassis.
Engage Chris to create a microservices adoption roadmap and help you define your microservice architecture,
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.
Engage Chris to conduct an architectural assessment.
Note: tagging is work-in-process
anti-patterns · application api · application architecture · architecting · architecture documentation · assemblage · beer · containers · dark energy and dark matter · deployment · design-time coupling · development · devops · docker · eventuate platform · glossary · hexagonal architecture · implementing commands · implementing queries · inter-service communication · kubernetes · loose coupling · microservice architecture · microservice chassis · microservices adoption · microservicesio updates · multi-architecture docker images · observability · pattern · refactoring to microservices · resilience · sagas · security · service api · service collaboration · service design · service discovery · service granularity · service template · software delivery metrics · success triangle · tacos · team topologies · transaction management · transactional messaging