This document discusses the differences between service-oriented architecture (SOA) and microservices. It provides background on SOA and outlines some of its common characteristics, such as an emphasis on reuse, integration, and static design. Microservices are presented as taking a different approach, prioritizing managing change, composition over integration, and dynamic design. The document cautions against some anti-patterns that can emerge from an overly strict SOA approach, such as the distributed monolith and overreliance on enterprise service buses. It recommends that with microservices, domains and boundaries should drive design, canonical data models should be replaced with data views, metadata should be normalized and separated, and tools should be chosen pragmatically.

1. A Not SO(A) Trivial
Question!
Tareq Abedrabbo - MuCon
7/11/2017

2. Agenda
• Motivation
• SOA vs Microservices
• Design: anti-patterns and recommendations

3. About Me
• CEO/Consultant at OpenCredo
• Background
• SOA
• Spring-WS
• Microservices

4. Motivation

5. Background
• Some organisations are starting greenfield
microservices projects
• A few are trying to evolve preexisting platforms
• Many of these organisations have a SOA heritage

6. Microservices
=
SOA done right
?

7. What is SOA?

8. “A service has four properties according to one
of many definitions of SOA:
1.It logically represents a business activity with
a specified outcome.
2. It is self-contained.
3. It is a black box for its consumers.
4. It may consist of other underlying services.”

10. In reality SOA is
also….

11. ➡ An architectural style and design patterns
➡ Data models and patterns
➡ Technology and tools (ESBs, GUIs)
➡ A collection of specifications (SOAP, WS-*)

12. The SOA Heritage
✓ Approach & design
✓ Technology selection
✓ Team organisation

13. “Those who cannot remember the past are
condemned to repeat it”

14. SOA
vs
Microservices

15. Reuse
vs
Managing change

16. Vendor-driven view
vs
Broad system view

17. Integration
vs
Composition

18. Technical reuse
vs
Functional reuse

19. Static
vs
Dynamic

20. Organisational silos
vs
Collaborative teams

21. Design

22. Some anti-patterns

23. Example 1: The Distributed Monolith

24. Example 2: The Revenge of the ESB

25. • Using ESBs (or similar)
• Ignoring delivery guarantees/expecting transactions
• Excessive marshalling/unmarshalling
• Canonical data models/complex schema
• Distributed monolith (based on lack of understanding of
boundaries)
• Minilith (proliferation of technology, databases)
• lack of automation in infrastructure/testing

26. Recommendation
• No canonical data model (services do not need to
understand every aspect of the service)
• canonical data model vs schemas
• Separate data from meta-data
• Data orientated modelling/schemas
• Normalise meta-data

27. Some
Recommendations

28. Keep it domain-driven

29. Replace canonical data
models with data views

30. Normalise metadata
(and separate it from the rest of the data)

31. Use the right tool for
the job
(and use common sense!)

32. Thank you!