Oh Hai There
• My name is Zander Janse van Rensburg
• I'm the lead PHP developer at BlackLight
• Organizer of JoburgPHP1
1 JoburgPHP is so awesome that some of the CPT guys have considered flying up to join our
meetups.
Slide 3
Slide 3 text
Places You Can Find Me
• Github: geevcookie
• Twitter: geevcookie or joburgphp
• Web: http://geevcookie.com/
• SpeakerDeck: geevcookie
Slide 4
Slide 4 text
Help Me Help
You
http://tinyurl.com/micro-services-talk
Slide 5
Slide 5 text
Them Slides
http://tinyurl.com/them-slides
Slide 6
Slide 6 text
Story Time
Slide 7
Slide 7 text
Monolithic/Layered
Slide 8
Slide 8 text
Monolithic/Layered
• Built as a single unit (All business logic, view,
and data persistence in same application)
• Default architecture when using popular
modern frameworks
Slide 9
Slide 9 text
Pros
• Easy to understand (If properly structured)
• Most of us are used to this form of
architecture
• Easy to document
Slide 10
Slide 10 text
Cons
• Entire app needs to be built on deployment
• Entire app needs to be up and running for
development
• Can be frustrating and cause technical debt if
not managed properly
Slide 11
Slide 11 text
Micro Services
Slide 12
Slide 12 text
There is no precise
definition for micro
services.
- Me
Slide 13
Slide 13 text
Micro Services
• Small independent pieces of code
• Less than 100 lines of code
• Smart Endpoints / Dumb Bus
Slide 14
Slide 14 text
Pros
• Can be deployed separately
• Can be developed separately
• Easy for new developers to start development
• Code is disposable
• Can be coded in any language (Well almost...
When done properly)
Common Cause Of
Technical Debt
• Laziness
• Inexperience
• Sloppy Code
Slide 18
Slide 18 text
HTTP As Bus
Slide 19
Slide 19 text
HTTP As Bus
• Responds to JSON RPC
• Self contained "mini apps"
• Needs to live under web server document
root
Slide 20
Slide 20 text
Pros
• Easy to understand
• Easy to implement
Slide 21
Slide 21 text
Cons
• Not really scalable
• Hard to configure
Slide 22
Slide 22 text
RabbitMQ As Bus
Slide 23
Slide 23 text
RabbitMQ As Bus
• Long running service connected to RabbitMQ
queue
• Uses RabbitMQ's built in RPC functionality
Slide 24
Slide 24 text
Pros
• More scalable
• RabbitMQ clusters
• Multiple services can listen to same queue
• Still fairly easy to understand (With some help)
Slide 25
Slide 25 text
Cons
• Requires more management
• Harder to get up and running on dev's
machines
Slide 26
Slide 26 text
The Hero
• Bindings for multiple languages
• No extra services required
• Highly customizable
Slide 27
Slide 27 text
ZeroMQ
Slide 28
Slide 28 text
ZeroMQ
• Carries messages across inproc, IPC, TCP,
TPIC, multicast.
• Smart patterns like pub-sub, push-pull, and
router-dealer.
• High-speed asynchronous I/O engines, in a
tiny library.
• Build any architecture: centralized,
distributed, small, or large.
• Free software with full commercial support.
Slide 29
Slide 29 text
Some Supported
Languages
Ada, Bash, Basic, C, Common Lisp, C#, C++,
delphi, Erlang, F#, Flex, Go, Haskell, Haxe, Java,
Lua, Node, Objective-C, Perl, PHP, Python, Ruby,
Scala, Tcl, Smalltalk
Slide 30
Slide 30 text
It's a library!
Slide 31
Slide 31 text
Request/Response
Slide 32
Slide 32 text
Request/Response
• Direct connection between app and the end
point
• Uses TCP connections
Slide 33
Slide 33 text
Pros
• Smart end points are easy to create
• Services can be on different servers
Slide 34
Slide 34 text
Cons
• Only one service per "task"
• No reliability checks
Slide 35
Slide 35 text
Request/Response Broker
Slide 36
Slide 36 text
Request/Response Broker
• App connects to a broker
• Broker manages connections to end points
Slide 37
Slide 37 text
Pros
• Round robin load balancing between end
points
• Services can still be located on different
servers
• More reliability
Slide 38
Slide 38 text
Cons
• Still not enough reliability.
• More end points available, but are they
really still there
• Broker is still a single point of failure
Slide 39
Slide 39 text
Request/Response Broker
(Heartbeat)
• Added heartbeat functionality
• Broker constantly checks if end points are still
connected
• End points constantly check if broker is still
accessible
• Client has proper timeouts and retries
Slide 40
Slide 40 text
Pros
• More reliable
• Constant logs of communication between
broker and end points
• Better client connection
Slide 41
Slide 41 text
Cons
• Could still improve load balancing
Slide 42
Slide 42 text
Request/Response Broker
(Balanced)
Slide 43
Slide 43 text
Request/Response Broker
(Balanced)
• App still connects to broker and broker
distributes to end points
• Brokers communicate to offload extra jobs
Slide 44
Slide 44 text
Pros
• Much more scalable
• More more reliable
• Better load balancing
Slide 45
Slide 45 text
Cons
• Harder to manage
Slide 46
Slide 46 text
Monitoring (Supervisor)
• Checks if services are running and restarts if
required
• Provides stop/start/restart functionality to
services via control script
• Adds API to check status of services etc.
Slide 47
Slide 47 text
Config (etcd)
• High available key-value store
• Inspired by Apache Zookeeper
• RESTful API
Slide 48
Slide 48 text
Management (Yogurt)
• Talks to Supervisor, etcd, and custom client.
• Can install client to servers automatically.
• Provides easy scaling of services.
Slide 49
Slide 49 text
Big Dreams
• Self healing and scaling solution
• Connects to provider such as Digital Ocean to
scale servers as well
• Logstash and Machine Learning provides
accurate(ish) scaling based on history