The evolution of the Microservice Architecture pattern language

pattern language   microservice architecture  

---

It’s been 10 years since I began writing the Microservice Architecture pattern language. Here’s a presentation that I gave at the recent Pattern Languages of Programs, People & Practices (PLoP 2024) conference on the evolution of the pattern language.

Introduction to the pattern language

Patterns have played a major role in my thinking for decades and it was great to discuss the evolution of the pattern language with the patterns community. Since the audience came from a variety of fields - not just software development - I started by explaining the core concepts of software architecture and architectural styles, highlighting the importance of non-functional requirements like runtime behavior and ease of development. I then introduced the Microservice Architecture, an architectural style that enables fast flow – a way of working that allows teams to deliver continuous streams of small changes, fostering rapid feedback and learning.

The pattern language, which I started developing back in 2014, provides guidance to developers navigating the complexities of implementing a Microservice Architecture, helping them decide whether it is a good fit for their application, and address the various challenges that arise.

The evolution of pattern language

A key part of the presentation discussed the evolution of the pattern language over the years. It wasn’t a carefully planned process; it grew organically based on practical experiences and feedback.

Anti-patterns of microservices adoption

I shared how I introduced the anti-patterns of microservice adoption, based on my observations, to help developers avoid common pitfalls. I also explained how key definitions within the pattern language were refined over time, leading to a clearer understanding of core concepts like loosely coupled and independent deployable services.

About dark energy and dark matter forces

One of the more interesting developments of the pattern language was the introduction of dark energy and dark matter as metaphors for the forces that shape architectural decisions. Dark energy, representing forces pushing for smaller, more independent services, resulting in improved team autonomy and agility. Dark matter, on the other hand, represents the forces that encourage larger services, even a monolith, in order to avoid the downsides of a distributed architecture. These opposing forces create a constant tension in architectural design and architects must carefully balance them.

Your context determines the strength of dark energy and dark matter forces

It’s important to remember that the context plays a crucial role in determining the strength and relevance of these forces. The size and structure of the development team, the nature of the application, and the capabilities of the deployment pipeline all influence the architectural choices.

Beyond patterns

Moving beyond simply applying predefined patterns, I introduced Assemblage, which is a deliberative process for designing a microservice architecture.

The future of the pattern language

Looking ahead, I outlined several improvements for the pattern language. These include refining the terminology used to describe the roles within a pattern’s solution, simplifying the treatment of database architecture patterns, and exploring the relationship between patterns and Team Topologies.

While the focus is often on microservices, I also emphasized that monolithic architectures are still valid and valuable for many applications contexts. Applying principles like modularity and minimizing build-time coupling can even help create well-designed, modular monoliths that are easier to maintain and evolve.

The presentation concluded by emphasizing the continued relevance of the pattern language, the need for ongoing adaptation to keep pace with new knowledge and changes in the technology landscape, and the importance of using precise language to effectively communicate architectural concepts.

Slides

Need help with accelerating software delivery?

I’m available to help your organization improve agility and competitiveness through better software architecture: training workshops, architecture reviews, etc.

Learn more about how I can help