A Look At Micro Service Architecture

Micro-Service architecture has been around for a while now, but there is still no clear way to implement it in PHP. During this talk we will be taking a look at a couple of ways to implement it.

Transcript

1. A Look At Micro Service Architecture
2. 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.
3. Places You Can Find Me • Github: geevcookie • Twitter: geevcookie or joburgphp • Web: http://geevcookie.com/ • SpeakerDeck: geevcookie
4. Help Me Help You http://tinyurl.com/micro-services-talk
5. Them Slides http://tinyurl.com/them-slides
6. Story Time
7. Monolithic/Layered
8. Monolithic/Layered • Built as a single unit (All business logic, view, and data persistence in same application) • Default architecture when using popular modern frameworks
9. Pros • Easy to understand (If properly structured) • Most of us are used to this form of architecture • Easy to document
10. 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
11. Micro Services
12. There is no precise definition for micro services. - Me
13. Micro Services • Small independent pieces of code • Less than 100 lines of code • Smart Endpoints / Dumb Bus
14. 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)
15. Cons • Steep learning curve (Without proper guidance) • More management required
16. Evil Cycle Of Technical Debt
17. Common Cause Of Technical Debt • Laziness • Inexperience • Sloppy Code
18. HTTP As Bus
19. HTTP As Bus • Responds to JSON RPC • Self contained "mini apps" • Needs to live under web server document root
20. Pros • Easy to understand • Easy to implement
21. Cons • Not really scalable • Hard to configure
22. RabbitMQ As Bus
23. RabbitMQ As Bus • Long running service connected to RabbitMQ queue • Uses RabbitMQ's built in RPC functionality
24. Pros • More scalable • RabbitMQ clusters • Multiple services can listen to same queue • Still fairly easy to understand (With some help)
25. Cons • Requires more management • Harder to get up and running on dev's machines
26. The Hero • Bindings for multiple languages • No extra services required • Highly customizable
27. ZeroMQ
28. 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.
29. 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
30. It's a library!
31. Request/Response
32. Request/Response • Direct connection between app and the end point • Uses TCP connections
33. Pros • Smart end points are easy to create • Services can be on different servers
34. Cons • Only one service per "task" • No reliability checks
35. Request/Response Broker
36. Request/Response Broker • App connects to a broker • Broker manages connections to end points
37. Pros • Round robin load balancing between end points • Services can still be located on different servers • More reliability
38. Cons • Still not enough reliability. • More end points available, but are they really still there • Broker is still a single point of failure
39. 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
40. Pros • More reliable • Constant logs of communication between broker and end points • Better client connection
41. Cons • Could still improve load balancing
42. Request/Response Broker (Balanced)
43. Request/Response Broker (Balanced) • App still connects to broker and broker distributes to end points • Brokers communicate to offload extra jobs
44. Pros • Much more scalable • More more reliable • Better load balancing
45. Cons • Harder to manage
46. 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.
47. Config (etcd) • High available key-value store • Inspired by Apache Zookeeper • RESTful API
48. Management (Yogurt) • Talks to Supervisor, etcd, and custom client. • Can install client to servers automatically. • Provides easy scaling of services.
49. 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
50. Some Links • http://www.rabbitmq.com/ • http://zeromq.org/ • http://logstash.net/ • http://prediction.io/ • https://github.com/geevcookie/zeromq-php- helpers
51. The End