3. Microservices
• Definition
• Drivers
• Sizing
• MS vs SOA
• MS Ecosystem
• Decomposition
• Patterns and Anti-Patterns
• Frameworks and tooling
• Reference Architecture
• Microservices Conference Berlin 2018
• Takeaways
mei ’18 3
4. What is a Microservice ?
mei ’18 4
Resilient
Business
Capability
Container
DevOps
Loose
Coupling
Strong
Cohesion
Polyglot
Bounded
Context
Scaling
EDA
API
Cloud
5. History
• A group of architects cam together in Venice 2011 to discuss
the common architectural styles recently exploring
• In May 2012, the same group decided on “Microservices” as
the most appropriate name.
mei ’18 5
6. Wat is a Microservice Architecture?
The microservice architectural style is an approach to developing a
single application as a suite of small services, each running in its
own process and communicating with lightweight mechanisms, often
an HTTP resource API.
These services are built around business
capabilities and independently deployable by fully automated
deployment machinery. There is a bare minimum of centralized
management of these services, which may be written in different
programming languages and use different data storage
technologies.
-- James Lewis and Martin Fowler
mei ’18 6
7. “Microservices are small autonomous services that work
together” – Sam Newman
“Loosely coupled service-oriented architecture with bounded
contexts” – Adrian Cockcroft
“A microservice is an independently deployable component of
bounded scope that supports interoperability through message-
based communication.
Microservice architecture is a style of engineering highly
automated, evolvable software systems made up of capability-
aligned microservices.”
mei ’18 7
8. Characteristics
• Componentization via Services
• Organized around Business Capabilities
• Products not Projects
• Smart endpoints and dumb pipes
• Decentralized Governance
• Decentralized Data Management
• Infrastructure Automation
• Design for failure
• Evolutionary Design Martin Fowler
mei ’18 8
9. Bounded Context / scope
mei ’18 9
Microservice
Framework /
Language
Database
REST REST
API
Bounded Context / scope
Microservice
Framework /
Language
Database
API
Bounded Context / scope
Microservice
Framework /
Language
Database
API
Domain Model Domain Model
Domain Model
15. Example (DDD)
mei ’18 15
Entities
Aggregates
Object
Values
Business
Capabilities
Ubiquitous language
16. Interesting DDD methods
• Event storming
(See https://www.infoq.com/news/2014/06/dddx-brandolini-
eventstorming)
• Domain Story telling
(See https://www.infoq.com/news/2018/02/storytelling-domain-
contexts)
mei ’18 16
17. Data
• What is the data representing in a particular domain context?
Boundaries: DDD Entities, Value objects and Aggregates.
i.e. Book in seach context is Title
and in Order is titles+copies, so
entities mean different things !
• Transaction boundaries: smallest
unit of atomicity that you need
mei ’18 17
19. Microservices “vs” SOA
mei ’18 19
SOA Microservices
Layering (utility, entity, task layers) No layering (on service level)
CDM Domain Models
http/soap, XML, WSDL , XSD REST/http, JSON, Polyglot
Composite orchestrations Event driven architectures
ESB Service Mesh
Value chain and business model is
changing the entire business process
Value chain and business model is about
efficiencies, small teams and DevOps
practices while eliminating cilos.
Focus on reusability Focus on usability and speed
Loose Coupling Loose Coupling
Dividing problem domain into services Dividing problem domain into services
24. Patterns and Anti-Patterns
Anti-Patterns
• Distributed Monolith (hype driven architecture)
• Decoupling Illusion (technical- does not match business separation)
• Micro Platform (standardization internal runtime aspects)
• Entity Service (too wide business entities)
• Anemic Service (solely data encapsulation)
• Unjustifed re-use (extremely generic utility functions)
• Domain-last approach (org structure around technical capabilities, not
business domain)
mei ’18 24
27. Distributed Monolith
• Microservices gone bad
• System made up of arbitrarily sized, tightly coupled modules
communicating over network interfaces
(i.e. everything is DCOM object)
mei ’18 27
28. Decoupling Illusion
mei ’18 28
• Functional changes required by different stakeholders require changes
to overlapping services
• Too much focus on re-use
29. Micro platform
• Standardization of service internal runtime aspects
• (Perceived ) increased efficiency, but practically shared
dependencies on details, which increases the need for
communication
mei ’18 29
30. Entity Service
• Service boundaries are chosen to encapsulate “wide” business
entities
• Perceived benefit of canonical models
mei ’18 30
38. Type of tools
• Development (KumuluzEE , Springboot, NodeJs, Scala, Akka,
Play framework, Lagom, Eventuate)
• API (OpenAPI, WADL, Blueprint, RAML)
• Database (Cassandra, Datomic, Mongo, Neo4J)
• Gateways (Netflix Zuul, Jboss Netty, Twitter Finagle)
• Monitoring (Twitter Zipkin, Netflix Hystrix)
• Container management(Docker, Kubernetes, Mesos)
• Communication (http, Kafka)
• Service Mesh (HAProxy, traefik, NGINX, Istio, Linkerd)
mei ’18 38
39. Service Mesh
mei ’18 39
No centralized integration/ESB layer but a set of (composite and
atomic) microservices. Service-to-service communication at the
microservices level.
40. Microservices toolsheet
• Sheet with reference architecture concepts and the
tools/frameworks/products available to fill in those concepts
• Feel free to contribute !
• https://docs.google.com/spreadsheets/d/1BAR2pZlaqNGAEAW
q7qDyKM7xYlt3uhoHAmlnsau0gdw
mei ’18 40
51. • Microservices is (still) not the holy grail !
• Don’t fall into trap of the anti-patterns
• Don’t fall into the trap of hype and available tools and
frameworks
• Microservices is no mainstream and commodity. Tools are not
always production ready
• Microservices architecture is NOT easy
• Define what you try to achieve
• Add it to your bag of architecture tools
mei ’18 51
55. Componentization via Services
A component is a unit of software that is independently
replaceable and upgradeable.
libraries are components that are linked into a program and
called using in-memory function calls
services are out-of-process components who communicate with
a mechanism such as a web service request, or remote procedure
call.
One main reason for using services as components (rather than
libraries) is that services are independently deployable.
mei ’18 55
56. Organized around Business Capabilities
Conway’s Law:
Any organization that designs a system (defined broadly) will
produce a design whose structure is a copy of the organization's
communication structure.
-- Melvyn Conway, 1967
mei ’18 56
57. Organized around Business Capabilities (2)
The microservice approach to division is different, splitting up
into services organized around business capability. (including
user-interface, persistant storage, and any external collaborations)
mei ’18 57
58. Products not Projects
• A team should own a product over its full lifetime
• “You build, you run it”
mei ’18 58
59. Smart endpoints and dumb pipes
• NO smart within communication mechanism (i.e. ESB)
• The smarts live in the end points that are producing and
consuming messages; in the services.
mei ’18 59
60. Decentralized Governance
• So less standardization on platforms and technology
( costs !)
• Use right tool for the job
mei ’18 60
61. Decentralized Data Management
• Conceptual model of the world will differ between systems ->
Bounded Context
• Polyglot Persistence
mei ’18 61
63. Design for Failure
• Applications must be able to tolerate failures of services
• Real-time monitoring (latency, throughput)
mei ’18 63
64. Evolutionary Design
• Service decomposition as tool for flexibility and change
• The key property of a component is the notion of independent
replacement and upgradeability
• If you find yourself repeatedly changing two services together,
that's a sign that they should be merged.
• Avoid versioning (be tolerant)
mei ’18 64
71. How to decompose?
• Business Capabilities
Guides the decomposition according to the way the business is
structured (Conway’s law)
• Domain-Driven Design (DDD) subdomain
Provides a suite of tools and methodologies to reason about the
underlying domain at hand. DDD Strategic Patterns guide the
creation of a context map which forms the foundation of the
decomposition
mei ’18 71