Practical Microservices with Ruby

(Coming out later in 2014)

What's a typical Rails app?

If you are visiting this page, chances are, you have a Rails deployment. It's also likely that the app is a typical Rails-style monolith, which does a lot of things—and every piece of functionality (component), however distant and unrelated, is sharing the same code base: authentication and user management, billing, notifications, and a great deal of other things.

Adding new features is painful!

In a monolith, every aspect of the app depends on everything else. This means adding an innocent-looking feature can lead to unexpected problems in totally unrelated parts of the program.

The boundaries are blurry and it's hard to get a simple mental picture of the system architecture—i.e. what pieces of code belong to a particular component and how they interact with each other.

New hires too will have a hard time grasping the architecture, and they'll have to understand how everything works before they can start working on a particular feature.

Scaling a giant…

With a monolith, every distinct component is locked up in the giant.

You can't use a more appropriate technology for a specific component. If your API is Rails, your data analyzer or NLP will be in Ruby as well, even if some language is more suited for this purpose (performance, better libraries).

You can't scale components up and down on demand independent of each other.

Sounds familiar?

If these problems sound familiar, maybe too familiar, don't worry. There is a solution.

OK, what are microservices?

The microservice style is an approach to developing a single application as a suit of smaller services, each running in its own process and communicating with lightweight mechanisms like HTTP.

The services are built around business capabilities and are deployable and scalable independent of other services.

The services can be written in different languages where appropriate. With microservices it is also possible to have different teams working on different components of the application.

Microservices aren't all or nothing. You don't have to apply this approach to its extreme to start taking advantage of it.

What does Practical Microservices cover?

The book will explain microservices in more details. It will showcase how common Rails app features would be handled in a service-oriented design, as well as tell about the gotchas.

Because it's not just a book about microservices, but a book about practical implementation of microservices, it will cover things that other books didn't. Specifically, development environment setup, deployment to cloud platforms and own servers, and service discovery mechanisms.

It will cover things like:

  • The drawbacks of monolith approach
  • Microservices: what and why
  • Transitioning a legacy app with an example
  • Doing microservices from scratch with an example app
  • Sync and async communication between services (HTTP REST, RabbitMQ)
  • Handing failure
  • Service discovery
  • Development environment
  • Deployment to cloud platforms like Heroku and to own servers
  • Polyglot services

About Gosha Arinich

Gosha is a polyglot software developer. For the past few years he's been freelancing and occasionally contributing to some open-source projects.