Microservices architecture is garnering attention as a modern pattern for building application that scale well, deploy often, have better fault tolerance and can be built out of multiple technologies. We will go through the advantages and drawbacks of going Microservices way and when the pattern is a good fit. We will also touch on Docker, yet another buzzword, strongly emerging as a Microservices delivery mechanism for Linux based systems. If you are looking to refactor your monolithic application, to build a new cloud native application or simply to get your geek on this session is for you.

1. Microservices - Yet another buzzword?
Orlando Code Camp, 2015
Ovidiu Dimulescu
@odimulescu
www.odimulescu.com

2. The opinions and views expressed in this talk
are my own, and do not necessarily reflect the
opinions or views of my employer.

3. 3
Why bother?

4. * http://commons.wikimedia.org/wiki/File:Beer_growler.jpg

6. * http://microxchg.io/2015/index.html

7. ~1 out 5 sessions on Microservices directly or indirectly

8. * https://skillsmatter.com/conferences/6312-mucon

9. 9
* Wikimedia

10. * http://commons.wikimedia.org/wiki/File:Windows_Phone_8_Startscreen.png
* http://commons.wikimedia.org/wiki/File:IPhone_5C_PSD.png

11. 11
Monolith App
PM
QA
DEV
DBA
SA
NetEng
“On Premise”
No / SQL (single datastore*)

12. 12
Monolith App
UI
Data Access
Business Domain

13. 13
Monolith App
UI
Data Access
Business Domain
Comp I Comp II

14. 14
* http://commons.wikimedia.org/wiki/File:Gnome-emblem-package.svg
* http://commons.wikimedia.org/wiki/File:Inkscape_icons_dialog_layers.svg

15. 15
Does the code reflect the architecture?

16. 16
?
* http://commons.wikimedia.org/wiki/File:Component-cables.jpg
* http://commons.wikimedia.org/wiki/File:Gnome-emblem-package.svg

17. 17
APP
UI
Data Access
Bussines Domain
…
APP
UI
Data Access
Bussines Domain
APP
UI
Data Access
Bussines Domain
Scalability model

18. 18
ESB
WS-*
SOAP
XML
Svc I Svc II Svc N
PM
QA
DEV
DBA
SA
NetEng
“On Premise”
No / SQL (single datastore *)
…

19. 19
(Not so) Old world
Layers oriented
Scaling per app instead of per component
Process oriented / friction prone
Single language *
Single datastore *

20. 20
* http://en.wikipedia.org/wiki/User:Shijauddin#/media/File:I_am_a_Programmer.png

21. 21
* http://en.wikipedia.org/wiki/User:Shijauddin#/media/File:I_am_a_Programmer.png

22. 22* http://commons.wikimedia.org/wiki/File:Four_continents.png
* http://en.wikipedia.org/wiki/User:Shijauddin#/media/File:I_am_a_Programmer.png

23. 23
* http://en.wikipedia.org/wiki/Conway%27s_law
Organizations which design systems ... are constrained to
produce designs which are copies of the communication
structures of these organizations
Melvin Conway, 1968
Conway’s Law

24. 24
$$$
* http://commons.wikimedia.org/wiki/File:Gl%C3%BChlampe_42W_230V_E27_Effi_Klasse_C.jpg

25. 25
Web size
Team size
Team skills and geo distribution
Systems Architecture
Time to market
Scalabilities

26. 26
Opportunities ?

27. 27
* http://commons.wikimedia.org/wiki/File:A_new_and_correct_map_of_the_world,_laid_down_according_to_the_newest_discoveries,
_and_from_the_most_exact_observations_(8342680176).jpg

28. 28
PaaS
APIs
DevOps
HTTP 2.0
JSON
IaaS
*aaS
SQL + NoSQL (new datastores)

29. 29
Self - serve
Convenience oriented / low friction
Polyglot language and persistence
Fast & affordable experimentation
Uniform & disposable environments
New world

30. 30
Old world - Good Parts

