This document discusses microservices architecture and principles. It notes that a monolithic design leads to tight coupling that prevents independent scaling of modules. Microservices architecture aims to allow individual parts of a system to scale independently through looser coupling, autonomous services, and clear separation of concerns. Key principles for microservices include that they should be independently deployable, communicate through events and APIs, and that each service handle a specific task rather than representing an entire business entity.

1. μServices
`

4. 4

6. 33 000 000
page views per week
*Google Analytics v.17 2014
18 MINUTER
time spend per visit*
55% 45%

8. architecture
actual scale

9. A monolithic design is characterised by such a tight coupling
among modules that they have no independent existence.

10. challenges
• If one things fails, everything fails
• Can’t scale the database any further
• Expensive hardware
• Maintenance is scary
• Platinum support contract costs

11. We used to innovate to get ahead,
now We have to innovate just to keep up

12. goals
• Scaling individual parts of the system
• Lower hardware costs
• No platinum support
• Environment to quickly evaluate ideas
• No estimations, you are wrong anyway!

15. Top inspirations
• Larry Constantine - Structured Design (1960)
• Douglas McIlroy - Programs (1965)
• Ken Thompson - Unix (1973)
• Antony Williams - COM (1987)
• Udi Dahan - Autonomous Components (2004)
• Greg young - CQRS (2008)
• Fred George - Micro Services (2013)

16. –Ken Thompson, Unix Philosophy 1973
“Design programs to be connected to other
programs. “

17. –Mc Mcllroy, Unix Time-Sharing System Forward”. 1978
“Expect the output of every program to become
the input to another, as yet unknown, program.”

21. μServices architecture
service
subscribe to events
publish events
exposes http api
GET /profile
event stream
storage
reads and write to own storage

22. simple: easily understood or done

23. coupling is the degree to which each module relies on each one
of the other modules.

24. “μServices should be made as small as
possible, but not smaller”

25. Event Storming is a workshop format for quickly exploring
complex business domains.

26. services
events

29. where does online status come from?

33. “No μService should ever depend on another
being available”

34. autonomous: acting independently

35. “every view should be served by a single to one
μService”

36. {
name: bob ross,
text: …
portrait: {
url: /m/f.jpg,
isLiked: true,
}
isOnline: true
publicPhotos: …
privatePhotos: [{
url: /m/f.jpg
hasAccess: true
}]
}
GET /profile

38. where does the member live?

39. “No μService represents an business entity, but
rather serves an expect of one”

42. “An μService is the smallest consistency
boundary”

43. “μServices depends more on how the service fit into the
environment than on how they are designed internally.”

45. “Polyglot developers are a myth”

46. “Clarity is better than cleverness”

50. “An μService is the smallest part of the system
that can scale independently”

59. Shipping

61. “a μService is to μ to treat as a single product”

62. master
test
A
B

63. 0
1750
3500
5250
7000
13:00 13:15 13:30 13:45
v14.test.A.like.count v14.test.B.like.count

64. Summary

65. You've been a great audience!
already knew that when creating this slide