[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

[Scarblac]

> 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.

Even tiny backends usually have, from the start, a database server, some web server / proxy to handle incoming requests and load balance or cache them, and then something running your actual code that requests are passed on to. That's so normal that we don't even think of them as separate services anymore, but they are.

[codr7]

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

[Scarblac]

Splitting off a few larger parts because they are self contained, have their own Ops characteristics and might be usable by other projects on their own, vs creating a service for every single entity in your domain modal (or whatever), that's quite a difference.

We have an auth service, a database service for raster geo data, a generic task runner. Those are services. They all have their own pretty unique architecture and stand on their own, they are used by but are separate from the project that they were made for.

Different services for customers, for orders, for invoices, for items in the shop, for items on an order, for promotions, that's microservices. They all look very similar and belong to the application.

(in my opinion this morning)

[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.