This document discusses the benefits of microservices architectures for simplifying complex systems. It outlines how Remmelt Pit transitioned an auction and listings website from a monolithic architecture to microservices. Some best practices they followed included defining strict contracts between loosely coupled services, thorough documentation, and avoiding polyglot approaches. Areas for improvement included starting smaller, better onboarding operations teams, and underestimating the needed culture change. Overall, microservices allow for improved scalability, flexibility to swap out services, and increased developer happiness and productivity when done right.

1. Remmelt Pit
Info.nl
remmelt@info.nl
@remmelt_

2. simplifying complexity
with microservices

4. conclusion

5. microservices
are awesome

7. since
2003

8. 12,000
auctions

13. 4,000,000
listings

14. ~1M unique
visitors/month

20. not maintainable

21. not agile

22. no fun

23. I like fun

24. enter
microservices

25. Loosely coupled
service oriented architecture
with bounded contexts
— Adrian Cockcroft

26. Loosely coupled
Services do not need to be updated at the same time

27. Loosely coupled
Services do not need to be updated at the same time
Bounded contexts
If you have to know too much about surrounding
services than you don't have a bounded context1
1
See Eric Evans, Domain Driven Design

28. µ?

30. what did we do right?
— define contracts and stick to them

31. what did we do right?
— define contracts and stick to them
— documentation of API

33. what did we do right?
— define contracts and stick to them
— documentation of API
— no polyglot from the start

34. what could we have done better?
— start small

35. what could we have done better?
— start small
— onboarding ops

36. Organizations which design
systems ... are constrained to
produce designs which are copies
of the communication structures
of these organizations
— Melvin Conway (1968)

37. what could we have done better?
— start small
— onboarding ops
— underestimated necessary culture change

38. what could we have done better?
— start small
— onboarding ops
— underestimated necessary culture change
— architectural challenges

39. why do it anyway?

40. makes sense

41. makes sense
— unix philosophy

42. makes sense
— unix philosophy
— swap services

43. makes sense
— unix philosophy
— swap services
— scale specific functionality

44. cool factor

45. RTFM

46. ITFM(f?)

47. Invent The Flippin' Manual2
2
https://www.youtube.com/watch?v=FArZxLj6DLk

48. Martin Fowler

49. innovation leads to
productivity and happiness

50. Services with the guts
on the outside
— Gartner

51. continued growth

52. conclusion

53. microservices
are awesome

54. Final words3
3
https://www.youtube.com/watch?v=Wk4Gu94R9ms&t=50s

56. Links4
4
Essential reading/viewing:
http://martinfowler.com/articles/microservices.html
http://www.slideshare.net/adriancockcroft/goto-berlin
http://blogs.gartner.com/gary-olliffe/2015/01/30/microservices-guts-on-the-outside/
http://www.slideshare.net/lemiorhan/a-gentle-introduction-to-micro-services-from-theory-into-practice
http://thenewstack.io/microservices-four-essential-checklists-getting-started/
https://www.youtube.com/watch?v=Qr0sATj9IVc