This document discusses microservices and their advantages and disadvantages. Microservices are small, independent units that work together to form an application. They allow for independent deployment and use of different technologies. While this improves scalability and agility, it also introduces challenges around distributed systems, refactoring code between services, and operating at scale. The key is to start with a functional architecture and limit communication between services.

1. Microservices –
All is Small, All is Well?
Eberhard Wolff
Freelancer

2. Eberhard Wolff - @ewolff
Leseprobe:
http://bit.ly/CD-Buch

3. Eberhard Wolff - @ewolff
Microservice
Definition

4. Eberhard Wolff - @ewolff
Microservices: Definition
• Small
• Independent deployment units
• i.e. processes / VM
• Including GUI
• Any technology
• Any infrastructure
Micro
Service
Server
Micro
Service
Server

5. Eberhard Wolff - @ewolff
Components Collaborate
Micro-
service
Micro-
service
Link
Data Replication
REST
Messaging

6. Eberhard Wolff - @ewolff
Online Shop
Order
Catalog
Search
Billing
Customer
HTML /
HTTP

7. Eberhard Wolff - @ewolff
Microservice
to scale Agile

8. Eberhard Wolff - @ewolff
Define
architecture to
limit
communication

9. Eberhard Wolff - @ewolff
Microservice
Conway’s Law

10. Eberhard Wolff - @ewolff
Conway‘s Law
Architecture
copies
communication structures
of the organization

11. Eberhard Wolff - @ewolff
Order Billing Search Catalog
Order CatalogSearchBilling
Team can deploy without integration
Changes can be deployed independently & quickly
Strong & enforced modularization
Technology stack per Microservice
One or many Microservices per Team
Synergy Microservices / Conway’s Law

12. Eberhard Wolff - @ewolff
One team can
build and
deploy features
independently!

13. Eberhard Wolff - @ewolff
Team must be
responsible for
a sensible set
of functionality

14. Eberhard Wolff - @ewolff
Microservice
Bounded
Context

15. Eberhard Wolff - @ewolff
DDD
• Domain Driven Design
• By Eric Evans
• UBIQUITOUS LANGUAGE
• Code / database / user should use
the same terms for the domain
model

16. Eberhard Wolff - @ewolff
Bounded Context
• Domain model is only valid for one
context
• There is no universal data model!
• See all failed SOA attempts

17. Eberhard Wolff - @ewolff
Order Shipping Billing
Customer
Loyalty
program #
Customer
Shipping
address
Customer
Credit
Card #

18. Eberhard Wolff - @ewolff
Bounded Context &
Microservice
• Microservice = Bounded Context
• Changes: local
• Even for data model
• Independent development
• Relationship = team collaboration

19. Eberhard Wolff - @ewolff
Sustainable
Development

20. Eberhard Wolff - @ewolff
Monoliths
• Architecture rot
• …not maintainable any more
• …and can’t be rewritten / replaced

21. Eberhard Wolff - @ewolff
Microservices
• Distributed system of small units
• Architecture violations harder
• Small units
• Easy to replace

22. Eberhard Wolff - @ewolff
Free choice of
technology

23. Eberhard Wolff - @ewolff
Online Shop
Elasticsearch
Spring Batch
Oracle
Spring MVC
MongoDB
Order
Catalog
Search
Billing

24. Eberhard Wolff - @ewolff
Free Choice of Technology
• Use the best tool for the job
• Very hard with a monolith
• Option
• Can increase motivation

25. Eberhard Wolff - @ewolff
Refactoring &
Code Reuse

26. Eberhard Wolff - @ewolff
Code Reuse
• Reuse across technology stacks hard
• Code dependencies are evil!
• Deployment dependency
• No more independent deployment
• Update hell
• Avoid code reuse!
• Or make it Open Source projects (Netflix)
• Service reuse is fine

27. Eberhard Wolff - @ewolff
Code Reuse
is an issue,
not a goal

28. Eberhard Wolff - @ewolff
Global Refactorings?
• Move code from service to service
• Might be a port to a different
language
• Separate in a new service?
• More services = more complex
• Hard

29. Eberhard Wolff - @ewolff
Functional Architecture
• Teams should be independent
• i.e. one team = one functionality
• Otherwise: Coordination hard
• Functional architecture much more
important

30. Eberhard Wolff - @ewolff
Refactoring &
Code Reuse
Individual
Technology Stacks

31. Eberhard Wolff - @ewolff
Refactoring hard
Functional
architecture much
more important

32. Eberhard Wolff - @ewolff
Need to get
architecture
right first time
Architecture
evolves

33. Eberhard Wolff - @ewolff
Start BIG
• Won’t have too much code at the
start anyway
• Refactoring easier
• Can build architecture as you go
• Let the functional architecture
grow!

34. Eberhard Wolff - @ewolff
Distributed
System

35. Eberhard Wolff - @ewolff
1st Law of Distributed Objects
• Don’t Distribute Your Objects!
• Too much remote communication &
overhead
• Lesson learned from CORBA etc
• Microservice should include a GUI
• http://martinfowler.com/bliki/
FirstLaw.html

36. Eberhard Wolff - @ewolff
Request
Response
Processing
Latency Round Trip:
0,2-0,5 ms
= 600.000-1.500.000
instructions@3GHz

37. Eberhard Wolff - @ewolff
1st Law of Distributed Objects &
Microservices
• Small Microservices mean a lot of
communication
• Violate the 1st Law
• Seems to work, though
• http://martinfowler.com/articles/
distributed-objects-
microservices.html

38. Eberhard Wolff - @ewolff
Too small =
too much
communication

39. Eberhard Wolff - @ewolff
Resilience
• Failures must not propagate
• Timeouts
• Bulkheads
• Circuit Breaker
• Michael T. Nygard: Release It!
• Implementation: Hystrix (Netflix)
• More robust than monoliths!

40. Eberhard Wolff - @ewolff
Authentication & Authorization
• Centralized authentication
• Service must authorize user
• More complex than monolith
• E.g. OAuth2

41. Eberhard Wolff - @ewolff
Deploy &
Operate?

42. Eberhard Wolff - @ewolff
Component Model
• No restriction on language etc
• Individual processes
• + infrastructure (database etc)
• JARs, WARs, EARs: No good fit
• Standardized Monitoring
• Standardized Logging

43. Eberhard Wolff - @ewolff
Possible Component Models
• Virtual machine
• Docker container
• Installable software (RPM, deb)
• + deployment / config scripts

44. Eberhard Wolff - @ewolff
Operation
• Common standards must be
enforced
• Templates simplify creating new
Microservices
• …avoid too large Microservices
• …and support common standards

45. Eberhard Wolff - @ewolff
Conclusion

46. Eberhard Wolff - @ewolff
Conclusion: Microservices
• Microservices are a new way of
modularization
• More technological freedom
• Architecture to enable scaling agile
• Easier, faster and less risky
deployment

47. Eberhard Wolff - @ewolff
Issues
• Refactoring and reuse hard
• Distributed systems
• More sources of failures

48. Eberhard Wolff - @ewolff
Use If…
• Time to market is important
• Sustained development speed
• Large enough project

49. Eberhard Wolff - @ewolff
Don’t Use If…
• Infrastructure complexity cannot be
handled
• Architectural complexity cannot be
handled

50. Eberhard Wolff - @ewolff
Thank You!