4 ms·

Yes but bear in mind successful companies do grow and you are then frequently stuck with the startup type choices made early on because "now it's too late" - ev

by gedy 5y ago

Yes but bear in mind successful companies do grow and you are then frequently stuck with the startup type choices made early on because "now it's too late" - even if it just due to original small team now being the tech leadership and know no other way. Been at a 30 team company working on an old Rails monolith and it totally sucked.

lexx 5y ago
Yeah, I get that and it happened to me too. That can happen in any design though. Even with a microservices approach. As I said in the previous comment, you have to design your way out of the thing you are building. Not easy at all, and sometimes, not possible to predict. I mean successful companies do grow, but a lot of times they pivot, etc.
deleted 5y ago
[deleted]
bcrosby95 5y ago
A well architected monolith isn't necessarily that different from a well architected set of microservices. The problem with rails is it encourages you to not think about your architecture, and after years of putting every model, controller, or view in literally the same folder, you have a giant pile of shit. Modularize by feature. And under each feature, you modularize by layer. Slicing your code N ways will scale better with your team than slicing your code 3-4 ways.
- DeathArrow 5y ago
  >Modularize by feature. And under each feature, you modularize by layer. Sounds like Vertical Slice Architecture combined with n-layer or onion architecture.
  - bcrosby95 5y ago
    > Vertical Slice Architecture I didn't realize it had a name like that. I've always just called it "package by feature" (Java). Been using it for over 10 years at this point.
DeathArrow 5y ago
Like Twitter and their Ruby problem. But it's not an issue. If you chose tech X because it was the easiest way for the small team to produce an working prototype, when you find success, you might afford to rewrite using tech Y like Twitter switching to Java or alternative approaches like Facebook doing their own PHP version. It's not like being microservice based and modular from the start will save you from rewrites and architecture rebuilds. Google rewrote parts of their services and modified their architecture hundreds of times. Of course, if the architecture is modular, rewrites and architectural changes are easier.

by gedy 5y ago

lexx 5y ago

Yeah, I get that and it happened to me too. That can happen in any design though. Even with a microservices approach. As I said in the previous comment, you have to design your way out of the thing you are building. Not easy at all, and sometimes, not possible to predict. I mean successful companies do grow, but a lot of times they pivot, etc.

deleted 5y ago

[deleted]

bcrosby95 5y ago

A well architected monolith isn't necessarily that different from a well architected set of microservices. The problem with rails is it encourages you to not think about your architecture, and after years of putting every model, controller, or view in literally the same folder, you have a giant pile of shit. Modularize by feature. And under each feature, you modularize by layer. Slicing your code N ways will scale better with your team than slicing your code 3-4 ways.

DeathArrow 5y ago
>Modularize by feature. And under each feature, you modularize by layer. Sounds like Vertical Slice Architecture combined with n-layer or onion architecture.
- bcrosby95 5y ago
  > Vertical Slice Architecture I didn't realize it had a name like that. I've always just called it "package by feature" (Java). Been using it for over 10 years at this point.

DeathArrow 5y ago

Like Twitter and their Ruby problem. But it's not an issue. If you chose tech X because it was the easiest way for the small team to produce an working prototype, when you find success, you might afford to rewrite using tech Y like Twitter switching to Java or alternative approaches like Facebook doing their own PHP version. It's not like being microservice based and modular from the start will save you from rewrites and architecture rebuilds. Google rewrote parts of their services and modified their architecture hundreds of times. Of course, if the architecture is modular, rewrites and architectural changes are easier.