All posts by jlebrijo

Ruby on Rails scalability with Kubernetes

One of the bigger fails pointed to Rails is its scalability problems due to the overhead of the framework, and mainly, to the use of Ruby, and scripting language. It makes Ruby slower than compiled languages, but it can be scaled horizontally adding servers (or containers in Kubernetes case).

We can mount a Deployment pipeline with Kubernetes and Docker for a Rails project. All the process is detailed in this CoderHourney play list.

GraphQL vs REST APIs

The only advantage I see of GraphQL over REST is the ability of specifying the fields returned in the response. It can save a lot of sequential calls which slowdown the frontend responsiveness.

With Ruby on Rails there is a way that can be easily used to create this advantage over a REST API. We can use the as_json serializer:

  • We can make a call with query parameter like this: /users?query=”include: { posts: { include: { comments: { only: :body } }, only: :title } }”
  • In the controller we could return: user.as_json(params[:query])

This is an idea to improve your REST API, but in Rails we can make a fully GraphQL API with graphql gem.

Configuration Management

We create Ruby on Rails Web Applications, mainly in several environments, so that is really important not only the automated Deployment for us, but the automated installation (Configuration) also. For Server side, we use dedicated Ubuntu LTS Systems, on the usual providers: AWS, DO, Linode …

We use Capistrano for automated deployments, and we searched years ago for a tool for Configuration Management. We were evaluating all market possibilities: Chef, Puppet, Salt, Ansible …. And finally we decided Chef for a reason: We know ruby so writing recipes in ruby was a big advantage.

But working with Chef Solo we found several limitations:

  • Need to install Chef Agent in node, which makes the process heavy.
  • You need to run all tasks on every setup command, it delays debugging tasks.
  • Debugging errors are a hell, there is not a clear help for errors. Indeed the documentation is sometimes poor.

Probably regarding that situation Ansible server agent-less promise would be the best option. But I found several inconveniences:

  • Language based on YAML, really verbose (try to install a big list of packages)
  • We would lose ruby for writing recipes.
  • Working with environments/roles is not really standardized.

What do we really need?

  • Write recipes (scripts) in Ruby, in our well-known and loved language.
  • Agent-less server side. Solve everything with an ssh connection.
  • Work with variables.
  • Work with environment/roles variables and configurations.
  • Work with templates for configuration files.

Chef, Ansible, Salt … Are really powerful, but:

  • Do we need OS compatibility? No, we use Ubuntu LTS versions.
  • Do we need complicated idioms? No, we have ruby and Shell scripts.
  • Do we need Warehouses or Galaxies of recipes? well … yes, they are useful, but sometimes they are solved with a shell script.

Sometimes, the solution is the easiest way. Shell scripting ? near, but what about ruby, variables or templates …. Capistrano 3:

  • Based on Ruby rake tasks.
  • Only SSH connections, based on SSHkit.
  • Working with roles, environments and variables out of the box.
  • We know the tool because our deployments are based on this.
  • We will integrate the standard recipes into our prun-ops gem.

Yes, we need templates, but we have ERB in Ruby, and googling a while we can find an easy solution for templating.

Today our analysis gives Capistrano 3 as the best way to go, tomorrow … who knows?