[m4l3x]

In my opinion implementing strong interfaces and good modularization is something, that we should talk about more, than doing Microservices. In the end it might be easy to rip of a Microservice, when needed, if the code is well structured.

[jerf]

This is what I do in practice. I've seen it called a "distributed monolith".

One of the good reasons to spend time with Erlang or Elixir is it'll force you to learn how to write your programs with a variety of actors. Actors are generally easy cut points for turning into microservices if necessary. As with many programming languages I appreciate not being forced to use that paradigm everywhere, but it's great to be forced to do it for a while to learn how, so you can more comfortably adapt the paradigm elsewhere. My Go code is not 100% split into actors everywhere, but it definitely has actors embedded into it where useful, and even on my small team I can cite multiple cases where "actors" got pulled out into microservices. It wasn't "trivial", but it was relatively easy.

[ravi-delia]

That's where a lot of the fun of Elixir comes from I think. It's viscerally satisfying to split off functionality into what almost feels like an independent machine that happens to be in the same codebase. It clicked in a way normal object oriented programming never did for me, I guess since it's not feasible to mint 10,000 genservers to use as more complicated structs.

[cultofmetatron]

haha I was thinking the same thing. The code base of my startup is a monolith but in reality its a fork on request webserver sending messages to a collection of genservers actings as services.

In essence, creating a microservice with elixir is about the same amount of effort as adding a controller in rails.

[baash05]

Yeah.. rails hits this same nail with jobs.. I use jobs in a synch manner, and it's great. It's a rather functional way of working within an OO world.

[fatnoah]

> In my opinion implementing strong interfaces and good modularization is something, that we should talk about more, than doing Microservices.

This is my position as well. Strong interfaces, good logical separation of function under the covers, etc. should allow splitting off things at whatever level of micro you prefer.

[alexvoda]

Indeed, the principal seems to often be forgotten. The why of monolith vs citadel vs microservices is ignored by some people.

This results in K8s-driven-development instead of microservices.

[baash05]

I love that sentence.