Ruby in the Cloud

Ruby

Ruby in the Cloud

Mike Subelsky

2 talks

Ruby in the Cloud

by Mike Subelsky

In the presentation titled "Ruby in the Cloud," Mike Subelsky, co-founder of Other Inbox, discusses the transition from traditional server environments to cloud computing, specifically using Ruby as a development tool in this new ecosystem.

Key Points:

Introduction to Cloud Computing: Subelsky describes the exciting shift towards cloud computing, highlighting its advantages like disposable servers, flexibility, and the ability to quickly scale applications.
Transition Process: Initially, Other Inbox operated on a single Rails app server, which was not sustainable long-term. The move to a cloud platform (EC2) was surprisingly fast, taking only about 30 minutes to migrate, as pre-built images simplified server setup.
Defining Cloud Computing: For the purpose of the talk, he defines cloud computing as servers running code consumed as a service, emphasizing their loosely coupled and distributed nature.
Using Ruby to Manage Complexity: Subelsky elaborates on how Ruby facilitates task management in the cloud, connecting different components smoothly and reducing the complexity of operations.
Tools and Gems: He highlights several essential Ruby tools:
- God RB for process monitoring and management
- Rufus Scheduler for task scheduling
- Capistrano for deployments
- Homegrown Ruby scripts for server launch and management, despite the need for optimization and structured code.
Benefits of a Unified Language: The use of Ruby throughout the programming environment allows for better focus, unit testing, and ease of learning among team members.
Future Improvements: Subelsky discusses strategies for improved cloud management, emphasizing gem usage, unit testing, and structured scripts for efficiency.
Conclusion: He stresses the importance of building redundancy in cloud applications for data integrity and robust performance. He encourages a unified approach to managing cloud-native applications to enhance operational effectiveness.

Takeaways:

The presentation reinforces that adopting cloud solutions can greatly improve flexibility, scalability, and management within a development environment, particularly when leveraging the Ruby programming language. Overall, Subelsky advocates for a strategic, Ruby-centric approach to cloud computing that minimizes complexity and fosters collaboration among development and operational teams.

00:00:06.600 Video equipment rental costs were paid for by PeepCode.

00:00:24.039 Screencasts. Okay, is this thing on? Can everybody hear me? Are there any technical problems before I start?

00:00:29.279 Alright, I want to start my presentation. I like to jump right in and get right into the thick of things.

00:00:37.000 This is one of the tools that I'm going to talk about. This is a part of a God RB watch configuration file, and I will return to that in a little while.

00:00:49.559 I work as a co-founder of Other Inbox, a startup based here in Austin. About exactly one year ago, we were running a prototype of our app, which was a Rails app running on a Tiger server that we just happened to have in the office.

00:01:08.840 It was up on a breadboard, and it actually worked pretty well for a long time. We had a couple of dozen early beta testers using it and providing us feedback.

00:01:21.640 However, obviously in the long run, that wasn’t what we wanted to be running our whole app on.

00:01:33.399 So today we are running in the cloud.

00:01:39.799 This visualization represents the excitement of cloud computing, and how distributed and wonderful it is. We're these super hip developers, and we could be on a hay bale working on our app, and it's totally fine; we’re not tied to some server room.

00:01:52.680 More seriously, we’re really able to take advantage of running our app on a cloud platform. We can think about our infrastructure completely differently.

00:02:06.320 Our servers are disposable, making it easy for us to experiment. When we do major changes to our database, we can launch two or three different copies of the database and run the migration at the same time. If it fails on one, we’re not stuck.

00:02:20.400 There are many different ways we can distribute work between our servers. But how do we go from that one server, which we had set up quickly, to working in the cloud?

00:02:37.720 It took me a few hours to get the servers built. Whatever cloud platform you choose, there are usually a lot of pre-built images that contain most of the tools you need.

00:02:50.200 For us, we use EC2, and there are a ton of images out there that contain most of what you need. The rest of the time is spent customizing it to your own needs.

00:03:08.239 It probably took me a few hours to build the servers; moving the app over only took maybe 20 to 30 minutes. I have a little cognitive dissonance; I’m nine months past this and probably remembering it a bit optimistically, but I don’t remember this part taking much time at all.

