7 comments

[ 3.2 ms ] story [ 24.7 ms ] thread
This seems like such a saner way to achieve modularity/boundaries rather than using Microservices.
I agree that using microservices to solve the boundaries issue alone may prove costly.

However, microservices should exist to solve other issues as well.

Microservices are a thing that many companies implement way too soon, in companies that are way too small. It's a tool for managing complexity when you have hundreds of engineers, yet you'll see teams with a dozen engineers using the design. They'll point out "Uber does it!" forgetting that early on Uber was a typical monolith.
Agree with this. Imagine how hard it is to maintain just one service? Now multiply this by the number of your Microservices. Change to Microservices should come naturally when the org need it, for example when teams in a different functions start to fight to merge their changes to the monolith.
Would be interested to hear whether they consider moving some parts to Elixir that is mentioned in the post. It would appear as a very good match for their situation and problems they are facing.
Highly unlikely. And as you may have read in this article, this isn't about "moving parts" but making the monolith itself more modular. The monolith is close to 3 millions lines of codes last I read, and they don't want a micro-service architecture.

Also - would Elixir have really scaled 3 million lines of code that easily? Maybe Shopify would have gotten the "Umbrella app" from Elixir for free but would have had to implement a tons of other functionality themselves. I read over and over Elixir has missing libraries. If they went the rewrite in different language route I'd argue something static like Java is a much more sensible fit for this specific problem than Elixir.

> Packwerk enforces boundaries between packages through a check that can be run both locally and on the CI pipeline. To perform a check, simply run the line packwerk check. We also included this in Shopify’s CI pipeline to prevent any new violations from being merged into the main branch of the codebase.

that seems cool - in our project's gitlab ci pipelines we could implement them with ease.