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
…considerably.
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.

Transcript

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 before.
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 at:
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.
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
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 trade-offs.
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 user.
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 databases.
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.
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.
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 mean
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.
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 works.
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. …
196. The One Thing That Still Holds True HTML has been with us for two decades now.
197. Lingua Franca HTML is **the language** of the web. And I'd argue of our culture.
198. Why Not? So, why not use HTML as the media type for our inter-app communication?
199. Primitives It's got semantics for roughly mimicking most primitives we care about in, say, JSON.
200. <ol> An ordered list is an array.
201. <ul> An un-ordered list is a set. Or could be thought of as one.
202. <dl> A definition list is a key-value store, or a hash.
203. <table> A table is a table.
204. <p> A paragraph is a string.
205. 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.
206. 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.
207. 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?"
208. RTFM One answer is: read the docs. Just like an XML or JSON API.
209. Standards The other answer is: use open standards.
210. XML Formats? There are a bajillion XML formats for all of the things. But most noticeably, there's
211. RSS/Atom RSS and Atom. They are formats of XML which is a media type.
212. JSON Formats? Every API is a unique and beautiful snowflake rolling its own particular format using the JSON media type.
213. 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.
214. 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.
215. HTML Formats? HTML has a rich set of formats for higher level data. The most widely used and my favorite is called
216. microformats microformats.org
217. 4.3.2 microformats microformats are a simple, native HTML way of adding
218. Additional Semantics additional semantics to the already existing semantics of HTML.
219. Classes All it takes is using classes to further describe what some data is.
220. E.g.,
221. Contact Info
222. <h1 class="h-card"> <a class="u-url" href="http://iamshane.com"> Shane Becker </a> </h1>
223. <h1> Shane Becker </h1>
224. <h1> <a href="http://iamshane.com"> Shane Becker </a> </h1>
225. <h1 class="h-card"> <a class="u-url" href="http://iamshane.com"> Shane Becker </a> </h1>
226. h-card That's a **very simple** h-card. There's also:
227. h-calendar
228. h-resume
229. h-event
230. h-recipe
231. h-review
232. h-geo
233. h-entry h-entry is the one that we care about most in our architecture of little apps.
234. h-entry =~ Atom entry h-entry is an HTML representation of an entry in an Atom XML feed.
235. Humans HTML is readable by humans using a web browser.
236. Programs HTML is readable by programs using Nokogiri.
237. 5. Callback
238. So. Let's tie it all up together now.
239. Little Apps Little Apps
240. Single Tenant Database Single tenant database
241. One App Per User One App Per User
242. Pull (not Push) Pull (not Push)
243. HTML (not JSON) HTML (not JSON)
244. HTML + microformats HTML + microformats
245. Websites At the end of the day, our whole big Constellation Architecture is just websites publishing HTML that humans and other websites read.
246. 6. Outro
247. The Web The architecture of the web scales. Conceptually and technically.
248. Web App Your web app will never be bigger than the web.
249. Web Scale™ If it works for the web as a whole, it'll work for your web app.
250. 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.
251. — XOXO Sb I love you.