Rails. Fucking rails...

God damn monoliths, built by a cowboy coder.

Every one I have ever worked with becomes (or already is) a house of fucking cards that will blow over at the slightest gust of wind.

The worst part is that you always hear the same justifications from rails developers, then after they convince the higher-ups that “we will build it right, not like those other monoliths” we find ourselves F’ed right in the A a few months later.

It’s this frustration that lead me to MUCH better paradigms like Microservices, Event-Sourcing, CQRS, Domain Driven Design and the like.

When someone says “our backend is in rails” my first response is “so when are you replacing it?”

is it Ruby on Rails?

@wowotek Yes, that’s why I was referring to. Good point to bring up since there are a number of different “rails” out there.

RoR is great for a side project or a simple application. For complex domains I have seen only headaches.

@leanrob what makes it not suitable for complex task? is it unmaintainable?

@wowotek That’s a pretty big question to answer but there are a few quick points I will mention.

1. Speed of development is fast, this looks like a good thing, until you get a junior developer in there cowboying, looking productive while screwing everything up.

2. Lack of flexibility, lots of standard thing like router, DB migrations come out of the box. So they are good for standard usages but if you want to go beyond that it is a mess.

3. Super high cost of early development mistakes. They compound quickly and are not easily fixed.

4. Too much “magic”, so many things in rails are just magic. They happen and then no one on the team understands the internals. Again, great for a simple and standard app. But when the magic doesn’t do what you want it to then who fixes the magic? A magician?

That’s just a few off the top of my head.

@brano88 No. It is not.

Note. I’m not talking about all the articles saying “Break your monolith into rails Microservices”

I’m also NOT talking about SOA (Service Oriented Architecture).

Most people’s ideas of what Microservices are turn out to be complete nonsense, sadly.

@brano88 Also, here is a pretty good book about microservice best practises.

If you can handle the sometime broken English of a non-native English author. Sometimes it can be hard but the concepts, tech and code in this book are on point.

https://packtpub.com/application-de...

<Not and ad>

@brano88 Ah, a problem I have encountered before.

This issue is mitigated (if not solved) with the use of an event driven system.

This way, your Microservices to not actually “subscribe” to something being “published” by another service. All inter-service communications are done through an event store.

For example....

My user service send an event “userCreated” to the event stream.

But I want emails to be sent out to multiple people when they join (member, admins, etc.) so I have those services watching for the events with that name and then my other email service can handle whatever it needs without having to worry about who published the event.

The main issue with this is that it is “eventually consistent” because of the need to handle the stack of event is a synchronous fashion.

Badly designed Microservices should be avoided at all costs, I agree with that.

However, a well designed, event-driven system can offer things like...
- complete audit ability
- on the fly read model generation
- the system can be completely rebuilt using the event stream

A great example of this is Netflix.

The problem is that building good Microservices takes a LOT of deliberate planning and knowledge. The exact opposite of Rails.

I would encourage you to take a look at that book, it’s very helpful in understanding how to build Microservices that aren’t shit.

@brano88 I see.

Then I guess I am confused about the previous is comment. From what I see all of the complexities you describe are not “accidental” but very deliberate complexity that (if built correctly) can build a resilient system.

- system can distribute messages multiple times.
— this is very deliberately done is that one event can have the proper effect on multiple Microservices without each service having to rely on each other.

- system can not distribute a message at all
— if the microservices are in control of what event topics they subscribe and keep track of the index of events they have already built into read models then this should never happen.

- lose message during distribution
— as long as the event store (such as Kafka) is not destroying events this should never happen. Not that events should be kept forever but they should be kept for long enough that the consistency of read models can be confirmed. If your referring to network calls failing to generate events then this is a possibility in any system that needs an internet connection.

But really I’m more curious about what alternatives you would recommend for high-reliability, highly scalable system?

Debate about architecture is usually a good thing.