A Gentle Walk Towards SOA

Many smaller projects with limited complexity can easily be served by an application written on top of your favorite monolithic framework. But as complexity and scope increase you will often find increased load times and significant barriers to testing by way of heavy coupling of both your application code and your data.

How do you approach this problem when you need to scale beyond the capabilities of a monolithic application? The concepts involved are rather simple and have been around for a very long time. But the path from monolithic application to a service-based architecture is not easy with existing projects. The answer is not to create many HTTP-based services tomorrow; the answer is to move iteratively through your codebase. In this talk we will look at how to approach this problem by teasing data and concerns into separated services in a step by step fashion.

Transcript

1. PRESENTED BY JEFF CAROUTH @jcarouth A Gentle Walk Towards SOA
2. Welcome to the 6-hour tutorial on service oriented and network- based application architectures.
3. Agenda • What problem are we solving? • Why do I need an SOA? • How can I implement this in my existing ball of mud architecture?
4. Application Architecture
5. Most application developers go through a progression of understanding of architecture.
6. Architectures
7. Architectures
8. Architectures libs
9. Architectures libs models controllers views
10. Architectures End User Application Business Logic Database
11. Architectures End User Application Business Logic Database Controllers Models Views
12. The Monolithic app End User Application Business Logic Database
13. The Monolithic app End User Application Business Logic Database
14. After nearly a decade of life, this monolith has 58 controllers and 153 models.
15. Adding a new feature likely means adding new controllers and new models.
16. Modifying existing models changes other models; changes other controllers.
17. Problem: Adding to or modifying the monolithic application is time- intensive and affects everyone who works on the app.
18. The Monolithic app End User Application Business Logic Database
19. The Monolithic app End User Application Business Logic Database
20. Service Oriented app End User Application Business Logic Database App Models Database App Models Database
21. End User Application Business Logic Database App Models Database App Models Database Service Oriented app
22. End User Application Business Logic Database App Models Database App Models Database Service Oriented app
23. End User Application Business Logic Database App Models Database App Models Database Service Oriented app
24. A monolithic application is a single codebase responsible for handling all application functionality.
25. A service oriented application is composed of many codebases each doing one thing only.
26. Do you even need a service oriented architecture?
27. Benefits of SOA • Reduces complexity of logic by removing unnecessary dependencies. • Makes deployments of new features and changes independent. • Provides an easy way to divide work and parallelize. • Makes it substantially easier to mix technologies. • Gives you the freedom to easily scale specific parts of your application.
28. drawbacks of SOA • Managing multiple codebases is hard. • More codebases means more dependencies. • Development environments are more complex. • Much more difficult to understand the system as a whole.
29. When to use SOA • You have a huge, cumbersome codebase and team. • You have an API-driven product/business. • You need independent scalability.
30. When NOT to use SOA • Almost every other time.
31. What you need to SOA • Experienced developers capable of building out APIs and abstractions around APIs that may or may not exist yet. • Time. • The ability to reject feature requests while you develop a robust platform.
32. Things You Don’t Have • Experienced developers capable of building out APIs and abstractions around APIs that may or may not exist yet. • Time. • The ability to reject feature requests while you develop a robust platform.
33. How to introduce SOA into your monolith
35. End User Application Business Logic Database App Models Database App Models Database Service Oriented app
36. Application Business Logic Database App Models App Models Service Oriented app
37. Architecture models controllers views libs services +
38. Payments libs authorize.net
39. Payments libs authorize.net Braintree
40. Payments libs authorize.net Braintree App Models Database
41. interface PaymentGateway { public function charge(Payment $payment); public function refund(Payment $payment); }
42. interface PaymentGateway { } class AuthorizeGateway extends PaymentGateway { public function charge(Payment $payment) { $authorize = new AuthorizeNetAIM(); /* some code omitted */ return $authorize->authorizeAndCapture(); } }
43. interface PaymentGateway { } class AuthorizeGateway extends PaymentGateway { } class BraintreeGateway extends PaymentGateway { public function charge(Payment $payment) { return Braintree_Transaction::sale(array( 'amount' => $payment->amount )); } }
44. interface PaymentGateway { } class AuthorizeGateway extends PaymentGateway { } class BraintreeGateway extends PaymentGateway { } class PaymentGatewayFactory { public static function create($gatewayType) { switch ($gatewayType) { case 'Authorize': return new AuthorizeGateway(/*...*/); case 'Braintree': return new BraintreeGateway(/*..*/); case 'GiftCard': return new GiftCardGateway(/*..*/); default: throw new UnknownGatewayException($gatewayType); } } }
45. Payments libs authorize.net Braintree App Models Database
46. namespace PaymentService; class Client { public function purchase($payment, $options = array()) { $requestBody = new ChargeRequest( $payment->amount, $payment->currency, true, $payment->card ); $client = new \Guzzle\Http\Client(); $post = $client->post( "", array('Content-Type' => 'application/json'), $requestBody->to_json() ); $response = $post->send(); return $this->decode_json($response->getBody()); } }
47. namespace PaymentService; class Client { } class PaymentServiceGateway { public function charge(Payment $payment) { $client = new \PaymentService\Client(); return $client->purchase($payment); } }
48. namespace PaymentService; class Client { } class PaymentServiceGateway { } class PaymentGatewayFactory { public static function create($gatewayType) { switch ($gatewayType) { case 'Authorize': case 'Braintree': case 'GiftCard': return new PaymentServiceGateway(/*..*/); default: throw new UnknownGatewayException($gatewayType); } } }
49. What have we achieved?
50. Architecture End User Application Business Logic Database
51. Architecture End User Application Business Logic Database Services Business Logic
52. libs authorize.net Braintree App Models Database service service service service JS App
53. Recap
54. Recap • Much like the evolution of your understanding of architectures, the evolution of a monolithic application to a service-oriented architecture will not happen overnight.
55. Recap • SOA is powerful and useful in certain situations.
56. Recap • It is possible to build towards SOA without picking up as much of the complexity burden until you are forced to.
57. JEFF CAROUTH Lead Platform Engineer at Liftopia Mid-level Tweeter as @jcarouth Inbox(0) guy at jcarouth@gmail.com Freenode user as jcarouth Co-Host of Loosely Coupled Founder of Dev Book Club
58. Thank You @jcarouth joind.in/13568