Hey, Ruby web developers! Having trouble asking deployment questions? Not sure what Provisioning or Orchestration are? Getting bad results Googling your questions, but not sure why?
Let’s go over some deployment vocabulary from your point of view — that makes it a lot easier to Google and to read information about deploying your app to a server, and setting up that server in the first place.
As a nice side effect, you may have an easier time talking to your Ops guy at work.
First, let’s go over what the word “deployment” means:
‘Deployment’ is the process of putting a new application, or new version of an application, onto a prepared application server.
If you are talking to a developer, it may also mean the process of preparing the server, perhaps by installing libraries or daemons. If you are talking to an operations professional, it DOES NOT. They use the word “provisioning” for that.
(Developers are going to keep using the word “deploy” for everything involved in getting our app and its dependencies installed. That’s cool. But don’t be surprised if you confuse your Ops guy.)
Hey, tech companies. Hey, engineers working at tech companies.
There’s a great post by Chad Fowler going around with a job description for an engineer we’d all love to work with.
He says he can’t find any of those engineers to hire. Spoiler: neither can your company. I’m going to tell you why not, and what it would take to fix it.
Are you deploying a Rails app? Here are lots of things you’ll probably have to watch for as you do… I’ve been writing an open-source gem and a for-pay online class about this for months now. Let me share some things.
There are lots of big reasons that deploying a Rails app is hard. And lots of well-known, big tasks. But when you’re provisioning a server and deploying your application to it, lots of little things go wrong too.
I feel like the big things get a lot of respect already. Let’s look into some of the under-appreciated little things you have to get right in order to make a good deploy happen.
For starters, a lot of these small issues can require a lot of debugging. You know those two-line fixes that take three hours to find? Deployment is full of those. Here are some of mine to speed you on your way.
All Things Great and Small
You can’t compile recent Ruby on a VM with less than approximately 1GB of RAM. The amount varies a bit, of course.
When you try, you discover that GCC gives an internal compiler error as its “out of RAM” notice. Also, that the RVM cookbook tells you a completely wrong directory for the six logfiles to check for errors. At least, if you install RVM in user directories.
If you’re new to Ruby on Rails, you may be new to the old debates (pro and con) about how “Rails doesn’t scale.” You might wonder why people say that, or where it came from.
Let’s talk about that.
As far as “Rails Doesn’t Scale”, the main arguments go something like:
1) Ruby is slow, often up to 50x slower than C, so the server will eventually collapse.
This isn’t actually a scaling argument. But it’s true that Ruby is slow. Not 50x any more, closer to 5x (up to maybe 20x), but still, that’s not terribly speedy.
Rails doesn’t help Ruby here. A lot of the metaprogramming techniques it uses are among the slowest things Ruby does. I wrote a book about how Rails uses those techniques called Rebuilding Rails. They’re awesome, but they’re not speedy.
In practice, Ruby and Rails apps often “farm out” the slow stuff. The database is the traditional place to put the heavy lifting, but you’ll see Redis and Cassandra used in similar ways. Want Ruby to be fast? Call to something that isn’t Ruby, and is designed for speed :–)
Pure Ruby is quite slow, but just as scalable as any other language or library. It doesn’t get somehow slower as you add more.
2) Ruby/Rails leaks resources, so large or long-running projects don’t work
There was once more truth to this. Ruby had a few leaks and Rails exercised Ruby like nothing else. Also, ActiveRecord encourages large amounts of garbage per request, which was easy to mistake for leaks.
I had the good luck to be an early reviewer of John Sonmez’s excellent book “Soft Skills: The Software Developer’s Life Manual”. So you get a review!
Soft Skills is a book like that — more career than communication skills, and especially a lot of very frank talk about how to promote yourself in your career. It also includes several other chapters of how to take care of yourself as you develop for a living; that means fitness, investing, and even morale.
Oh! And don’t miss the story of how he got the review, at the last minute, from Uncle Bob Martin. Even if you’re not a big fan of Uncle Bob.
This is powerful stuff, and stuff I’ve never seen another book teach. In fact, go read the chapter names in the table of contents before you come back. I promise, it’s worth your time. And the table of contents will tell you far better than I did just what the book is about.