Deploying with JRuby

Editor's Notes

• #2: I’m a programmer, but I don’t tell that to my family. I tell them I’m a “Software Architect” because it doesn’t disappoint them as much. \n\nWhat we do is really about solving problems. In fact, I think easiest part of our job is writing the code. Figuring out how to tackle a problem is much harder. Sometimes we need to punch out some code to get through a problem -- it helps us realize what we are doing. But there are lots of different ways to solve problems:\n\nDivide and conquer: break in down into more manageable parts.\nTrial and Error: see what sticks to the wall.\nRoot Cause Analysis: eliminating the cause of the problem.\n\nWhen it comes to Ruby applications, JRuby is a means of eliminating the root cause of many architectural and deployment problems.\n\nBut I don’t like the phrase “root cause analysis” -- it’s too stuffy. I prefer the analogy to “changing the conversation.” Who watches Mad Men?\n\nIf you don’t like what’s being said, change the conversation\nIf you don’t like the solutions, change the problem.\n\nHave you ever focused really hard on a difficult problem, then realized (probably in the shower) that you could solve the problem by avoiding it altogether?\nOf course you have.\nIf you don’t like what’s being said, change the conversation\nIf you don’t like the solutions, change the problem.\nThat’s what this talk is about. There are problems with deploying MRI-based web applications that i’ll describe in a moment. \n\n
• #3: Memory Growth (each process has a copy of the app in memory)\nDatabase Pools (each process has it’s own DB pool)\nSlow Restarts\nZombies.\n\nThe result of these problems has been the additional layers. Unicorn and Passenger try to solve these problems. pgpool on the backend. God and Monit. \n\nBut really, we need to change the conversation. We need to eliminate the root cause.\n\nIt’s all because of the GIL\n\n\n\n
• #4: It’s all because of the GIL\nMultiple Ruby threads to one OS thread.\nYea, garbage collection and IO can happen concurrently, but not our code.\nThis is to protect the programmer.\n\nJVM does not have a GIL \nIt maps User threads directly to OS threads.\n\nA lot of folks want to remove the GIL -- to make MRI more like the JVM. It ain’t gonna happen.\nAt RubyConf 2011 someone asked Matz if the GIL would be remove. He said no. He doesn’t want MRI to be “that kind of platform.” \n\nI’m with Matz on this one. Ruby is supposed to make it easy for the program - Matz doesn’t care if it’s fast.\nThere are tons of applications where having a GIL doesn’t matter. \nBut web apps are not one of them.\n\n
• #5: one process. no balancing layers. no peripheral background processes. no external db pool (unless you’re running a cluster that shares a db instead of using replication).\n
• #6: Interesting question: is this thread-safe on MRI?\n\nIt depends. Do you care about the order of the data array?\n
• #7: Interesting question: is this thread-safe on MRI?\n\nIt depends. Do you care about the order of the data array?\n
• #8: This program runs the same benchmark twice. In each run it calculates the factorial of 99 400,000 times. \nThe first time, it uses a single thread. The second time, it uses four threads. \n\nInteresting question: is this thread-safe on MRI?\n\nIt depends. Do you care about the order of the data array?\n
• #9: This program runs the same benchmark twice. In each run it calculates the factorial of 99 400,000 times. \nThe first time, it uses a single thread. The second time, it uses four threads. \n\nInteresting question: is this thread-safe on MRI?\n\nIt depends. Do you care about the order of the data array?\n
• #10: That’s how JRuby changes the conversation for our architectural problems. But how do we implement this?\nThat’s where deployment comes in.\nDeployment is the process of taking something we’ve built, and delivering it to the customer. That includes the application and the platform it runs. So we have two considerations:\n1. how do we deploy our code\n2. how do we deploy our infrastructure.\nTraditional Ruby deployment takes a directory of loose files and launches them in a sort of shotgun blast arcoss a network, and we just have to hope that everything arrived intact. \nBut JRuby allows us to package our application -- independently of the platform it runs on -- and distribute it as a single file. This means we can encrypt it, sign it, or even compile it.\n
• #11: \n
• #12: \n
• #13: \n
• #14: Archive File / Capistrano\nBackground Jobs\nClustering\nPaaS\n\n
• #15: \n
• #16: \n
• #17: \n
• #18: \n
• #19: \n
• #20: \n
• #21: \n
• #22: You can still deploy your JRuby applications with Capistrano if you want, and there may be good reasons for do so. But that’s just it -- you have to figure out the nature of your constraints and select the best deployment strategy to suit that world.\n