00:03:21.360 Moving from a whole ecosystem running on this one machine to an entire ecosystem running on multiple machines was surprisingly fast. That really only took about 30 minutes to get up and running.

00:03:39.159 The rest of the time I was working on building new features, taking advantage of being in the cloud, having a flexible environment, being able to use disposable servers, and spinning things up when there’s more work to do and shutting them down when there isn’t.

00:03:58.400 So, that’s what I’m going to talk about: why was it so easy for us to transition to this cloud environment and what are some resources available to help you take advantage of it?

00:04:09.799 I believe it dovetails pretty well with the last talk. I'm going to show you something at a slightly lower level of detail, not using third-party gems, but using some third-party tools to help manage our systems.

00:04:23.560 Any talk like this requires us to define our terms because 'cloud computing' can mean whatever someone wants, depending on what they're selling.

00:04:34.639 For the sake of this talk, let's agree on what I personally mean by cloud computing. We are talking about servers running your code that you consume as a service, meaning you rent them by the hour. You don't own any physical hardware and are not responsible for providing power to them.

00:04:55.520 This cloud service is valuable because your servers are loosely coupled, which means you have code running in different places, and you might not know ahead of time who you’re talking to. You don’t have a lot of information about each side of a connection.

00:05:19.680 It’s also distributed. For us, the essential parts of our system are not all running in the same place within Amazon's computing cloud. We don’t care where the stuff is running, as long as there’s enough segmentation to prevent one problem from affecting others.

00:05:34.000 It’s a single point of access. No matter where our data is stored or where code is running, all we have to do is SSH into an IP address to access it. We then just set up our DNS, and users can find the server.

00:05:55.400 Cloud computing is grid-like. If that phrase makes more sense to you, think of it as a grid of servers that talk to each other. It's utility-like because you buy this stuff by the hour. The cheapest instance we use is about 10 cents an hour.

00:06:14.360 I don't know the pricing models that Heroku and Engine Yard use, but it’s the same principle where you’re not tied to a device that you have to own and maintain. Cloud computing is cheap, redundant, scalable, and flexible, but it can be a little too flexible.

00:06:40.319 There are complexities you might not have had to deal with when you were just using that one server you could hard reset or connect a monitor and keyboard to.

00:06:53.759 Now, you’re faced with issues that I won’t dive into because they extend beyond the scope of my talk. I’m merely pointing out that being able to turn servers on and off, having them auto-scale, and communicating with each other adds a lot of complexity.

00:07:09.120 Ruby can help with that complexity. I want to share how we’re using Ruby to manage the challenges of being in a cloud environment. To start with, we use Ruby as the code that glues other Ruby code together.

00:07:29.960 However, I feel that this description underestimates its importance. It’s more than just a collection of scripts; Ruby serves as the connective tissue animating our entire ecosystem.

00:07:57.120 While we’re not dogmatic about it and will certainly use something better if it comes along, my experience over the past year as the sole developer for about six or seven months is that Ruby has allowed me to accomplish a great deal without spending too much time on sysadmin tasks.

00:08:13.080 What do I mean by a Ruby ecosystem? I’m talking about Ruby code that schedules the execution of other Ruby code. This involves using gems like Rufus Scheduler, monitoring Ruby code via something like God, and managing server tasks through Capistrano.

00:08:40.080 For example, Ruby code that kills other Ruby code is facilitated by Capistrano tasks that call God RB, which represents a layer of Ruby connective tissue.

00:08:55.520 We also use homegrown Ruby scripts to launch servers, although I wouldn’t recommend this approach for the future. Since I put this together, there are better solutions available.

00:09:10.640 I’ll show you a bit of the code, though I’m not particularly proud of this long, evolving script. However, I was able to write it quickly, which is why it didn’t take long to get us running on a new platform.

00:09:32.080 Ruby code is also used to configure servers. When we launch a new server, we utilize the DD client to communicate with the Dynamic DNS provider, allowing our newly launched server to obtain its domain name.

00:09:57.520 Static IP addresses can be acquired with Amazon, but you’ll always need some kind of Dynamic DNS management when you want to operate at scale.

00:10:18.680 So, Ruby provides a blanket of freedom and security that we as Ruby developers can flourish under.

00:10:29.280 Now, why would you want to implement everything in Ruby?

