=Paper=
{{Paper
|id=Vol-2072/paper2
|storemode=property
|title=Analyzing the Relevance of SOA Patterns for Microservice-Based Systems
|pdfUrl=https://ceur-ws.org/Vol-2072/paper2.pdf
|volume=Vol-2072
|authors=Justus Bogner,Alfred Zimmermann,Stefan Wagner
|dblpUrl=https://dblp.org/rec/conf/zeus/BognerZ018
}}
==Analyzing the Relevance of SOA Patterns for Microservice-Based Systems==
https://ceur-ws.org/Vol-2072/paper2.pdf
Analyzing the Relevance of SOA Patterns for
Microservice-Based Systems
Justus Bogner1,2 , Alfred Zimmermann1 , and Stefan Wagner2
1
Reutlingen University of Applied Sciences, Germany
{justus.bogner,alfred.zimmermann}@reutlingen-university.de
2
University of Stuttgart, Germany
{justus.bogner,stefan.wagner}@informatik.uni-stuttgart.de
Abstract. To bring a pattern-based perspective to the SOA vs. Microser-
vices discussion, we qualitatively analyzed a total of 118 SOA patterns
from 2 popular catalogs for their (partial) applicability to Microservices.
Patterns had to hold up to 5 derived Microservices principles to be appli-
cable. 74 patterns (63%) were categorized as fully applicable, 30 (25%)
as partially applicable, and 14 (12%) as not applicable. Most frequently
violated Microservices characteristics were Decentralization and Single
System. The findings suggest that Microservices and SOA share a large
set of architectural principles and solutions in the general space of Service-
Based Systems while only having a small set of differences in specific
areas.
Keywords: Microservices, SOA, Service-Based Systems, Design Patterns
1 Introduction
Over the last decade, Service-Oriented Computing (SOC) [13] established itself
as one of the most important paradigms for distributed systems. The implemen-
tation of enterprise-wide software landscapes in the style of Service-Oriented
Architecture (SOA) [3] brought benefits with respect to encapsulation, interoper-
ability, composition, reuse, loose coupling, and maintainability. However, increased
standardization and governance efforts, higher architectural and technological
complexity, and sometimes vendor or product lock-in caused frustration and lead
to failed SOA adoption projects [11]. In recent years, Microservices [7, 12] as an
agile, DevOps-focused, decentralized service-oriented variant with fine-grained
services quickly gained in popularity and tried to address some of the issues
with both large monolithic applications as well as “traditional” Service-Oriented
Systems based on SOAP/WSDL and a central Enterprise Service Bus (ESB).
There is still an ongoing discussion in industry and academia about the
differentiation of SOA and Microservices. Some see it as a very new architectural
style that needs to be treated very differently (“revolutionary” perspective), some
see it merely as a specialization of SOA, e.g. “fine-grained SOA” (“evolutionary”
perspective). While many papers have been published on the subject, so far
N. Herzberg, C. Hochreiner, O. Kopp, J. Lenhard (Eds.): 10th ZEUS Workshop, ZEUS 2018,
Dresden, Germany, 8-9 February 2018, published at http://ceur-ws.org/Vol-2072
10 Justus Bogner et al.
no comprehensive pattern-based approach to compare the two has been taken.
Software design patterns are a well-established form to document proven solutions
to recurring design problems within a specific context in a technology-agnostic
yet easily implementable way. They base their origin in Alexander’s building
pattern language [1] and went mainstream with the famous Gang of Four “Design
Patterns” [8]. There is large catalog of documented service-oriented patterns that
emerged over the years as a result of growing SOA industry experience. However,
it is not fully clear, if these patterns are of value for Microservice-Based Systems.
The contribution of this work is to add a pattern-based perspective to the
“SOA vs. Microservices” discussion by analyzing the applicability of existing SOA
patterns for a Microservices context. To create a basis for important principles
of Microservice-Based Systems, Section 2 introduces existing comparisons of the
two service-based architectural styles. Section 3 outlines the detailed scope and
research method of the pattern-based approach, while Section 4 presents the
results. Finally, Section 5 closes with a summary, limitations, and an outlook on
potential follow-up research.
2 Related Work: SOA vs. Microservices
Several perspectives on the comparison of SOA and Microservices have been
published so far. Zimmermann first compares the two most popular definitions of
Microservices, namely the one of Lewis/Fowler and the definition of Newman [19].
He distills common tenets and warns that the two definitions mix concerns
related to process, organization, architecture, and development, which should
be avoided when defining an architectural style. He then analyzes the identified
tenets for SOA pendants and finds similarities for most of them. For him, the
largest differences show with respect to decentralized governance, infrastructure
automation, independently deployable services, and lightweight communication
as opposed to a central ESB. Based on these findings, the analysis concludes that
Microservices can be seen as a specific development and deployment approach
for SOA.
Similarly, Dragoni et al. come to the conclusion that Microservices are “the
second iteration” of the SOC and SOA concepts with the aim to strip away
complexity and to focus on the development of simple and lightweight services [2].
While SOA addresses the enterprise workflow level, Microservices aim for a
smaller application-level scope. Other apparent differences for them include
independent bounded contexts with small services, the high degree of automation,
the organizational aspects related to DevOps teams (“you build it, you run it”),
the preference of choreography over orchestration, and a potentially higher degree
of technological heterogeneity.
Xiao et al. describe Microservices and SOA as allies that should be leveraged
to enable a bi-modal or two-speed IT in the digital age [18]. Their comparison
highlights autonomy, size, and the development and deployment cycle as main
differences. Additionally, decentralized governance and different communication
and message exchange protocols are pointed out. Apart from these, a lot of
SOA Patterns for Microservice-Based Systems 11
similarities are mentioned, especially the focus on organizing services around
business capabilities and service-oriented principles like statelessness, reuse, and
abstraction.
Salah et al. take a broad evolutionary perspective and compare the client/server
architecture, mobile agents architecture, SOA, and Microservices [17]. They de-
scribe a direct line of evolution from client/server to SOA and from there on
further down to Microservices. Main differences for them include high service
independence and decentralization, fine-grained services with bounded contexts,
fast software delivery, and lightweight communication via “dumb pipes” and no
middleware focus.
Lastly, the most “revolutionary” perspective is taken by Richards [14]. He
argues that SOA focuses on large, complex, enterprise-wide systems whereas
Microservices target small to medium web-based applications. Likewise, SOA
follows a “share-as-much-as-possible” approach while Microservices are based on
the “share-as-little-as-possible” principle. For Richards, Microservices are located
on the other side of the service-oriented spectrum as SOA. He focuses very
much on differences, not so much on commonalities. Other notable Microservices
differences presented are the low degree of centralization and standardization, a
very small number of lightweight communication protocols as opposed to SOA’s
protocol-agnostic heterogeneous interoperability provided by an ESB, and the
focus on bounded contexts as opposed to SOA’s focus on abstraction and business
functionality reuse.
To the best of our knowledge, there are currently no publications solely on the
topic of SOA patterns and Microservices. There are some publications concerning
patterns specifically tailored for Microservices [9, 10, 15], but the authors do
not really explain the relation to SOA. Moreover, several of these Microservices
patterns are not new and have been used in other contexts before (including
SOA). A detailed analysis would be interesting, but goes beyond the scope of
this paper.
3 Scope and Research Method
All comparisons in Section 2 focus on design characteristics, principles, or applied
technologies. A different approach would be to analyze existing SOA patterns for
applicability to a Microservices context. This architecture- and design-centric
perspective has the positive side-effect of providing a list of candidate patterns
potentially usable in a Microservice-Based System. We use Erl’s [4, 5] and Rotem-
Gal-Oz’s [16] books as sources for SOA patterns, as they are well established in
industry and academia and have minimal overlap. From literature (including the
publications in Section 2) we compiled the following list of Microservice-specific
principles.
• Bounded Context: fine-grained services according to Bounded Contexts [6]
• Decentralization: decentralization of control and management, low degree
of standardization, choreography over orchestration
12 Justus Bogner et al.
• Lightweight Communication: communication via RESTful APIs or light-
weight messaging (no ESB, no workflow engine, etc.), “dumb pipes”
• Single System: building a single Service-Based System of medium size
• Technological Heterogeneity: support of diverse programming languages,
databases, or used frameworks/libraries
With these criteria, we qualitatively analyzed the patterns in our 3 sources
and documented if the usage of a pattern violates the compiled characteristics.
Based on the violations, a pattern is categorized as fully applicable, partially
applicable (with certain limitations/modifications), or not applicable. Some
examples: The pattern Enterprise Inventory that provides architecture, stan-
dardization, and governance boundaries for every service within the enterprise is
categorized as not applicable, because this violates the Microservice principles
Decentralization, Single System, and Technological Heterogeneity. Likewise, the
pattern Protocol Bridging that enables communication between consumers and
providers that rely on different protocols is rated partially applicable, because
this is usually not necessary in a Microservice-Based System. The principles
Lightweight Communication and Single System could be violated by this. How-
ever, there could be rare evolutionary use cases where this pattern could indeed
be applied, e.g. when a service that uses message-based communication (e.g.
AMQP) should interact with one that relies on RESTful HTTP because of new
or changed requirements. Lastly, the pattern Lightweight Endpoint where a series
of fine-grained capabilities replaces a single coarse-grained capability to avoid
wasteful data exchange and consumer-side processing is categorized as fully
applicable. It violates none of the defined Microservices principles and is in fact
in line with the core values of this architectural style.
The aggregated results of all these pattern categorizations are then used for
further analysis and to provide answers to the following research questions:
RQ1: To what degree are SOA design patterns applicable to Microservices?
RQ2: What pattern categories are the most or least applicable?
RQ3: What are the most frequent Microservice-specific properties violated
by not or partially applicable patterns?
4 Results: Applicability of SOA Patterns to Microservices
Erl’s catalog comprises a total of 92 patterns (85 SOA patterns [4] and 7
REST-inspired patterns [5]). These patterns are structured into 5 different
categories, namely Service Inventory Design Patterns (24 patterns), Service
Design Patterns (31 patterns), Service Composition Design Patterns (23 patterns),
Compound Design Patterns (7 patterns), and REST-Inspired Patterns (7 patterns).
Rotem-Gal-Oz’s more compact book presents 26 patterns [16] in 6 categories,
namely Foundation Structural Patterns (5 patterns), Performance, Scalability,
and Availability Patterns (6 patterns), Security and Manageability Patterns (5
patterns), Message Exchange Patterns (4 patterns), Service Consumer Patterns
(3 patterns), and Service Integration Patterns (3 patterns). So all in all, we
SOA Patterns for Microservice-Based Systems 13
analyzed 118 SOA patterns with very few duplicates (examples being Service Bus
or Orchestration).3
60
54
50
40
Fully applicable
30 26 Partially applicable
20 Not applicable
20
12
10
4
2
0
Erl Rotem-Gal-Oz
Fig. 1. SOA Pattern Applicability to Microservices
From Erl’s 92 patterns, 54 (59%) patterns were found to be fully applicable,
26 (28%) to be partially applicable and only 12 (13%) were categorized as not
applicable. That means that 87% of the patterns were estimated at least partially
applicable in a Microservices context. For Rotem-Gal-Oz’s smaller catalog, the
numbers were even higher: Of the 26 patterns, 20 (77%) were categorized as fully
applicable, 4 (15%) as partially applicable, and only 2 (8%) were deemed
not applicable. So 92% of these patterns were found to be at least partially
applicable for Microservices. When combining both catalogs (118 patterns), this
accounts for 74 (63%) fully applicable, 30 (25%) partially applicable, and
14 (12%) not applicable patterns (see Fig. 1).
When looking at Erl’s 5 pattern categories, an immediate observation is that all
of the 7 REST-Inspired Patterns are fully applicable, which seems understandable
in light of Microservice-related communication preferences. Furthermore, 22 of 31
Service Design Patterns (71%) and 15 of 23 Service Composition Design Patterns
(65%) were fully applicable, which makes these two categories also very useful
design sources when building Microservice-Based Systems. The 7 Compound
Design Patterns were the least applicable category with 0 fully and only 4
partially applicable patterns (57%). This can be explained with the complexity
and centralized nature of these patterns. For Rotem-Gal-Oz’s 6 categories, both
Message Exchange Patterns and Service Consumer Patterns are 100% fully
applicable. Moreover, Performance, Scalability, and Availability Patterns with
83% and Security and Manageability Patterns with 80% fully applicable patterns
3
For details see: https://github.com/xJREB/research-soa-patterns-for-microservices
14 Justus Bogner et al.
are mentionable. All in all, the categories here consisted of fewer patterns, which
makes it harder to compare them with Erl’s.
30 28
25
20 19
Decentralization
Single System
15
Bounded Context
11
Lightweight Communication
10
6 6 Technological Heterogeneity
5 4
2
1
0 0
0
Erl Rotem-Gal-Oz
Fig. 2. Violated Microservice-related Principles of Not Fully Applicable SOA Patterns
When analyzing the most frequent causes why patterns were not or only
partially applicable (see Fig. 2), the Decentralization characteristic was the
most violated one (42% of all violations for Erl, 55% for Rotem-Gal-Oz). After
that, Single System (29%) and Bounded Context (17%) were the next
frequent violations in Erl’s catalog, with Lightweight Communication only
accounting for 9%. Interestingly, Technological Heterogeneity was violated
only twice by Erl’s patterns (Enterprise Inventory and Domain Inventory) and
in Rotem-Gal-Oz’s catalog only by one single pattern (Service Host). This can
be explained with the technology-agnostic form of design patterns. Moreover,
SOA systems are no strangers to diversity, so even an increase in technological
heterogeneity in a Microservice-Based System will not invalidate the vast majority
of patterns.
5 Summary and Conclusion
Based on 5 derived Microservices principles, we qualitatively analyzed the appli-
cability of SOA design patterns for the context of Microservices. Of 118 patterns,
74 (63%) were found to be fully applicable, 30 (25%) partially applicable,
and 14 (12%) not applicable. The most violated principles were Decentralization
and Single System while Technological Heterogeneity had very little impact. The
findings suggest that from a pattern-based perspective, Microservices and SOA
have some small distinct areas of differences, but share a large set of design-related
commonalities.
SOA Patterns for Microservice-Based Systems 15
However, since descriptions of Microservices (unlike descriptions of “pure”
architectural styles) cover other areas than architecture and design (e.g. process,
organization, development, operations, etc.), differences in these other areas may
be much more apparent. Since a definition of SOA as an architectural style should
not define or restrict these areas, this seems to support the view of [19] that
Microservices can be seen as a specific development and deployment approach
for SOA.
Limitations of our work are the qualitative nature of the comparison. Results
precision could have benefited greatly from a more rigorous method to rate
patterns and state that a principle was violated. Similarly, an external validation
of the pattern ratings by experts in the field of Microservices would have improved
the results further. This would have reduced the possibility of subjective bias and
increased the reproducibility of the study. Follow-up research could include such
methods as well as trying to identify SOA patterns in existing Microservice-Based
Systems. Lastly, it will be interesting to analyze the currently forming catalog
of Microservices patterns to check for either “SOA backwards compatibility” or
existing SOA pattern ancestors.
Acknowledgments This research was partially funded by the Ministry of
Science of Baden-Württemberg, Germany, for the Doctoral Program “Services
Computing” (http://www.services-computing.de/?lang=en).
References
1. Alexander, C., Ishikawa, S., Silverstein, M., i Ramió, J.R., Jacobson, M., Fiksdahl-
King, I.: A Pattern Language. Gustavo Gili (1977)
2. Dragoni, N., Giallorenzo, S., Lafuente, A.L., Mazzara, M., Montesi, F., Mustafin, R.,
Safina, L.: Microservices: Yesterday, Today, and Tomorrow. In: Present and Ulterior
Software Engineering, pp. 195–216. Springer International Publishing, Cham (2017)
3. Erl, T.: Service-Oriented Architecture: Concepts, Technology, and Design. Prentice
Hall PTR, Upper Saddle River, NJ, USA (2005)
4. Erl, T.: SOA Design Patterns. Pearson Education, Boston, MA, USA (2009)
5. Erl, T., Carlyle, B., Pautasso, C., Balasubramanian, R.: SOA with REST: Principles,
Patterns & Constraints for Building Enterprise Solutions with REST. The Prentice
Hall Service Technology Series from Thomas Erl, Pearson Education (2012)
6. Evans, E.: Domain-driven Design: Tackling Complexity in the Heart of Software.
Addison-Wesley (2004)
7. Fowler, M.: Microservices Resource Guide (2015), http://martinfowler.com/
microservices
8. Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns: Elements of
Reusable Object-Oriented Software. Addison-Wesley, Boston, MA, USA (1994)
9. Gupta, A.: Microservice Design Patterns (2015), http://blog.arungupta.me/
microservice-design-patterns
10. Krause, L.: Microservices: Patterns and Applications. Lucas Krause (2015)
11. MacLennan, E., Van Belle, J.P.: Factors affecting the organizational adoption of
service-oriented architecture (SOA). Information Systems and e-Business Manage-
ment 12(1), 71–100 (2014)
16 Justus Bogner et al.
12. Newman, S.: Building Microservices: Designing Fine-Grained Systems. O’Reilly
Media, 1st edn. (2015)
13. Papazoglou, M.P.: Service-oriented computing: concepts, characteristics and di-
rections. In: Proceedings of the 7th International Conference on Properties and
Applications of Dielectric Materials (Cat. No.03CH37417). pp. 3–12. IEEE Comput.
Soc (2003)
14. Richards, M.: Microservices vs. Service-Oriented Architecture. O’Reilly Media,
Sebastopol, CA (2016)
15. Richardson, C.: Microservices Patterns. Manning Publications (2018)
16. Rotem-Gal-Oz, A.: SOA Patterns. Manning, Shelter Island, NY (2012)
17. Salah, T., Jamal Zemerly, M., Chan Yeob Yeun, Al-Qutayri, M., Al-Hammadi, Y.:
The evolution of distributed systems towards microservices architecture. In: 2016
11th International Conference for Internet Technology and Secured Transactions
(ICITST). pp. 318–325. IEEE (2016)
18. Xiao, Z., Wijegunaratne, I., Qiang, X.: Reflections on SOA and Microservices. In:
2016 4th International Conference on Enterprise Systems (ES). pp. 60–67. IEEE
(2016)
19. Zimmermann, O.: Microservices tenets. Computer Science - Research and Develop-
ment 32(3-4), 301–310 (2017)