Service architectures in Ruby, you say? Certainly services can only be built in languages like Java and Go, and require elaborate messaging transport and mass-scale storage solutions that only the biggest teams and companies can afford!

Of course, none of that is true. And it should be pointed out that the exact same things used to be said of web app development between 1997 and 2007, and especially of MVC and ORM—both of which were considered only suitable for advanced developers. It was true until—predictably—these things were democratized by tools like Rails, and its many clones on numerous platforms.

Autonomous services, evented services, service-oriented architecture, microservices, and event sourcing are architectural styles, and architectural styles are completely unrelated to specific technologies used to implement them.

Service architectures are no more “natural” to a given language or runtime than web apps are. But there are tools, and they may be more approachable or less approachable, or a better or worse fit.

Eventide makes service development as approachable as Rails made web development in 2006, and seeks to democratize this as-yet esoteric subject that, at the moment, tends to be calcified under a thick layer of popular myths and fads.

So, let’s talk about why you would implement service architectures in Ruby, and with Eventide.

1. You’re a Ruby Developer

This one is a no-brainer. You’re already a Ruby developer. You have Ruby skills and fluency. You’ll be at a disadvantage for a spell while you gain fluency and experience with service architectures, but at least you won’t have to do that while simultaneously trying to become a competent developer in an unfamiliar language.

2. You Work in a Ruby Shop

Your company has business logic assets built in Ruby, probably in Rails. There is no short cut to porting a monolithic web app to an evented and autonomous service architecture, but having the existing business logic implementation in Ruby will make moving it into service components that much easier. You already have a frame of reference that you already understand, and the value of that can’t be understated when making the journey to a new architectural style.

3. It’s a Boost for Your Career

A senior developer working in a Rails shop sooner or later bumps up against a kind of — glass ceiling — an arbitrary limitation on how far you can go in the Ruby ecosystem. Those developers tend to reach for the ejection handle and punch out to ecosystems and opportunities that don’t appear to have the same limitations.

The next logical stage in a senior Rails developer’s career is a move toward reliable and robust back end systems based on tried and true autonomous and evented service architecture techniques and patterns.

Eventide replaces the tedious legacy ORM app maintenance with the re-invigoration that comes with throwing yourself into a new learning journey, and opens the door to the opportunity to work at your maximum level of capability, and not be limited by the frustrations of the app that you’d rather divorce yourself from.

You can blaze a trail forward not only for your career, but also for your co-workers and colleagues, ensuring that they too will not be limited by the glass ceiling.

Eventide rolls out the red carpet for the next steps on your career journey. As a bonus, the Eventide community will support you along the way. You’ll learn a lot, and there are people who want to help you get there!

4. Don’t Change Language and Architecture at the Same Time

Changing programming language and architecture at the same time is the riskiest and most failure prone kind of project in the annals of software development. It’s for this reason that managers are often reticent to go along with it.

The worst project you’ll do with a language is the first project you’ll do with a new language. It’s when you have the least facility with the language and when nothing about the language feels natural.

If you take on a project where you’re at your lowest level of capability with a language and your lowest capability with a new and alien architecture, you can effectively reduce your chances of success to a coin toss.

Cut your risk in half and build services in a language you’ve already mastered. You might even learn a whole new pile of new techniques and patterns from the Eventide implementation that you hadn’t already heard of.

5. You’re Not a Ruby Developer

Despite the warning to not change language and architecture at the same time, the particular language and the particular architecture can be factors, and sometimes they’re mitigating factors.

In 2006, the Java and C# developers who transitioned to Rails also transitioned to Ruby. But it was Rails that was the main attraction. The simplicity and joy of working with Ruby was a bonus.

You wouldn’t adopt Eventide because of Ruby. You’d do it because, as with Rails, Ruby allows Eventide’s implementation to cut away the distractions and the cruft and leave just the essence. Ruby is just a bonus — an easy to read language that allows service architectures to be brought down from the ivory tower and stripped of the esoteric incantations that keep all architectures from being democratized early in their histories.

As has been borne out in practice, moving to Ruby from other languages has proven to be one of the less arduous transitions a developer can make.

6. Eventide’s Message Store is Platform Agnostic

The core of Eventide is the message store. It’s just a data store. In Eventide’s case, it’s just a Postgres data store. A highly-optimized Postgres data store, but a Postgres data store, nonetheless. And for more massive scale needs, we also support the Event Store database.

At the most basic level, all it takes to integrate evented services written in other languages with services built in Ruby on Eventide is a language-specific Postgres client or an Event Store client. And there’s no shortage of those on the market!

Check out Eventide and get started on the next stage of your career in autonomous, evented services in Ruby:
https://eventide-project.org

Or, jump right to the docs and get your feet wet:
http://docs.eventide-project.org