Upgrade to Pro — share decks privately, control downloads, hide ads and more …

The Constellation Architecture — All the Little Apps

The Constellation Architecture — All the Little Apps

The Constellation Architecture — All the Little Apps
Shane Becker
My team and I were brought into The Company™ to help them take their One Big Monolithic Rails App™ and turn it into a a handful of smaller Rails apps that all work together… mumble mumble SOA mumble mumble.
When I started looking at it, I realized that 4 or 5 apps was only just scratching the surface. Instead of 5 apps, 1 for each product with a multi-tenant database, we've decided on 1 app per client, with NO multi-tenant database.
We have a few internal admin apps, then a whole slew of client apps. Each client has an admin app, a deployer app (to deploy the client admin), and n apps per client that are end-user facing.
- company admin apps:
- client admin deployer:
- client admin:
- end user site
- end user site
- end user site
- …
It's the classic Rails app story. Built in 2007 and piled onto for 6 years. Lotsa of version bumps and upgrades, but never any serious refactor. It's grown and grown. Clients have grown and grown. The technical requirements and cost of operating has grown and grown.
By doing this re-architecting we've reduced:
- the technical complexity of each app (each piece of the previous one big app)
- the resource requirements of each app
- the cost of operation
Oh, and we're doing all PULL (no push) and HTML with microformats as "API output" (no JSON).
Those three things (lots of little apps, pull, html) are changing everything for us.


Shane Becker

April 29, 2013

More Decks by Shane Becker