00:10:39.600 If I were in the IRC channel right now, I could imagine people asking, "Doesn’t this guy know about Monit or LaunchD?" or questioning if there are better solutions out there.

00:10:59.640 The reason for using Ruby everywhere is largely tied to the complexity I mentioned earlier; all these systems are configured differently, requiring different syntaxes and thinking.

00:11:10.800 If you're doing cloud computing right, it shouldn't resemble the exact same setup you had with your traditional ISP.

00:11:27.360 You're taking advantage of loose coupling where one machine runs code that distributes tasks to another server to pull off and start working, and your storage is distributed.

00:11:46.560 The disposable nature of these servers means you need to keep better track of them. Knowing where your five physical boxes were was easy; now, you can start them up anytime.

00:12:03.440 This snippet demonstrates the management tool we use, which happens to be a Rails app. The names of these dynamically launched servers indicate their temporary nature.

00:12:18.200 Ruby helps to simplify this complexity, and that’s what I’m here to explain.

00:12:37.160 We love Ruby and its expressiveness, which allows us to articulate things clearly and powerfully.

00:12:53.400 If you were a non-programmer trying to understand a scheduling expression, would you rather read the complex syntax or something clear and straightforward like, "scheduled every five minutes"?

00:13:11.040 Ruby allows you to encapsulate time in a way that makes sense. Additionally, Ruby offers platform independence, so as long as you have the right tools, you're not tied to any specific operating system.

00:13:29.840 You don’t have to resort to writing shell commands because the Ruby standard library provides utilities that replace the need for backticks.

00:13:49.680 This is an example from a neat gem called Rush Ruby Shell, which enhances readability by offering an object-oriented approach to file operations.

00:14:05.799 Another significant benefit of Ruby in this context is that it allows you to write testable code.

00:14:24.560 You can write tests to verify if the connective code functions correctly. In contrast, scheduling with crontab can often lead to confusion.

00:14:41.120 You can't always ensure whether or not your task is scheduled; was it a star or a question mark? With Ruby, you gain clarity and can create tests to check that your scheduling works.

00:15:07.080 We have learned to keep the glue code minimal, with each scheduled job calling a method on a class. This makes unit testing that class easier.

00:15:28.560 Limiting what goes into the scheduling code allows for better exception handling, logging, and overall simpler operation.

00:15:47.360 Another benefit is reduced context switching. Staying in one language environment allows me to work more efficiently.

00:16:06.520 If I’m writing a Ruby application, whether it’s a monitoring, task, or launch script, I find it much easier to maintain focus.

00:16:21.680 This is also why I treat this glue code as part of the application, as it can be easily placed under version control.

00:16:39.120 Having all critical configuration files in version control provides us with the benefits of easily reverting and tracking changes.

00:16:59.480 Additionally, this approach fosters a closer alliance between developers and operations teams. When team members can communicate in the same language, it makes coordinating easier.

00:17:18.760 While it's important to have people familiar with Ruby, it’s also not a huge barrier, as people tend to find it easy to learn.

00:17:31.960 As Ruby developers, we can write our code in a way that makes it understandable and clear, leading to more productive teams.

00:17:44.760 Let’s talk about some useful tools in the Ruby ecosystem.

00:18:19.200 I want to start with God RB, which is excellent for monitoring processes on your server and taking action.

00:18:26.440 It offers reporting capabilities and can notify you via email if something goes wrong. More importantly, it can restart processes if they fail.

00:18:38.120 Here’s a basic configuration showing how to monitor four Mongrel instances, illustrating God RB's ability to effectively manage multiple tasks.

00:18:52.640 Through Ruby iterations, we can succinctly replicate settings across instances and define restart conditions for various performance metrics.

00:19:13.200 In practice, this looks like monitoring processes, managing memory and CPU usage, and providing notifications when certain thresholds are reached.

00:19:36.560 Another gem I highly recommend is Rufus Scheduler, which provides a great interface for scheduling tasks.

00:19:51.360 It can express various time formats, allowing you to specify when and how often certain processes should occur.

00:20:14.880 Rufus Scheduler can convert cron syntax while simplifying the testing aspect of scheduled jobs.

