Scalability
Tips and Tricks for Tweaking and Using Ruby and Rails for a Distributed Enterprise Application

Summarized using AI

Tips and Tricks for Tweaking and Using Ruby and Rails for a Distributed Enterprise Application

Francis Sullivan • September 04, 2008 • Earth

The video, "Tips and Tricks for Tweaking and Using Ruby and Rails for a Distributed Enterprise Application," presented by Francis Sullivan at LoneStarRuby Conf 2008, shares valuable insights on utilizing Ruby and Ruby on Rails effectively within a distributed enterprise application context. Sullivan, the CTO and co-founder of Spiceworks, outlines key lessons learned from their experiences over the years.

Key Points Discussed:

  • Introduction to Spiceworks: Established in 2006, Spiceworks is a free, ad-supported application designed for IT professionals in small to medium businesses. It enables users to manage their inventory and service tickets while fostering a community for advice and expertise sharing.
  • Architecture and Deployment: The application runs on a cloud of Linux servers, designed for local installations on Windows machines. The shift from a hosted solution to local installations was driven by users' desire for private inventory data.
  • Ruby on Rails Adoption: Despite initial concerns regarding Ruby on Rails’ scalability, the streamlined development process and rapid prototyping capabilities outweighed these fears. Sullivan emphasizes how this decision catalyzed their growth, now supporting over 450,000 installations worldwide.
  • Managing Distributed Installations: Sullivan shares challenges faced in updating distributed installations. Initially, updates were applied silently during application restarts, leading to user confusion. The current approach allows users to approve major updates while minor updates are seamlessly deployed.
  • Performance Optimization: Noting that Ruby on Windows performed slower than on Linux or Mac, the team implemented optimizations resulting in faster execution speeds and better resource management. Innovations such as using C extensions for Ruby also contributed to enhanced performance.
  • Community Engagement and Feedback: The importance of community involvement in feature development and support is emphasized. Engaging with users has led to improvements and successful feature implementations that directly address their needs.
  • Multithreading and Concurrency: By incorporating these techniques into their network scanner, the performance improvements were significant, particularly in gathering and analyzing device information.

Conclusions and Takeaways:

  • The transition from the original idea to a hybrid installation model highlights the necessity of adapting to user feedback and preferences.
  • Ruby on Rails can scale effectively if developers are diligent about optimizing their applications and being aware of performance issues.
  • Community engagement is critical in driving improvement and innovation, underscoring the programmer's passion for continuous learning and adaptation.

In summary, Sullivan emphasizes that through shared experiences and community support, developers can navigate common challenges and continue enhancing their Ruby applications.

For further inquiries or collaboration, interested parties are encouraged to reach out via email.

Tips and Tricks for Tweaking and Using Ruby and Rails for a Distributed Enterprise Application
Francis Sullivan • September 04, 2008 • Earth

Tips and Tricks for Tweaking and Using Ruby and Rails for a Distributed Enterprise Application by: Francis Sullivan

LoneStarRuby Conf 2008

