This document discusses microservices architecture and how it enables agility. It defines microservices as small, independent units that can be developed and deployed autonomously. The document argues that microservices align with the principles of the Agile Manifesto by allowing teams to work independently, facilitating continuous delivery, and making the architecture adaptable to change. Some benefits outlined are improved scalability, maintainability, and ability to replace services easily. The conclusion is that by structuring an organization and software architecture around microservices, greater agility can be achieved compared to a monolithic architecture.

1. Microservices:
Architecture for Agile
Software Development
Eberhard Wolff
Fellow, innoQ
@ewolff

2. http://microservices-buch.de/

3. Code

4. Microservice
Definition

5. Server
Server
Microservices:
Definition
> Small
> Independent deployment units
> Any technology
> Any infrastructure
> UI + Logic
Micro
Service
Micro
Service

6. Components Collaborate
Micro
Service
Micro
Service
Link
Data Replication
REST
Messaging

7. Online Shop
Order
Catalog
Search
Billing
Customer
HTML /
HTTP

8. Online Shop
Elasticsearch
Spring Batch
Oracle
Spring MVC
MongoDB
Order
Catalog
Search
Billing

9. Agility

10. Agile Manifesto
> Individuals and Interaction
> Over processes and tools
> Working Software
> Over comprehensive documentation
> Customer Collaboration
> Over contract negotation
> Responding to change
> Over following a plan

11. Agile Manifesto:
Individuals and
Interactions

12. Software Architecture
& Individuals

13. Software Architecture
& Individuals
Unrelated?

14. Does Your
Architecture Take
Individuals Into
Account?

15. Conway‘s Law
Architecture
copies
communication structures
of the organization

16. Conway‘s Law: Impact
Architecture
and
communication structures
in the organization
are the same thing.

17. Conway’s Law as a
Limit
> Organization drives architecture
> I.e. GUI, logic & database team
> Three technical artifacts

18. GUI
Logic
DB
E Commerce
Shop
Change
Order
Process!

19. time
DB
Team Sprint
Logic
Team Sprint
GUI
Team Sprint
3 sprints

20. Deployment Monolith
Deployment Monolith
Stories
Technical Coordination
Coordinating Releases

21. Order
Billing
Search
Order
Search
Billing
Team for each business feature
Let architecture drive the organization

22. Deployment Monolith
+ Conway’s Law
Deployment Monolith
Stories
Technical Coordination
Coordinating Releases
StoriesStories
Order Billing Search

23. Microservices +
Conway’s Law
> Let architecture drive the organization
> Team for each Microservice
> Team responsible for business features
> Ideal: Independent features

24. Order
Billing
Search
Order
Search
Billing
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

25. Microservices
Microservice
Stories
Technical
Coordination
Microservice
Stories
Technical
Coordination
Microservice
Stories
Technical
Coordination
Order Billing Search
Release Release Release

26. How to scale agile?

27. Use a process to scale
agile?

28. Individuals & interaction
over
processes and tools

29. Define architecture
to limit
communication
needs

30. One team can build and
deploy features
independently!

31. Team must be responsible
for a sensible set of
functionality

32. Less Technical
Coordination

33. Agile Manifesto:
Working Software

34. Scrum
> PSI
> Potentially shippable increment
> Why?

35. Principles behind the
Agile Manifesto
Our highest priority is
to satisfy the customer
through early and
continuous delivery
of valuable software.

36. Potentially
Shippable
Increment
Continuous
Delivery

37. Monolith
ECommerce
System
3rd party
systems
Database

38. Continuous Delivery:
Build Pipeline
Commit
Stage
Automated
Acceptance
Testing
Automated
Capacity
Testing
Manual
Explorative
Testing
Release
ECommerce
System

39. Build Pipeline:
Complex Infrastructure
> Huge database
> 3rd party integration

40. Build Pipeline:
Slow Feedback
> Slow feedback
> Test everything for each commit
> Huge deployment unit
> Deployment slow

41. Monolith:
Deployment
> Huge deployment
> Risky
> Hard to mitigate risk
> Blue / Green: Create a separate
environment
> Canary: Deploy to one server first

42. Microservices
ECommerce
System
3rd party
systems
Database
Order
Catalog
Billing
Search

43. Commit
Stage
Automated
Acceptance
Testing
Automated
Capacity
Testing
Manual
Explorative
Testing
Release
Commit
Stage
Automated
Acceptance
Testing
Automated
Capacity
Testing
Manual
Explorative
Testing
Release
Commit
Stage
Automated
Acceptance
Testing
Automated
Capacity
Testing
Manual
Explorative
Testing
Release
Order
Billing
Customer

44. Build Pipeline for
Microservices
> Independent deployment
> Build pipeline per Microservice
> Small
> Easier to set up
> Less features (3rd party systems)
> Faster Feedback: Less tests

45. Microservice:
Deployment
> Small deployment
> Less risky
> Other Microservices resilient to failing
microservice
> Easy to create new environments
> E.g. for Blue / Green or Canary

46. Quick Deployments
Time
Size & Risk
Manual
Deployment
Pipeline
Continuous
Delivery
Pipeline
Monolith
Microservices

47. Potentially shippable
increment?

48. SHIP!!!

49. Agile Manifesto:
Customer
Collaboration

50. Customer
Collaboration &
Architecture?

51. Customer
Collaboration &
Architecture?
Not sure.

52. Microservices &
Departments
StoriesStories Stories
Customer Billing
Order
Process
Product
Owner
Product
Owner
Product
Owner
Department Department Department

53. Microservices &
Departments
> Ideal: One team per department
> Ideal: Change local to one team /
Microservice
> Otherwise: Coordination needed

54. Customer should own
Microservice

55. Agile Manifesto:
Responding to change

56. Monoliths
> Architecture rot
> …not maintainable any more
> …and can’t be rewritten / replaced

57. Deployment Monolith
> Cyclic dependency
> …because the IDE suggested some class
> Might not even be noticed
Module
Class
Module
Class
Class Class

58. Microservices
> Need to use the API
> Different team
> More effort - will think about it
> Rot less likely
Microservice
Class
Microservice
Class
Class Class

59. Global Refactorings?
> Move code from service to service
> Might be a port to a different language
> Separate in a new service
> Harder than in a Deployment Monolith

60. Microservices
> Small
> Easy to change
> Architectural problems in Microservice unlikely
> Can be replaced
Microservice
Class
Class

61. Microservices
– Easy to Recylce

62. Conclusion

63. Conclusion:
Microservices & Agility
> Individuals over tools
> Architecture drives organization
> Scale by architecture not process
> Working software
> Actually ship software
> Continuous Delivery

64. Conclusion:
Microservices & Agility
> Customer collaboration
> Customer should own services
> i.e. organization beyond the project =
architecture

65. Conclusion:
Microservices & Agility
> Responding to change
> Individual Microservices small
> Easy to change
> …and replace
> Unwanted dependencies won’t sneak in
> But: Global refactoring hard, too

66. Meta-Conclusion

67. How To Think About
Architecture
> Process has an impact on architecture
> Software architecture & organization are the
same
> Build recyclable software!

68. Microservice > Agile
Achitecture
Strong Modularization
Scaled Agile Architecture
Sustainable development
speed
Replaceable Services
Continuous Delivery
Choose best technology
for job!
Handle Legacy more efficient
Independent Scaling
Robustness

69. Microservice Training
> Stefan Tilkov / Eberhard Wolff
> Frankfurt / Main
> 26.-27.10.2015
> https://www.innoq.com/de/trainings/
microservices-training/