I’d love to hear from more people who just don’t use micro services at all and vertically scale Elixir/Phoenix

The only sane microservice amalgamation I worked on was with Elixir/Phoenix. It was event driven and that was the key. I think event driven microservices are an extemely powerful architecture but it’s still the early days for them until we can get really good open source support for replays, sectioning off events from a period, and lots of utilities like that as well as figure out all of the best practices.

I’ve built monoliths but never at scale, but don’t see why they wouldn’t have scaled incredibly well. I have built macroservices that have scaled super well (5ish services IIRC).

having built my own startup in elixir/phoenix, i'd have to agree.

I think it comes down to how you define a microservice/monolith. when it comes down to codebase, our codebase is very much a monolith. however elixir lets you connect nodes together and setup individualized processes that can be communicated with by any other node in your network toplolgy using the BEAM's built in pubsub system. in essence, creating a new microservice is easy. you just define a geneserver file and add it to your application.ex. about as much effort as adding a controller in rails and that makes a big difference. you get a lot of the advantage of microservice architecture where you spread computation across your physical machines but the codebase is a small easy to maintain monolith.

This is my life these days :(

From experience this happens just as often inside monoliths.

It's a symptom of over-engineering and building for the future rather than anything inherent to microservices. Java had a whole decade of being obsessed with design patterns e.g Facade, Decorator that resulted in the same spaghetti architecture.

Microservices invite over-engineering more than monoliths do. Monoliths are more prone to inviting a lack of a structure. That’s kind of…a big potential advantage of microservices, I guess.

the theoretically nice thing about microservices is that because the API boundary should be well defined, any possible application that can fulfill that API, whether it's Java, Rust, or three raccoons in a trench coat can become the new microservice fairly easy.

All we have are three raccoons in a trashcan, but you'll be able to fit this in the current sprint, right?

The problem with that. Maintenance. Team X writes a micorservice in Node. Team A->W write in elixir. Bug in Micro_X and tada... company is screwed. No one wants to learn Node, so the bugs stay around, get worked around and then Micro_X gets re-written in elixir, because coders have to fix stuff.

That is painfully accurate. My usual response to it is https://despair.com/products/break-the-rules

It usually gives me angry looks at first, but thanks after several years when there's enough turnover.

Terrible engineering is also possible in the monolith, it’s just significantly harder to rewrite sour bits of monolith independently.

That's why moduliths are becoming more popular. These are basically monoliths that enforce structure. The other advantage is that each "module" can be extracted as a micro-service later without much work.

At least with a monolith, all of your ball of mud is in-process.

The pinned comment on that video is from 4 years ago:

>I'm a junior backend developer and this inspires me a lot to study frontend

I always find watching this video surreal because I worked on a microservice called Galactus

For some reason that video's genius reminds me this, https://m.youtube.com/watch?v=b6LKNTJN3Ug