00:20:31.400 There are also gems that are useful if you're operating within the Amazon ecosystem, such as the RightScale gem, which provides effective management capabilities.

00:20:47.920 This gem integrates with various APIs needed for cloud management, giving you control over queues, servers, and storage.

00:21:06.640 For deployment, most people are familiar with Capistrano, but alternatives like Vlad the Deployer can be easier to use, especially if you're already comfortable with Rake.

00:21:24.520 Because it builds on familiar concepts, you might find Vlad is a simpler solution for managing deployments.

00:21:39.520 Nevertheless, there will always be scenarios where you need to write custom glue code yourself to get specific tasks done.

00:21:55.360 Let me show you an example of a plain Ruby script designed to wrap around Amazon's command-line tools for launching instances.

00:22:12.120 In this context, the script ensures that we don’t have to constantly remember image IDs to bring instances online.

00:22:25.280 The script manages launching, naming, and all required configurations for whenever a new server comes online.

00:22:40.360 We can associate domain names at launch time, allowing staging environments to mirror production environments with minimal changes.

00:22:59.600 The core of this process is to launch instances while ensuring relevant configurations are applied right when servers become active.

00:23:14.320 We need to avoid cluttering our auto run scripts with unnecessary commands, focusing only on the essentials to communicate with the server.

00:23:32.920 While I haven't optimized this entirely, the core idea is to use simple tasks that can launch and provision servers effectively.

00:23:51.200 Let’s highlight some additional gems that can simplify cloud management, such as Pool Party for server provisioning.

00:24:04.560 In particular, Rush can enhance file system interactions and provide more expressive syntax for performing various tasks.

00:24:20.520 Finally, don’t overlook Rake, which is helpful for managing dependencies and scheduling tasks more reliably.

00:24:37.040 Using Rake tasks rather than one-off scripts can add more structure and maintainability to your code.

00:24:49.040 Many other cloud-specific gems exist that could offer manageability solutions worth exploring, like Rubber and Elastic Rails.

00:25:05.600 While I haven’t had firsthand experience, they might help streamline development as you scale.

00:25:19.120 Looking forward, I would love to see Ruby solutions for configuring firewalls, health monitoring, and log analysis, perhaps similar to what we’re doing already.

00:25:39.760 A more Ruby-centric approach to health monitoring, cloud logging, and backup systems would help streamline efforts while retaining focus on quality.

00:26:03.840 As for lessons learned, I would emphasize using gems and libraries more effectively, relying less on personal scripting solutions.

00:26:11.360 Writing more unit tests for the glue code would also help maintain clarity and reliability.

00:26:25.680 Finally, minimizing what goes into launch scripts could reduce complications during server boot time.

00:26:40.480 Does anyone have any questions? We have a bit of time left.

00:26:48.720 We do have a firewall on the hosts, which is stateful. For us, Amazon provides a packet filtering firewall that works effectively.

00:27:08.040 Though, if you wish to guard against advanced threats like SYN flood attacks, you’ll need to put additional solutions in place.

00:27:27.480 As our needs grow, considering a management layer on top of our current systems has become more appealing to maintain flexibility in operations.

00:27:44.480 At this point, having around six or seven servers starts to feel overwhelming; a capability to better manage demands simplifies operations.

00:28:07.080 When managing multiple servers, we find that costs increase, but achieving stable operations makes that investment worthwhile.

00:28:24.720 Using flexible solutions allows us to optimize how we process incoming requests and manage resources more efficiently.

00:28:39.180 As outlined, our infrastructure ensures data integrity, enabling a more robust operational environment for our users.

00:28:58.440 Ultimately, building redundancy is key when utilizing cloud solutions for crucial applications.

00:29:05.680 So, if you’re designing cloud-native applications, remember to implement robust error handling strategies that manage tasks in a loosely coupled environment.

00:29:40.720 In conclusion, this has been a useful framework for us to adhere to, and we've generally been pleased with the capabilities that cloud solutions bring.

00:29:54.880 Thank you for your time. If you have further questions or would like to connect, don't hesitate to reach out. I’m excited to share more about our experience in the Ruby ecosystem!

00:30:11.840 We’ve been fortunate to work in a great environment in Austin, so if you're interested in a productive, flexible workspace, let’s talk!

LoneStarRuby Conf 2008