Other Decks in Programming


  1. None
  2. There Are Exactly Two Ways to Put the Toilet Paper

    on the Roll: Over the Front & The Wrong Way There Are Exactly Two Ways to Put the Toilet Paper on the Roll: Over the Front & The Wrong Way
  3. Don’t act like you’ve never stayed in a nice hotel

  4. I’m just kidding.

  5. The Constellation Architecture All the Little Apps My real talk

    hashtag is called: The Constellation Architecture — All the Little Apps
  6. 1. Intro

  7. Me Now I’m gonna talk about me.

  8. Who here knows me? Who here knows me?

  9. Who here knows of me? Who here knows OF me?

    Hi. It's nice to meet you. My slave name is:
  10. Shane Becker Shane Becker My name on the internet is:

  11. @veganstraightedge @veganstraightedge

  12. I used to look like that.

  13. Now I look like this. And you can find me

  14. iamshane.com iamshane.com I live at

  15. The Farmhouse The Farmhouse in: Photo Credit: http://farmhouse.la/house By: Tj

    Nelson Jr https://twitter.com/tjnelsonjr
  16. in the Hollywood neighborhood of: Photo Credit: http://en.wikipedia.org/wiki/Hollywood_Sign

  17. El Pueblo de Nuestra Señora la Reina de los Angeles

    del Río de Porciúncula Los Angeles, CA LA. Which is a BIG fucking city. With a big fucking name. In fact, it’s as big as 8 other U.S. cities combined:
  18. St. Louis, Milwaukee, Cleveland, Minneapolis, San Francisco, Boston, Pittsburgh and

    Manhattan. St. Louis, Milwaukee, Cleveland, Minneapolis, San Francisco, Boston, Pittsburgh and Manhattan. I live in the Minneapolis of LA. So, please keep that in mind next time you ask me to pick you up from the airport. Photo credit: https://www.facebook.com/photo.php?fbid=10151078446867664
  19. Farmhouse.LA You can find The Farmhouse online at: http://Farmhouse.LA and

    on Twitter as:
  20. @Farmhouse @Farmhouse At The Farmhouse, I organize the world's best

    backyard storytelling conference called:
  21. Farmhouse Conf Farmhouse Conf. You should come to it. If

    you live in the LA area, definitely get a ticket and come to it. If you don't live in LA, butyou're feeling wild and adventurous, buy a plane ticket and come down for a couple days. You won't regret it.
  22. Past Speakers Past speakers include:

  23. Aaron Patterson, Andy Baio, Brian (Crimethinc), Caroline Woolard, Eli Duke,

    Eric Gradman, Evan Phoenix, Greg Bennick, Jenny Ryan, Kate Darling, Leah Silber, Maggie Mayhem, Marc Horowitz, Megan Dean, Meghann Millard, Michael Lopp (@rands), Micki Krimmel, Mitch Artman, Nova Han, Peter Young, Sarah Mei, Sean Bonner, Shepard Fairey, Simone Syed, Suzan Bond, Tara Brown, Tj Nelson Jr, Zoetica Ebb All these awesome people. Some of which are here at Rails Conf this weekend. The next one is:
  24. FHC4:Future May 4, 2013 Farmhouse Conf 4 on May 4th

    with the theme of: Future
  25. 10 Speakers There are 10 speakers. 5 men. 5 women.

  26. Jacob Appelbaum @ioerror Jacob Appelbaum @ioerror COINTELPRO — Past, Present

    and Our Shared Future Who you nerds might know better as "@ioerror".
  27. Starlee Kine @StarleeKine Starlee Kine @StarleeKine Past, Present, Future; Tense.

    From This American Life.
  28. Adam Lisagor @lonelysandwich Adam Lisagor @lonelysandwich The Children Are Our

    Future The maker of all those awesome Sandwich Videos for: Square, Jawbone, Airbnb, and many more.
  29. Erika Brooks Adickman @ThisErikaLife * Erika Brooks Adickman @ThisErikaLife A

    Neurotic Gal Attempts A Fearless Look Into The Future.
  30. Zach Klein @zachklein * Zach Klein @zachklein We Will Build

    Offline in the Future Co-founder and designer of Vimeo, Svpply and most currently DIY.org.
  31. Jessica Lord @jllord * Jessica Lord @jllord Future Commonwealth Who

    designs gorgeous maps of cities and their imagined futures.
  32. Ron Evans @deadprogram * Ron Evans @deadprogram Future Current: The

    Robot (R)Evolution You all know Ron Evans. He'll have his robots out.
  33. Colleen Jordan @colleeniebikini * Colleen Jordan @colleeniebikini What We Will

    Make in the Future Who makes 3D printed plant holder jewelry.
  34. Justin Ouellette @jstn * Justin Ouellette @jstn Designing Forever Creator

    of Muxtape.com.
  35. willowbl00 @willowbl00 * willowbl00 @willowbl00 Replacing Uppercase “F” Fucked with

    Uppercase “F” Future : Active Participation in Response Talking about hackers, humanitarians, makerspaces, and our role as responsible citizens building The Future™.
  36. FHC4 May 4 Farmhouse Conf 4 May 4th

  37. Srsly. Please come to it. I'm incredibly proud of it.

    It's, by far, the best thing I've ever made. And the final one is:
  38. FHC5:Collapse November 2, 2013 Farmhouse Conf 5 on November 2nd

    with the theme of: Collapse
  39. I work for a company across the street right here

    in Bend, OR called:
  40. G5. I am a:

  41. Mr Manager™ Mr Manager™ of a

  42. Soſtware Team Small Software Team

  43. Some of which are here today. All of which are

    totally awesome.
  44. New Product We are building a new product Which this

    talk is extracted from: And, of course, Photo credit: http://en.wikipedia.org/wiki/Orion_(constellation)
  45. We’re Hiring! We're Hiring You should come work for us.

    Find me and let's talk.
  46. So, here's the:

  47. tl;dr tl;dr Three design principles changed everything for us:

  48. Little Apps Little Apps

  49. Single Tenant Database Single tenant database

  50. Pull (not Push) Pull (not Push)

  51. HTML (not JSON) HTML (not JSON)

  52. 2. Back Story

  53. Classic Rails Story Our story is no different than bajillions

    of Rails apps.
  54. 2007 The codebase was started in 2007.

  55. My First Rails App™ The developer who started it (our

    now CTO) had never written any Ruby or Rails but wanted to try it out.
  56. Javaland Expat He previously lived in Javaland and thought like

    a Java programmer.
  57. Learning by Doing He was making it up and figuring

    it out as he went. There's nothing wrong with that.
  58. What We All Did In 2007, we were all making

    it up on the fly.
  59. What We All Did In 2007, we were all making

    it up on the fly.
  60. 6 Years Later The codebase has been piled onto for

    6 years now. And it's just like you would expect.
  61. Old Patterns

  62. Crufty Code

  63. Hairy Corners

  64. He / We Learned a Lot During that time, he

    has improved as developer in general. And in the ways of Ruby and Rails idioms. Ruby, Rails and the ecosystem around the two have grown and improved in that time too.
  65. Works in Production Of course, let me be fair. Things

    might be less than optimal in the codebase itself, but that hasn't stopped customers from using it and the company to make millions of dollars from the product.
  66. None
  67. But…

  68. We Can Do Better

  69. And We Know It

  70. The L.A. Team I wrote a blog post in September

    2012 offering up me and 4 others as a cross functional product team for hire. 2 Ruby / Javascript developers. 1 Designer. 1 Front end developer. And me as Mr Manager.
  71. “Hire Us” We were hired 33 days later. G5 needed

    another team to expand their capacity and build a new product.
  72. Perfect Match It was a perfect match.

  73. Primary Objective When we were brought in, we kept hearing

    the story of big and cumbersome the product and codebase were.
  74. Product From a product perspective,

  75. All or Nothing For a customer to try out The

    Product, they had to use and pay for it in its entirety. They couldn't use just this small piece over here, then upgrade to additional pieces with time.
  76. Many Products in One The Company had identified that there

    were really 4 or 5 products inside of the big one.
  77. Sold Separately And if the technical changes could be made,

    then they could sell them as separates pieces.
  78. À La Carte The Customer could choose the pieces that

    make sense for her business, then add pieces in the future as her needs changed.
  79. Codebase Technically speaking, things were "too big and messy" too.

  80. Maintenance It was hard to work on.

  81. Fragile Things broke easily.

  82. Tribal Knowledge Because of the complexity, certain bugs and features

    always went to certain people who knew those parts of the codebase best. Billing, I'm looking at you.
  83. Familiar? Does this sound like something you've been through before?

    I think we all have.
  84. Common Trajectory It's a path that a lot of quick

    and dirty Rails apps take. They continue to grow until they're just too big to manage.
  85. Doesn't Have to Be There's got to be a better

    way! I mean, Right?
  86. 3. Build Up

  87. Unbundling Along with the story of "it's too big!", I

    kept hearing this desire to "unbundle" the big app into a handful of little apps.
  88. SERVICES ALL THE THINGS Service Oriented Architecture seems to come

    and go in fashion as The Magic Wand solution to all your problems.
  89. WHAT DOES IT MEAN?! But what **does** it mean? Really?

  90. A Lot of Things

  91. A Lot of People

  92. No One Answer There are lots of problems and lots

    of solutions. There is no one solution to rule them all( and in darkness bind them).
  93. SOA: Cargo Cult Any sufficiently advanced buzzword technology is indistinguishable

    from a cargo cult. SOA is no exception.
  94. Ask Around Ask yourself. Or your neighbors in this room.

    Or people out in the hallway. Or your boss. Or favorite tech blogger. What they think SOA is? You'll get different answers.
  95. E.g., SOA means Enterprise™. SOA means XML. SOA means SOAP.

    SOA means Java. SOA means JSON. SOA means Node.js. SOA means messaging queues. SOA means PUSH. SOA means async.
  96. That's OK I don't particularly care what SOA is or

    isn't. Or whether or not we're doing it The Right Way™.
  97. Different Story I knew of all of those stories about

    what it meant to use services. But I wanted to try something different. A few different things actually.
  98. 4. Break Down

  99. Remember the tl;dr? At the beginning of my talk, I

    mentioned the four take away points.
  100. Little Apps Little Apps

  101. Single Tenant Database Single tenant database

  102. Pull (not Push) Pull (not Push)

  103. HTML (not JSON) HTML (not JSON)

  104. Let’s Dive In Let's Dive In

  105. None
  106. 4.1 Little Apps

  107. Multi-Tenant Database A multi-tenant database is one where all of

    your users' data is intermingled in the same place.
  108. E.g., For example,

  109. Hosted Blogging Tumblr, WordPress.com, Square Space, Blogger, etc all do

    the same thing.
  110. Users Table There's a users table

  111. Posts Table And a posts table.

  112. Post.user_id And each post references a user.

  113. Rails 101 This is basic stuff. Rails 15 minute screencast

    kinda stuff. Nothing earth shattering.
  114. Trade-Offs Like all design decisions, using a multi-tenant database has

  115. Security By having all of your users' data in the

    same place, if one person is able to compromise the database and gain access to it, then she gains access to everyone's data.
  116. Privacy If you ship a bug that show the wrong

    data to a user, you're potentially showing someone else's data to someone else. Potentially, private data.
  117. Corruption If one user intentionally or unintentionally corrupts the database

    or saves corrupted data into the database, all users are potentially affected. Not just the one user who screwed up.
  118. Uptime Again, if one user manages to intentionally or unintentionally

    take down the database, it's taken down for everyone. Until you run your backups or fix the problem.
  119. Alternatively

  120. Single Tenant Database A single tenant database is one where

    all of the data is owned by one user.
  121. Single Tenant Database A single tenant database is one where

    all of the data is owned by one user.
  122. Security That means, if the database is compromised, only one

    user is at risk. One user is worse than zero user, But better than all users.
  123. Privacy It's impossible to show the wrong data to a

    user with a single tenant data, because there is no wrong data. Nothing belongs to someone else. It all belongs to the only user.
  124. Corruption Like Security, if corruption happens, it only affects one

  125. Uptime Same is true for Uptime. Only one user is

    taken offline if the database goes down.
  126. Many Users But no site only ever has one user.

    So if your has many users,
  127. Many Databases Then your site would have to have many

  128. Crazy! Which is just crazy bananas. That sounds like such

    a terrible idea.
  129. Unless… It's only a crazy idea if your site has

    1 big Rails app and many little databases.
  130. But… But, if your site has

  131. Many Little Apps many little Rails apps and

  132. Many Little Databases Many Little Databases

  133. Trade Offs Again, all design decisions come with trade offs.

    Running little apps with little databases means some things are gonna be different for us.
  134. Deployment Deployment being an obvious trade-off. Let's say we have

    1000 users. We update the codebase and need to deploy to all the users.
  135. `git push` We can no longer, just `git push` or

  136. `cap deploy` `cap deploy` or whatever.

  137. Alternatives What are our options?

  138. Scheduling We can schedule the deploys and `git push` down

    a list of apps until we hit all 1000 of them.
  139. Batching Similar to scheduling, we can grab a group of

    apps deploy them all at once. Grab another batch, rinse, repeat. Both seem like they have a lot of overhead and complexity. Something I didn't want to deal with. And they seemed fragile too.
  140. None
  141. Autonomy Instead, what if each app was responsible for itself

    and its own needs?
  142. “Should I Update and Deploy?” Each app periodically asks an

    admin app if it should update. If "yes", then it goes off to GitHub, `pulls master`, `bundles`, `db:migrates` then finally re-launches the site.
  143. Buddy System Because we're using Heroku for this and Heroku

    apps can't re-deploy themselves, we actually use a buddy system. Each app has a sibling that deploys each other.
  144. A <–> B App A listens for instructions to update/deploy

    app B. App B listens for instructions to update/deploy app A.
  145. None
  146. Limited Concerns We want each of our types of apps

    to be simple technically and conceptually. The old "only do one thing" principle.
  147. G5 Hub In our system, the first thing we need

    to do is create clients. That's a pretty simple thing conceptually. We call this the "G5 Hub" because only G5 admins login to it to create new clients.
  148. Client Hub The apps that users access directly to do

    their admin stuff, we call that app a Client Hub. Its buddy is called a Client Hub Deployer.
  149. Bubble Up In between the G5 Hub and all of

    the Client Hubs, we have a handful of apps that handle the automated creation, initial deployment and bootstrapping new apps.
  150. One App Per Client Remember, we end up with 1

    Client Hub for every client.
  151. Two Apps Per Client But because of the buddy system,

    that's actually two apps per client: Client Hub and Client Hub Deployer.
  152. Inter-app Communication To explain how each app talks to other

    app, we have to move on to the other two unconventional ideas in our Constellation Architecture.
  153. 4.2 PULL

  154. First Things First Lemme just be clear up front that

    when I say
  155. “Pull” "Pull", I mean the antonym of

  156. “Push” "Push". Although, you might be thinking that I actually

  157. “Poll” "Poll" as in

  158. “Polling” "Polling". And you would be right. Technically, what I'm

    talking about when I say "Pull" (with a U) is actually "Poll" (with an O). But it just feels wrong.
  159. Push & Pull Push and Pull are antonyms and that

    mental symmetry feels right to me.
  160. None
  161. Trade Offs Again, like everything, Push and Pull each have

    advantages and disadvantages.
  162. The Hottness These days Push is all the rage. Kids

    are like PUSH ALL OF THE THINGS.
  163. Kinda Makes Sense It seems like a good idea. "Here.

    I have this thing. I am giving it to you."
  164. Un-Webby But Push isn't very much like how the web

  165. Web == Pull Pull is the way the web works.

  166. Pull is Easier Pull is so much easier.

  167. Publish a Document Sites publish documents.

  168. Read a Document Then someone (human or program) requests that

    document and reads it.
  169. Media Types And the format doesn't matter:

  170. HTML

  171. JSON

  172. XML

  173. JPEG

  174. PNG

  175. *

  176. Blogs Blogs. Good ol' blogs. Rails is definitely good at

    that, right?
  177. Blog Post A user writes a new blog post. She

    publishes it.
  178. Permalink The blog app creates the new post page. In

    Rails parlance, that'd be posts#show.
  179. Homepage The post gets added to the homepage.

  180. RSS/Atom And the post gets added as an entry to

    the site's RSS or Atom feed.
  181. No Push That's it. Just adding a page to her

    site. Super simple. Super easy. Super inexpensive.
  182. Imagine Imagine if every time a blogger wrote a new

    post, her site had to push a message to all of the readers and subscribers of her site.
  183. Popular Site Now imagine if a very popular blog with

    millions of readers had to do that. Now multiply that by several posts per day.
  184. Overworked Server Her server would fall down under the weight

    of that load OR it would cost her an arm and leg to keep it up and running.
  185. 4.3 HTML

  186. Final Piece The final piece of the puzzle, or at

    least of **our** puzzle, is how do wrap up the data that we're reading between apps.
  187. JSON Duh, right. Everyone uses JSON for all of the

    things. That's just what you do.
  188. XML "We used to use XML for all of the

    things, but that's sooo last version of Rails ago." Or... "XML? Ugh. That's for the enterprise."
  189. Trends It seems like every few to several years, there's

    the new One Right Way for APIs to talk at each other.
  190. JSON

  191. Roll Your Own XML

  192. SOAP

  193. XML-RPC

  194. CORBA

  195. The One Thing That Still Holds True HTML has been

    with us for two decades now.
  196. Lingua Franca HTML is **the language** of the web. And

    I'd argue of our culture.
  197. Why Not? So, why not use HTML as the media

    type for our inter-app communication?
  198. Primitives It's got semantics for roughly mimicking most primitives we

    care about in, say, JSON.
  199. <ol> An ordered list is an array.

  200. <ul> An un-ordered list is a set. Or could be

    thought of as one.
  201. <dl> A definition list is a key-value store, or a

  202. <table> A table is a table.

  203. <p> A paragraph is a string.

  204. Integers / Floats The one that I don't have a

    great answer for is integers and floats. But we can just duck type smash our way through that one.
  205. White-Space Ambiguity When I asked around on Twitter about how

    people felt about HTML as API output, the most legit answer I heard is that HTML has ambiguous rules on how to parse whitespace. That's a very fair point. Something to consider and act on accordingly.
  206. Formats Another concern, I often hear from people is that

    "how will I know what to expect from an HTML API?" Or "what format will the data be in the HTML output?"
  207. RTFM One answer is: read the docs. Just like an

    XML or JSON API.
  208. Standards The other answer is: use open standards.

  209. XML Formats? There are a bajillion XML formats for all

    of the things. But most noticeably, there's
  210. RSS/Atom RSS and Atom. They are formats of XML which

    is a media type.
  211. JSON Formats? Every API is a unique and beautiful snowflake

    rolling its own particular format using the JSON media type.
  212. Activity Streams Activity Streams has an XML representation (built on

    Atom) and JSON representation. Effectively, no one is doing anything with this. Which is a bummer. I really wanted Activity Streams to gain traction.
  213. RSS JSON rssjs.org Dave Winer is asking the question /

    loosely proposing a JSON representation of RSS. Which I think is a total shit show. But besides that, literally no one is using it.
  214. HTML Formats? HTML has a rich set of formats for

    higher level data. The most widely used and my favorite is called
  215. microformats microformats.org

  216. 4.3.2 microformats microformats are a simple, native HTML way of

  217. Additional Semantics additional semantics to the already existing semantics of

  218. Classes All it takes is using classes to further describe

    what some data is.
  219. E.g.,

  220. Contact Info

  221. <h1 class="h-card"> <a class="u-url" href="http://iamshane.com"> Shane Becker </a> </h1>

  222. <h1> Shane Becker </h1>

  223. <h1> <a href="http://iamshane.com"> Shane Becker </a> </h1>

  224. <h1 class="h-card"> <a class="u-url" href="http://iamshane.com"> Shane Becker </a> </h1>

  225. h-card That's a **very simple** h-card. There's also:

  226. h-calendar

  227. h-resume

  228. h-event

  229. h-recipe

  230. h-review

  231. h-geo

  232. h-entry h-entry is the one that we care about most

    in our architecture of little apps.
  233. h-entry =~ Atom entry h-entry is an HTML representation of

    an entry in an Atom XML feed.
  234. Humans HTML is readable by humans using a web browser.

  235. Programs HTML is readable by programs using Nokogiri.

  236. 5. Callback

  237. So. Let's tie it all up together now.

  238. Little Apps Little Apps

  239. Single Tenant Database Single tenant database

  240. One App Per User One App Per User

  241. Pull (not Push) Pull (not Push)

  242. HTML (not JSON) HTML (not JSON)

  243. HTML + microformats HTML + microformats

  244. Websites At the end of the day, our whole big

    Constellation Architecture is just websites publishing HTML that humans and other websites read.
  245. 6. Outro

  246. The Web The architecture of the web scales. Conceptually and

  247. Web App Your web app will never be bigger than

    the web.
  248. Web Scale™ If it works for the web as a

    whole, it'll work for your web app.
  249. Thank You I know your time and attention is more

    precious than any other commodity. I appreciate it greatly that you gave me a few minutes of it.
  250. — XOXO Sb I love you.