I-Tier: Dismantling the Monoliths

48 Responses to I-Tier: Dismantling the Monoliths

  1. Par Trivedi
    October 30, 2013 @2:11 pm

    Nice work Adam, Sean, Todd, Jan, Tristan and the whole itier team. Congrats.

  2. October 30, 2013 @3:08 pm

    A very interesting read!

    It appears that the re-architecture is pretty much the same as whats happening to most web apps these days, looks like your standard SoA (Service Oriented Architecture). i.e. mostly centralised web service API that serve multilple different client platforms (mobile, desktop, etc)

    One thing that I didn’t see in the write up is any caching layer? or is that done semi-automatically via nginx routing?

    If you are using caching, what is your caching policy and where is that controlled?

    Not to sure about the use of node.js. as the bottle necks will always be the database (IMHO) one way or another.

    • Sean McCullough
      October 30, 2013 @8:35 pm

      We have caching at various levels in our infrastructure, from in-app data caching to service response caching, but due to the heavily dynamic nature of our pages doing page-level caching wasn’t useful.

      • Jimmy
        November 1, 2013 @11:23 am

        Does your company develop web mobile or native applications?

  3. October 30, 2013 @4:56 pm

    Impressive work, and I can’t wait for the follow-up. As a rails developer myself, I wonder, what would you have done differently with your initial single-app architecture that would have made breaking it up like this easier?

    • Sean McCullough
      October 30, 2013 @8:34 pm

      In general the single app architecture is the problem, not the language/runtime/web framework. I’m sure there are ways that we could have improved the monolith, but having apps with limited responsibility gave us more value. We could have used Rails to get to this new architecture, but we felt Node with our home-grown application stack gave us more flexibility.

  4. October 30, 2013 @6:08 pm

    Adam,
    I’m impressed at the work that went into this. Working with multiple technology stacks and trying to avoid frankenstein software is very challenging.

  5. Kieve Chua
    October 30, 2013 @9:06 pm

    I’m curious on “API Client Library”, is it a browser javascript framework that directly talk to api?
    Or is it a server side library that make http or whatever call to api?

    • Adam Geitgey
      October 30, 2013 @11:10 pm

      It’s a server-side library, but client-side communication is possible too via other means when needed. To keep the diagrams from becoming too complex, I just tried to point out major pieces.

  6. Jorge
    October 30, 2013 @10:40 pm

    What languages/frameworks/platforms are you using for Backend Services?

    • Adam Geitgey
      October 30, 2013 @11:15 pm

      Java and ruby are the most commonly used technologies in our backend systems, but we also have a good mix of other technologies in use in various systems like clojure, python, etc.

      • Peking2
        October 31, 2013 @9:34 am

        How about scala?

  7. Jesse
    October 31, 2013 @1:19 am

    Very nice! Congrats!

    I am curious about configuration management. 20 web apps is not a small number.

    • Adam Geitgey
      October 31, 2013 @10:35 am

      That’s a great point! Configuration management becomes critical in this kind of architecture. We are building a solution that we’ll cover in a future post.

      • Manasi
        November 4, 2013 @12:33 pm

        Great article.
        Would love to know more about config management.
        When do you plan to post about configs?

  8. Peter
    October 31, 2013 @5:23 am

    Hi! Did you look on EvenMachine + Fibers? Does’t it look more simple with similar efficiency?

    • Peking2
      October 31, 2013 @9:32 am

      I compared EM with node, EM is a little frustrating and node just works. I did some research and found many people tried EM first but ended up with node.

    • Sean McCullough
      October 31, 2013 @10:25 am

      We did evaluate using Sinatra with EM, and the performance was similar. The third party module support wasn’t great, and we felt that fibers aren’t a great way to express concurrency.

  9. Ananth
    October 31, 2013 @8:49 am

    Very Impressive note on past and the approach taken.

    Isn’t the database layer another bottle neck. with two different data centers taking in data through two different code, how difficult is that to combine?

    Is it left intentionally? what are all the possible breaks that were thought through which stopped from getting your hands on Database??

    How Friendly would be NoSQL for certain type of data that you were handling that are being thought through?

    • Adam Geitgey
      October 31, 2013 @10:33 am

      We have other teams working on combining the backend systems as a separate project.

      The diagrams here are a very high-level approximation of the backend just to give you an idea of the flow of data. There’s a lot of different pieces in the backend. Some of those pieces use NoSql databases and some don’t.

  10. Peking2
    October 31, 2013 @9:29 am

    I’d like to see more benefits of node to mention such as coffeescript, one language for frontend and backend, async, client side mvc etc.

    • Sean McCullough
      October 31, 2013 @10:27 am

      I’m working on another post to dive into more of the technical details of using Node and the challenges of ramping an engineering team up onto a new stack. Stay tuned!

      • Jim
        November 6, 2013 @12:10 pm

        Great article! Looking forward to more detailed discussion of Node.js: the features and the challenges.

  11. Regis Bectarte
    October 31, 2013 @3:24 pm

    Thanks for taking the time to explain what this i-Tier we have been hearing about for months is all about. The explanation is understandable even for a non technical audience. Thanks!

  12. Steve Gentile
    November 1, 2013 @8:36 am

    great read – look forward to your followup. Sean McCullough’s inline comments here are gems as well

    ps. love that you linked to ‘Simple Made Easy’ :)

  13. Ted Jenkins
    November 1, 2013 @3:18 pm

    Very interesting. We’re facing a similar quandary with our monolithic web app. Out of curiosity–why an nginx routing module? Why not simply use node for that as well?

    • Sean McCullough
      November 1, 2013 @9:08 pm

      We already had a lot of logic baked into our nginx config that we needed to maintain through the transition. Adding the routing layer to the existing infrastructure was safer.

    • November 3, 2013 @10:28 pm

      Using Nginx OpenResty with Lua solved a similar multiple upstreams problem for us. It made the Nginx config really short, plus Lua is likely a lot easier to maintain than a custom Nginx module.

  14. Troy
    November 1, 2013 @9:28 pm

    So is node rendering everything serverside or just pumping json out to clientside?

    • Sean McCullough
      November 5, 2013 @9:13 am

      We render the pages mostly server-side and enhance them with client-side rendering if the product calls for it.

  15. Jan Wit
    November 2, 2013 @7:44 am

    Thanks a lot for this article. Good to see architecture in action.

    I see in your paper that you managed to dismantle your monolithic web front end. But what about the API component ? Is it one component as it appears on your schemas ? One runtime ? One team in charge of it ? Do you put in production versions of your services without stoping the others ? And finally what is the underlying technology for this API ?

    Thanks !

    • Sean McCullough
      November 5, 2013 @9:14 am

      Our Ruby monolith had two facets: web frontend and REST API. The REST API is still there, but we’re starting down the road to breaking it up into smaller pieces. Much of the data model has been moved out into smaller services and the API is quickly becoming an aggregation point.

  16. November 2, 2013 @8:01 am

    Excellent write up on solving a really tough problem. It seems like a great solution. Diversifying your applications rather than lumping them all together, not to mention drastically improving your page load time.

    Have you noticed any difference or change in customer interaction after the changes? Particularly with a faster website…

    • Sean McCullough
      November 8, 2013 @4:02 pm

      The site is certainly faster! As for improved customer engagement, we usually measure that over a longer period of time so it’s harder to tell. We do know that our customers do engage with the site better when it’s up, and the new architecture makes it easier to keep the site up.

      • Sean McCullough
        November 8, 2013 @4:03 pm

        Also the site is faster primarily because we gutted a lot of legacy code paths on our backend and we rewrote all our HTML/CSS/JS to be much slimmer. That in and of itself was a huge win.

  17. November 3, 2013 @1:27 am

    One of the challenges of breaking single monolithic app into multiple services/tiny web apps, is the set of common Models or SW-CCC (System Wide Cross Cutting Concerns) such as Logs, Stats, Exception reporting, Security (User Model), etc..
    What was the approach taken to share that across the services?

    • Sean McCullough
      November 8, 2013 @4:07 pm

      We have some solutions in place for managing logs, stats, and exceptions for our current SOA, but they’re far from perfect. There are a few platform teams working on building out a solid distributed tracing system to help get a better view of all this.

      Cross cutting business requirements have been handled a few different ways. User authentication is distributed via module to all teams that need that functionality. The Layout Service hosts many web features that are used in all applications. But we’ve found that it’s actually nice not having these big concerns across our website anymore because regressions in these crucial pieces are often difficult to fix (e.g. if you have a before filter where you try to get the active user on every request and for some reason that call gets slow, your entire site gets slow in the same way).

  18. November 3, 2013 @1:27 pm

    It’s a very nice story about the complex work that sometimes we need resolve!

  19. Surge
    November 3, 2013 @4:30 pm

    Great article! Looking forward to the next post about the rewrite, especial on what nodejs technologies were used! Were there any downsides that was experienced in this rewrite using node?

  20. Chris Johnson
    November 4, 2013 @5:22 am

    Nice to see more companies see the value in Node.js, I am hoping that local companies here in the UK take notice, as I am one of a few in Northern Ireland using it in production. Looking forward to hearing about the specifics on what stack you used.

  21. Ron Williams
    November 5, 2013 @9:51 am

    Hi – This is great stuff, thanks for the post. One question: within your specialized front end applications, how do you handle duplicate code – especially javascript?

    You mentioned that you built an application framework in Node.js which contains the shared components for each of the web apps. Do you store shared client side components in this same framework to cut down on duplicate implementations of JS assets?

    * Thanks again for the great post. It’s great to hear a success story for a large Node application. Makes me want to try it out…

  22. November 5, 2013 @5:36 pm

    Curious if you looked into Celluloid::IO on the Ruby side. I’m gonna guess no…

  23. November 6, 2013 @12:40 pm

    Thanks for sharing… I am just beginning to consider ways to break apart a large (13 years) Java web app, and start anew. Front-end first, wrapper back-end services, etc.

  24. November 7, 2013 @2:07 pm

    What view engine are you using with Node or is it all JSON with client side rendering?

    • Sean McCullough
      November 8, 2013 @6:05 pm

      All server side. It’s the best fit for our read-heavy limited-step product.

      We’re using our own view/rendering pipeline (a fork of https://github.com/quackingduck/bulk-hogan/) and we use mustache for our templating.

  25. November 7, 2013 @3:46 pm

    Very cool!

  26. Rajesh
    November 28, 2013 @3:03 am

    Great article :)

  27. hugo villeneuve
    February 5, 2014 @2:01 pm

    I have been browsing the web to find some inspiration to build our next generation web architecture. This is by far the most useful post. Good job

    Question 1: Are all your API stateless or some of them statefull and need to keep track of ‘user session’ ?

    Question 2 : Is there any situation that some code you implemented in your Interaction Thier need to be re-use for your Mobile App (ie creating a Link between the Mobile and your Interaction layer)?

Leave a Reply

Your email address will not be published. Please enter your name, email, and a comment.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Scroll to top