Presentation about introduction to Microservices

1. Microservices
The next step in architecture?
mei ’18

2. Agenda
• 16:00 – 16:30 Walk-in
• 16:30 – 17:15 Microservices: Roger
• 17:15 – 18:30 Vision and patterns MuleSoft
• 18:30 – 19:30 Dinner
• 19:30 – 20:30 Handson MuleSoft
mei ’18 2

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

10. Drivers
mei ’18 10

11. mei ’18 11
Agility
Safety
Release Speed
ScalabilityExperimenting
Flexibility
Replaceability
Microservices
Drivers
Decentralized
Governance

12. What makes a good size?
mei ’18 12

13. “Size” of a Microservice
• LOC?
• One “entity”?
• Team size?
• API size?
• Deployment time?
• Sam Newman “small enough and no smaller”
mei ’18 13

14. Decomposition
mei ’18 14
Business
Capability
DDD
Bounded
Context
Ubiquitous
Language
Event
Storming

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

18. Microservices “vs” SOA
mei ’18 18

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

20. Microservices Ecosystem
mei ’18 20

21. mei ’18 21
Microservice
Ecosystem
Service
(micro)
Process
Tools
CultureOrganisation
Solution
(macro)

22. Microservices
Platform
SOA
• “Small” services
• Domain Drive Design
• Webservices
• CQRS
DevOps
• CI / CD
• Monitoring
• Automatic testing
• Deployments
Agile /
Organisation
• Small teams
• Small increments
• Fast delivery
• Culture
Cloud
• Containerization
• Horizontal scaling
• Deployments
Event Driven
Architecture
• Loose coupling
• Event sourcing
API Management
• REST API
• Routing
• API Gateway
• Orchestration
• Transformation
mei ’18 22

23. Design Patterns
mei ’18 23

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

25. mei ’18 25
Source: http://microservices.io/patterns
Chris Richardson

26. Anti patterns
mei ’18 26

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

31. Anemic Service
• Services designed solely encapsulate data, with logic in other
layer
mei ’18 31

32. Unjustified re-use
• Extremely generic utility functions to reduce logic redundancy
• Leads to more complexity
mei ’18 32

33. Domain-last approach
• Major driver for organisational structure is roles and technical
capabilities, not business domain
mei ’18 33

34. Patterns
• Decentralized domain focused cells with maximum authority
over all aspects of a set of capabilities
• Cross functional
teams
mei ’18 34

35. Sizing Patterns (small -> large)
• FaaS (Function as a Service, small, async, serverless)
• microSOA (small, self hosted containerized services, close)
• Distributed Domain-Driven Design (bounded context)
• Self-contained Systems (UI+DB)
• Monolith (1 application is ok)
mei ’18 35

36. Tooling
mei ’18 36
Hystrix
Eventuate
Kubernetes
ZooKeeper
NodeJs
Service
Mesh
Eureka
Istio
Kafka
Lagom
OpenWhisk
Zipkin
Zuul

37. mei ’18 37

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

41. mei ’18 41

42. Reference Architecture
mei ’18 42

43. mei ’18 43

44. Pace Layer Model
mei ’18 44

45. Microservices Conference
Berlin 2018
mei ’18 45

46. mei ’18 46

47. • Architecture /design / tools&framework sessions
• Workshops
• Service Mesh
• Micro frontends
• Patterns (i.e. Sagas)
• Kubernetes
mei ’18 47

48. What’s next
mei ’18 48

49. • Microservices Maturity Model
• Consumer Driven Contracts
• Frontend modularisation needs innovation
• Organisational structures (team sizes)
• Event Sourcing
• Handling data (sharing / transactions (Sagas))
• Security (OpenID, OAuth2, JWT)
• Serverless (AWSLambda, functions, deployment model)
mei ’18 49

50. Takeaways
mei ’18 50

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

52. Backup slides
mei ’18 52

53. Resources
• https://martinfowler.com/microservices/
• http://microservices.io/patterns/microservices.html
• http://api.co/msabook
mei ’18 53

54. Books
mei ’18 54

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

62. Infrastructure automation
• CD/CI
• Automated test
• Automated deployments
mei ’18 62

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

65. API Gateway vs Service Mesh
mei ’18 65

66. Monolith sv Microservices
mei ’18 66

67. 1. Hardware
Bare metal, AWS EC2, Google Cloud Platform,
Azure.
Resource abstraction: Docker, Apache Mesos
Configuration management, Provisioning,
monitoring and logging
2. Communication
Network, DNS, service discovery, service
load balancing, messaging
3. Application platform
Development tools, test/package/build/release,
deployment pipeline, logging and monitoring
4. Microservices
Microservice itself and corresponding
configurations
mei ’18 67
Layer 4: Microservices
Layer 3: Application platform
Layer 2: Communication
Layer 1: Hardware

68. mei ’18 68

69. mei ’18 69

70. mei ’18 70

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