[xcskier56]

Microservices make sense from a technical perspective in startups if:

- You need to use a different language than your core application. E.g. we build Rails apps but need to use R for a data pipeline and 100% could not build this in ruby.

- You have 1 service that has vastly different scaling requirements that the rest of your stack. Then splitting that part off into it's own service can help

- You have a portion of your data set that has vastly different security and lifecycle requirements. E.g. you're getting healthcare data from medicare.

Outside of those, and maybe a few other edge cases, I see basically no reason why a small startup should ever choose microservices... you're just setting yourself up for more work for little to no gain.

[Scarblac]

Splitting off a few services from an application is not the same as using microservices. With microservices you split off basically everything that would be a module in a normal application.

[xcskier56]

I think that really depends on your definition. But I will also contend that even splitting your system into 2 or 3 services if it's not for strong reasons will 100% slow you down and cause long term headaches.

One project that I helped design had to split out a segment of the system b/c the data was eligibility records coming from health plans. This data had very different security and lifecycle requirements (e.g. we have to keep it for 7 or 10 years). Splitting out this service simplified some parts but any time we need to cross the boundary between the 2 services, the work takes probably twice as long as it would if it were in a single service. I don't think it was the wrong decision, but it the service definitely did not come for free

[codr7]

If you split off a small, isolated part of the application; that's pretty much the definition of a microservice.

[shooker435]

In addition to having 1 service with vastly different scaling requirements, having 1 service with vastly different availability requirements may make sense to separate as well.

If you need to keep the lights or maintain an SLA and can do so by separating a concern, it can really reduce risk and increase speed when deploying new features on "less important" components.

[Akronymus]

I personally wouldnt even call those microservices, but rather treat them closer to how a DB server is usually separate from an application one.