4

We recently moved a large application to two machines, both running the same codebase.

I. Machine A

  • Web server for public facing application
  • Receives web hook call backs from our ESP
  • Handles a few large, list-processing jobs (uploaded spreadsheets with data)

II. Machine B

  • Manages a massive set of (background) jobs but, primarily, focuses on building and assembling newsletters
  • Runs all integration with our NetSuite platform
  • Runs all system maintenance (read: DB) jobs

To me, having these two apps running the same codebase (a large, monolithic Rails application) seems 'wrong'.

I am wondering if anyone has advice on how to better break up the code for these two apps. While they both need the same DB and, ultimately, the same model code, Machine B has no need for Controllers and Views and it feels wasteful running a full-stack Rails app for its tasks.

A couple things came to mind but I'm not sure if I'm trying to solve a problem that doesn't exist:

  • Break the models out into a sub-module on git and include into both apps
  • Build out the Mahcine B app in plain Ruby or a lighter framework like Sinatra (where I could use ActiveRecord with Sinatra in combo with a sub-module for the model folder).

I'm new to this scenario and appreciate any and all feedback or direction! Thank you.

craig.kaminsky
  • 141
  • 3
  • You could consider extracting the models out as a 'gem' or an 'engine', then separate the two machine-roles into different apps. Generally speaking that *might* be better, but depends.... are you feeling any pain? The monolith is easy to manage in some sense -- it's just the one thing! If it's tested, deploy it, and done... two separate apps with a common dependency have to be kept in syn and updated separately. My experience is that the monolith DOES causes problems like: tests that take too much time to run, bleeding of concepts into each other, duplicate code, slow startups, etc.... – adzdavies Aug 19 '14 at 03:32
  • Thanks, very much, @adzdavies, I appreciate the feedback and your thoughts! Our current setup does not cause us any pain (at least at the moment). There's just a boatload of code that Machine B never touches ... makes me feel like something's 'wrong' with the approach/setup. I'm reading up on service-oriented design and engines to see if any approach therein grabs me. – craig.kaminsky Aug 19 '14 at 19:48
  • git submodules are the only part of git that is quite weird to use. Extracting gems seems more reasonable. – Greg Nov 06 '15 at 11:05

0 Answers0