Pro Yearly is on sale from $80 to $50! »

A Gentle Walk Towards SOA

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.

0f930e13633535c1c4041e95b8881308?s=128

Jeff Carouth

April 18, 2015
Tweet

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

  34. None
  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