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!
