Skip to content

Instantly share code, notes, and snippets.

@mmmries

mmmries/tradeoffs.md

Created November 27, 2014 05:10
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save mmmries/09ae52f8e8eb8c8d1bc6 to your computer and use it in GitHub Desktop.
Save mmmries/09ae52f8e8eb8c8d1bc6 to your computer and use it in GitHub Desktop.
Download ZIP
Tradeoffs Between SOA vs Modular Ruby Code (gems / engines)
Raw
tradeoffs.md

Modular Ruby

  • Easier to combine / split apart components and re-deploy (ie. change your design)
  • Easier to manage dependencies (ie. gem versions + bundler)
  • No need to coordinate deploys since bundler pulls it all together for you
  • No need to serialize / deserialize data (ie. JSON, protobuf, etc)
  • No need to do service discovery / load balancing between pieces
  • Less need for integration tests (ie a staging environment)
  • Sometimes you can get caught wanting to upgrade a gem or ruby version, but something else in your big Rails app needs to the lower version

Service Oriented Architecture

  • Use whatever language makes it easier
    • use jruby / java to make use of an existing library
    • use mri + c extension to make use of an existing library
  • Less dependencies and less code to think about for any given service
  • Easier to scale out / optimize separate parts of your platform
  • Easier to upgrade individual services
  • Easier to write focused unit tests
  • More dependent on integration tests
  • Need to coordinate deploys that affect multiple services
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment