4 ms·

What if you expect the team of 7 to grow to 20 or more.. In a larger context almost any company would hire more developers if they could find them and hire them

What if you expect the team of 7 to grow to 20 or more.. In a larger context almost any company would hire more developers if they could find them and hire them.

bigiain 9y ago
Premature optimisation... YAGNI is almost always the right approach.
- scarface74 9y ago
  I don't think you should always go with a microservice approach first, but you should always separate different domains/features into well defined modules/projects even within a monolith. There have been plenty of times where I've taken a project out of a monolith and created a separate shippable package to be consumed by another monolith in a separate repo. There were also occasions where I had to rip out a feature in a monolithic API that either needed to scale independently or be released independently and then just created a facade in the originally API that proxies the "microservice".
  - bigiain 9y ago
    Completely agree. I mostly tell my people "We aren't going to do that yet - or possibly ever - but keep in mind that we might have to if we ever win the user growth hockey-stick graph lottery, so when choosing between options of how to architect things, prefer very narrow focus that _could_ be pulled apart into microservices more easily if practical" I've also been known to stand up duplicated instances on a monolith with path routing on the load balancer as a "pretend microservices" scaling or upgrade trick.
bonesss 9y ago
Those growth points, and their associated market knowledge and budgetary constraints, would become perfect transition points into a friendlier architecture for the team... Plan for change, moreso than trying to plan against change. Decomposing and fragmenting an established service into smaller clones of itself should be reasonably straightforward. In most languages with a component story (ie java), library reuse across microservices should make your service architecture orthogonal to your application logic. This kind of approach also eases a lot of pain of cross-service issues.

What if you expect the team of 7 to grow to 20 or more.. In a larger context almost any company would hire more developers if they could find them and hire them.

bigiain 9y ago

Premature optimisation... YAGNI is almost always the right approach.

scarface74 9y ago
I don't think you should always go with a microservice approach first, but you should always separate different domains/features into well defined modules/projects even within a monolith. There have been plenty of times where I've taken a project out of a monolith and created a separate shippable package to be consumed by another monolith in a separate repo. There were also occasions where I had to rip out a feature in a monolithic API that either needed to scale independently or be released independently and then just created a facade in the originally API that proxies the "microservice".
- bigiain 9y ago
  Completely agree. I mostly tell my people "We aren't going to do that yet - or possibly ever - but keep in mind that we might have to if we ever win the user growth hockey-stick graph lottery, so when choosing between options of how to architect things, prefer very narrow focus that _could_ be pulled apart into microservices more easily if practical" I've also been known to stand up duplicated instances on a monolith with path routing on the load balancer as a "pretend microservices" scaling or upgrade trick.

bonesss 9y ago

Those growth points, and their associated market knowledge and budgetary constraints, would become perfect transition points into a friendlier architecture for the team... Plan for change, moreso than trying to plan against change. Decomposing and fragmenting an established service into smaller clones of itself should be reasonably straightforward. In most languages with a component story (ie java), library reuse across microservices should make your service architecture orthogonal to your application logic. This kind of approach also eases a lot of pain of cross-service issues.