00:00:06.359 The video equipment rental cost is paid for by PeepCode.
00:00:18.560 Hello, I'm Francis Sullivan, the CTO and co-founder of a company here in Austin called Spiceworks.
00:00:24.400 Today, I will talk about some of the lessons we have learned and share tips on using Ruby and Ruby on Rails over the last few years.
00:00:30.519 The agenda will include a brief overview of our product—we're not trying to sell our product, as we don’t charge for it—so there’s no reason for that.
00:00:38.280 I will then cover some interesting topics that you may or may not find interesting; however, since I find them interesting, I will be discussing them.
00:00:43.600 I will talk about updating remote installations, as we have numerous installations in the field. We have implemented logic to keep these installations up-to-date with our most recent deployments.
00:01:00.519 Next, I will briefly cover the performance of Ruby on Windows. I will walk you through a very basic example of how we avoid deadlocks in certain situations.
00:01:12.040 Then, I will introduce an extension we wrote that allows us to use Active Record for tracking purposes.
00:01:19.200 Finally, I will discuss the tweaks we've implemented on our network scanner to make it run faster.
00:01:27.040 Quick show of hands: how many people here are from Austin? I can't tell you how amazing it is to see this because, three years ago when we started Spiceworks, I hardly knew what Ruby was.
00:01:51.280 So, can you hear me now? Great!
00:02:01.840 It's incredible to see so many people here from Austin. Of course, it's a local conference, but when I signed up to talk here, I was thinking there might be 50 or 100 people. This is truly amazing to me.
00:02:31.840 Quickly, I'll go over what Spiceworks does: we build software for IT professionals in small and medium businesses to manage their inventory, service tickets, and more. We were founded in January 2006.
00:02:45.000 Our mission was to simplify IT management for small to medium businesses. At the time we launched, we were the first free ad-supported IT application.
00:02:58.960 Now, ad-supported applications are becoming more common, and today we have 450,000 IT professionals using Spiceworks in 196 countries.
00:03:16.920 Our app isn't even internationalized, yet we manage over 20 million devices and serve 13 million users through those installations.
00:03:30.920 Our tagline is that we’re building the app for everything IT.
00:03:41.640 This is a quick timeline of a day in the life of an IT guy. We would love it if they used us every day because, as an ad-supported service, we don't make money unless you use the app.
00:03:51.280 Initially, we built a product that inventories everything within your network, including computers, printers, software, hardware, etc. Additionally, we integrated a community into our application, allowing users to seek advice and expertise from other Spiceworks users.
00:04:16.120 We also built a help desk feature into Spiceworks so users could resolve issues and interact with each other electronically. Eventually, they could share best practices and purchase products and services through Spiceworks.
00:05:03.120 Now, let’s talk about our architecture.
00:05:06.360 Our application runs on a cloud of Linux servers utilizing Ruby on Rails, and the Spiceworks application itself is installed on Windows computers in small and medium business environments.
00:05:17.520 However, this was not how it was initially designed; it was intended to be a hosted solution. Once we began deploying, we learned that users wanted their private inventory data to remain within their networks.
00:05:30.479 Consequently, we adopted a local machine installation model using Ruby on Rails. Everything is driven from a web server launched from that Windows computer on-site.
00:05:56.520 It’s interesting because we kind of backed into this model while trying to determine how to manage over 450,000 installations. If we had to host all those servers ourselves, it would have been a nightmare.
00:06:16.520 Instead, we found this hybrid model where users install the application locally and it works for us.
00:06:30.160 Scaling has been huge for us. We started with just three developers, and in three months we were able to release our Alpha version.
00:06:42.240 I want to explain why we chose Ruby on Rails. We had experience with Java, .NET, and various other frameworks, but we needed something fast; we couldn't afford to wait a year to develop our application.
00:07:07.960 We were looking for technology that allowed quick prototyping but could also scale. Despite hearing rumors that Rails didn't scale well, in January 2006, we took the risk.
00:07:25.479 Initially, we were concerned about documentation. Having worked with Python, I leaned towards it due to its great documentation, but one of my developers prototyped in Ruby in two days what would have taken weeks in Java, and his enthusiasm convinced me to give it a chance.
00:08:02.160 Now, Spiceworks is adding about 1,200 businesses a day. So, regarding scalability, we’re doing quite fine.
00:08:37.280 I want to share some lessons on handling distributed installations. When you have half a million installations of Ruby on Rails distributed across small businesses worldwide, the original idea was to update everyone whenever there was a change.
00:09:11.480 The thought process was that perhaps when we check in a line of code everyone gets it, and everything would be fine. We thought it would be easy to support since everyone would be up-to-date.
00:09:49.560 However, we found that sometimes the models were misaligned, or we had to migrate data. This could be confusing for users, especially those with a larger number of devices.
00:10:05.360 Updating seamlessly via an application restart can be problematic, as many installations may not get restarted often.
00:10:19.959 Thus, we decided that whenever a user makes a restart, we'll sneak in the update. Unfortunately, many users leave their services up for months without restarting.
00:10:46.120 This led to confusion as users would unexpectedly find the application had changed without prior notice. Consequently, we began allowing users to choose when to update; they could follow the process to receive updates when they felt comfortable.
00:11:17.720 The challenge was that users ended up with old versions for long periods, leading to multiple versions in support, complicating issue resolution.
00:12:11.640 The current implementation uses a hybrid approach: major updates require user approval, while minor updates can be pushed out silently.
00:12:53.540 Our application on the user's end makes calls to the main servers, checking for major and minor version updates.
00:13:09.959 In production environments, managing updates has its challenges. Developers have created a custom handler to split workloads into multiple gems, and updates can switch paths and clear out templates efficiently.
00:13:36.700 Regarding Ruby performance on Windows, we noted that stock Ruby from One-Click is significantly slower compared to Mac or Linux. After benchmarking, we realized Windows versions needed optimization.
00:14:09.720 One developer took the initiative to enable the optimization flag for Windows Ruby, resulting in substantial performance improvements.
00:14:50.320 Initially, we were waiting for the next Rails version, but as our application grew, speed became essential. Therefore, we started looking into optimizations.
00:15:19.479 Some changes included optimizing function calls and refining the code to significantly increase execution speed.
00:15:41.719 As we continued making changes, we increased the efficiency of our application. For instance, we doubled data collected while scanning devices and improved the execution from several seconds to mere milliseconds.
00:16:31.320 And with further enhancements like custom Ruby extensions implemented in C, we ensured ongoing performance improvements.
00:16:45.480 If you're into changing UI, be careful. A previous vote scheme was altered, leading to user backlash.
00:17:04.920 Also, I learned my lesson on searching and performance. We used Fair for searching strings within our app; while it was working, it needed to be better tuned.
00:17:44.840 Lastly, we must beta test major updates. An actual case where we failed to do this resulted in user dissatisfaction.
00:18:09.520 There’s a common misconception that Rails doesn’t scale, but once we delved into our code and optimizations, we realized that it was more about our approach than the framework itself.
00:18:36.440 Being aware of inefficient queries and programming methods was a key lesson learned for our team, and making adjustments to our data handling led to much faster load times.
00:19:07.360 It’s essential to recognize simple practices that can greatly enhance the user experience, including insightful community feedback.
00:19:42.720 Through our experiences, we've come to appreciate the importance of knowing our users and building features they want by actively engaging with them in discussions and reviews.
00:20:20.080 With close to half a million users and only a few support representatives, we've leveraged our community for assistance where many users help solve issues for others.
00:20:55.480 Developers also benefit from user feedback, allowing them to address core issues and enhance usability.
00:21:32.720 We have developed features in our monitors and alerts page that automate background checks and allow discussions on automation with others.
00:22:15.680 However, we've learned the necessity of enhancing usability while maintaining aesthetics and awareness.
00:23:00.320 Ultimately, community-managed features have proven incredibly popular in fostering collaboration.
00:23:45.040 Throughout this process, I have developed ways to optimize our scanner, allowing it to run more efficiently across the network.
00:24:32.520 For each scanning group, we normalize the entries and ensure the devices are being probed without downtime, dramatically improving performance.
00:25:17.640 Finally, we’ve seen that by utilizing multithreading and concurrent processing, we've managed to significantly reduce the time taken to gather and analyze device information.
00:26:06.600 In conclusion, as a Ruby community, we all face common challenges, but through continuous learning and adaptation, we can enhance our skills and ensure our applications serve users better.
00:26:58.800 As we work together to solve problems and face challenges head-on, the support of the community can lead to remarkable growth for those who contribute.
00:27:44.920 Remember, being passionate about your work as a programmer allows you to innovate, improve, and ultimately enjoy the process of developing with Ruby and Rails.
00:28:53.360 If you have any questions or would like to reach out, feel free to email me.
00:29:07.040 Thank you for your attention!
00:29:18.800 The video equipment rental cost is paid for by PeepCode screencasts.
Explore all talks recorded at LoneStarRuby Conf 2008
+18