Jevgeni Kabanov in GeekOut: Redefining redeploys

1,969 views

Published on

Published in: Technology, News & Politics
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,969
On SlideShare
0
From Embeds
0
Number of Embeds
909
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Hi guys! My name is Jevgeni Kabanov and I’m here to present the “Do you really get changes?” talk.
  • Here’s my life in a tag cloud. I’m the original creator of JRebel and now the CTO of ZeroTurnaround, I used to write Haskell and still am a bit snooty about other languages, but I’ve been digging deep in Java for the past 7 years. I’m one article away from my PhD and have a wife, two cats and a really fast bike :)Before we go any further I’d like to ask you if you heard about JRebel?
  • Bringing developers and administrators together. Automation, lightweight process, fast reaction to errors v/s preventing errors at all costs
  • ClassLoader abuse
  • The majority of process restrictions stem from the technical issues.
  • Lower than expected, but is it because they don’t care or because it’s so hard to do without downtime?
  • This was calculated from those who allow downtime v/s those who actually are subject to it. The price is the average one, average length of an update is 1.6 hours. Could be more than $300,000 per update for some unlucky folks.
  • Only 16% fully automated! 54% majority has a manual step, 30% manual to a (varyingly) large extent. 7% have an “It’s the last copy of a list of arcane steps printed out three years ago. (May or may not involve sacrificing a goat)”
  • Lack of automation revealed nicely by the most popular tool, Maven & Ant mentioned often too. No real tooling available for automation!
  • Under 12% do fully transparent updates with no downtimes, 46% take the app offline (off-hours are a common complain), 42% risk side-effects with hacks causing complaints about reliability and downtime. Only 12% use container redeployment, why is that?
  • Very low.
  • We’ll examine all of them down the line.
  • 33% report onlyOutOfMemoryErrors, 46% multiple additional issues including PermGen or OutOfMemoryErrors, lack of support for database updates, thread races and deadlocks, thread and resource leaks, security concerns, native library issues, a multitude of application server caching issues, performance overhead, rollback difficulties and lack of reliability.
  • 33% report onlyOutOfMemory issues, 46% multiple additional issues including lack of support for database updates, thread races and deadlocks, thread and resource leaks, security concerns, native library issues, a multitude of application server caching issues, performance overhead, rollback difficulties and lack of reliability.
  • 33% report onlyOutOfMemory issues, 46% multiple additional issues including lack of support for database updates, thread races and deadlocks, thread and resource leaks, security concerns, native library issues, a multitude of application server caching issues, performance overhead, rollback difficulties and lack of reliability.
  • Tomcat 7, Weblogic 9.x+
  • The absolute majority of current ready-made tools support only two update methods: container redeployment and restarts with downtime
  • Session clustering is subject to state structure changes and heisenbugs
  • If the app is actively used it may take forever. Hard to automate due to lack of APIs and ready-made tooling. Needs manual control.
  • 33% report onlyOutOfMemory issues, 46% multiple additional issues including lack of support for database updates, thread races and deadlocks, thread and resource leaks, security concerns, native library issues, a multitude of application server caching issues, performance overhead, rollback difficulties and lack of reliability.
  • Rolling
  • 33% report onlyOutOfMemory issues, 46% multiple additional issues including lack of support for database updates, thread races and deadlocks, thread and resource leaks, security concerns, native library issues, a multitude of application server caching issues, performance overhead, rollback difficulties and lack of reliability.
  • LiveRebel does in-app hot updates, with no downtime, no lost sessions, no OOME, no side effect. It’s fully automated and instant.
  • 33% report onlyOutOfMemory issues, 46% multiple additional issues including lack of support for database updates, thread races and deadlocks, thread and resource leaks, security concerns, native library issues, a multitude of application server caching issues, performance overhead, rollback difficulties and lack of reliability.
  • 33% report onlyOutOfMemory issues, 46% multiple additional issues including lack of support for database updates, thread races and deadlocks, thread and resource leaks, security concerns, native library issues, a multitude of application server caching issues, performance overhead, rollback difficulties and lack of reliability.
  • Rolling restarts are hard because changes are hard in general!
  • Look at .NET, Dynamic languages, etc
  • Jevgeni Kabanov in GeekOut: Redefining redeploys

    1. 1. Do you really get changes?<br />Jevgeni KabanovFounder & CTO of ZeroTurnaround<br />
    2. 2. twitter.com/ekabanovzeroturnaround.com<br />
    3. 3. (how awesome is that?)<br />Over30 million builds, redeploys & restarts prevented for 15,000+ Java developers<br />twitter.com/ekabanov<br />
    4. 4. DevOps<br />
    5. 5. ClassLoaders<br />
    6. 6. Conversations & Research(LiveRebel)<br />
    7. 7. Tech v/sProcess<br />
    8. 8. How updates happen?<br />
    9. 9. What are the problems?<br />
    10. 10. How can we fix them?<br />
    11. 11.
    12. 12. Production Update Survey, May 2011<br />
    13. 13. 27% forbid downtime during production<br />
    14. 14. 19% lose ~$3,230 per minute on every update<br />
    15. 15. Update process rating<br />
    16. 16. Production update tools<br />
    17. 17. Production update methods<br />
    18. 18. Only 27% satisfied<br />
    19. 19. Issues: tooling, downtime, reliability, off-hours<br />
    20. 20. App Servers do ONLY redeployment,BUT<br />
    21. 21. Container Redeployment is a HACK!<br />
    22. 22. 24% allow redeployment, 12% rely on it<br />
    23. 23. 79% reportissues with redeployment<br />
    24. 24. Time for a SIMULATION<br />
    25. 25. Reloading an Object<br />OldClassLoader<br />NewClassLoader<br />MyObject.class<br />MyObject.class<br />Recreate the object<br />MyObject<br />MyObject<br />
    26. 26. Leaking ClassLoaders<br />ClassLoader<br />Class1.class<br />Class2.class<br />Class3.class<br />Static Fields<br />Static Fields<br />Static Fields<br />
    27. 27. Leaking ClassLoaders<br />WebApp.class<br />WebApp.class<br />WebApp.class<br />WebAppFactory$1<br />WebAppFactory$1<br />WebAppFactory$1<br />Leak.class<br />Leak.class<br />Leak.class<br />Leak<br />Leak<br />Leak<br />
    28. 28. Time for a DEMO<br />
    29. 29. BUT Wait!<br />
    30. 30. Parallel version deployment<br />
    31. 31. Rolling Restarts<br />
    32. 32. Session clustering<br />
    33. 33. Session draining<br />
    34. 34. Session reset<br />
    35. 35. Parallel hardware<br />
    36. 36. Time for a DEMO<br />
    37. 37. jenkins-demo.elasticbeanstalk.com<br />
    38. 38.
    39. 39. Time for a DEMO<br />
    40. 40. demo0.liverebel.com/rebel-chat/<br />
    41. 41.
    42. 42. Future: in-app updates, multi-process JVMs, ???<br />
    43. 43. Conclusions<br />Container redeploys are unreliable<br />Most popular update method is restart in off-hours<br />Biggest issues are lack of automation and downtime during updates<br />Another issue is lack of standard language for lightweight processes<br />In-App Updates and automated rolling restarts will solve majority of issues<br />
    44. 44. Q&A<br />

    ×