31. 31
UNIX Philosophy
Write programs that do one thing and do it well.
Write programs to work together.
Write programs to handle text streams, because that is a
universal interface.
Doug McIlroy
* http://en.wikipedia.org/wiki/Unix_philosophy

32. 32
Initial
Stands for
(acronym)
Concept
S SRP [4]
Single responsibility principle a class should have only a single responsibility (i.e. only one potential change in the
software's specification should be able to affect the specification of the class)
O OCP [5] Open/closed principle “software entities … should be open for extension, but closed for modification.”
L LSP [6]
Liskov substitution principle “objects in a program should be replaceable with instances of their subtypes without
altering the correctness of that program.” See also design by contract.
I ISP [7] Interface segregation principle “many client-specific interfaces are better than one general-purpose interface.”[8]
D DIP [9] Dependency inversion principle one should “Depend upon Abstractions. Do not depend upon concretions.”[8]
* http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29
SOLID (OOP)

33. 33
Discrete services that ‘do one thing and do it well’.
Microservices

34. 34
SOA !?

35. 35
Microservices
Micro is about scope not size
Independently deployable (group level)
Lightweight communication
Single process (lightweight containers)
Smart endpoints, dumb pipes

36. 36
Right tool for a job
Different code changing speeds
Organizational splits
Multiple scaling profiles
Multiple security zones
Cross functionality
Microservices - Pros

37. 37

38. 38
Splitting / Merging / Defining boundaries
Micro frameworks / containers availability & reliability
Wiring complexity
Configuration Management
Testing / Deployment / Monitoring
Data Management (MDM, Eventual Consistency)
Cognitive complexity
Org structure and culture
Microservices - Challenges

39. 39
Conway’s Law
Adrian Cockcroft (BatteryVentures, ex-Netflix) suggested
that instead of designing software that copies our current
organizational structure, figure out how we want our
software to look, then (re) design the organization so it
copies the software.

40. 40
Jeff Bezos, CEO,Amazon
* http://commons.wikimedia.org/wiki/File:Pepperoni_pizza_(2).png
Two Pizza Rule

41. 41
* http://apievangelist.com/2012/01/12/the-secret-to-amazons-success-internal-apis/
1) All teams will henceforth expose their data and functionality through
service interfaces.
2) Teams must communicate with each other through these interfaces.
3) There will be no other form of interprocess communication allowed: no
direct linking, no direct reads of another team’s data store, no shared-
memory model, no back-doors whatsoever.The only communication
allowed is via service interface calls over the network.
4) It doesn’t matter what technology they use. HTTP, Corba, Pubsub,
custom protocols — doesn’t matter. Bezos doesn’t care.
5) All service interfaces, without exception, must be designed from the
ground up to be externalizable.That is to say, the team must plan and design
to be able to expose the interface to developers in the outside world. No
exceptions.
6) Anyone who doesn’t do this will be fired.
Jeff Bezos, CEO,Amazon - Big Mandate

42. 42
“You build it, you run it”
WernerVogels, CTO, Amazon
* ACM Queue interview, 2006. https://queue.acm.org/detail.cfm?id=1142065

45. Native
Boot2Docker
Supported Platforms*
Boot2Docker

46. Ecosystem
Many more …

47. Startup speed
Resource density
Layered file system with changes tracking
Hierarchical images with registry hub
Portable
Single process*
Features

48. The Twelve-Factor App - www.12factor.net
coding {the} architecture - www.codingthearchitecture.com
Pass for Microservices - gilliam.github.io
Martin Fowler - martinfowler.com/articles/microservices.html
Chris Richardson - microservices.io/patterns/microservices.html
High Scalability - highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html
The Arm Blog - the-arm.com/2013/09/30/microservices-and-solid-principles-of-object-oriented-design/
Dare to dream blog - davidmorgantini.blogspot.com/2013/08/micro-services-introduction.html
CharlesYoung Blog - geekswithblogs.net/cyoung/archive/2014/12/20/hexagonal-architecturendashthe-great-reconciler.aspx
Docker Website- docker.com
Google Search Engine - last but not least :)
Resources

49. Questions ?
Ovidiu Dimulescu
@odimulescu
www.odimulescu.com