We are still writing Microservices with the same rigour as we do regular applications. But is that needed? And is it enough? What do we have to think about?

1. What if everything you knew about
Code Quality is wrong?
Erwin van der Koogh
Principal Consultant
evanderkoogh

2. “What would it take to get
this out to customers?”
COO of a $30B company

4. Let’s rewind 6 months..

5. “What will TV & media consumption
look like 5 years from now?”
Same COO

6. Image © Gunnar Bothner-By

7. Image © Thomassin Mickaël

8. The Need for Speed
Image © Pagani. Used without permission

9. Languages:
Hours doing TDD:
Hours spend pairing:
Code Reviews:
Highest # of indents:
5+
0
0
0
9
# of tests: 0
# of CI builds: 0

10. You no know how to code?!

11. “What would it take to get
this out to customers?”
COO of a $30B company

12. Image © ViaCom. Used without permission

13. Image © CBS Studios Inc. Used without permission

14. One does not simply
Put a prototype in production

15. What we thought we build..
Image © https://www.flickr.com/photos/jldugger/

16. What we actually build

17. Huh?

18. Friction Driven Development

19. Huh?

20. Our pain?
Everything changed

21. Our pain?
All the time..

23. ‘Immutable’ Microservices

24. Huh?

26. Image © https://www.flickr.com/photos/scott_horvath/
Microservices
all the way
down..

30. Smooth Dependencies

31. Huh?

32. Dependencies are evil

33. You don’t import, but adopt
dependencies

35. Take Aways

36. Microservices
• Do one thing well
• (And that is still not one thing)
• Pretty doesn’t matter when it is done
• A Module (Group of services) has it own DB
• A new version of a service is a new service

37. Dependencies
• Just don’t do it
• Limit your exposure.
• Most dependencies are implicit
• Complexity is not in the components, but
the interactions