Don't start with microservices – monoliths are your friend

Selling effectively is the most important factor, not speed. Speed is second as a factor (and obviously very important). That's actually what you're describing when you say success of a product is not correlated to how well it's engineered. It's correlated to how well you can sell what you have to the audience/customers you need. That's why some start-ups can even get jumpstarted without having a functional product via pre-product sign-ups and sales. Getting to selling as reasonably quickly as you can, in other words.

Go when you have something to sell. That's what the MVP is about.

Which also isn't the same as me saying that speed doesn't matter - it matters less than how well you sell. It's better to sell at a 10/10 skill level, and have your speed be 8/10, than vice versa (and that will rarely not be the case). Those are bound-together qualities as it pertains to success, so if you sell at 10/10 and your speed is 1/10, you're at a high risk of failure. Give on speed before you give on selling and don't give too much on either.

Works well and it actually simplifies things a lot, each service has its repository, pipeline and permissions, developers don't need to understand the whole application to code.

You also don't have to start with Kubernetes to make microservices work, many tools can act as in-betweens. I am using app engine from gcloud, yes it's a lot of abstraction over kubernetes and it is overpriced, but I don't care. It works perfectly for these use cases and even if overpriced, it stays a low absolute value.

The caveat is that you really need to start off with a "stateless mindset".

Microservices is an organizational optimization. It can allow one team to manage and deploy their own subsystem with minimal coordination with other teams. This is a useful thing, but be aware what it's useful for.

If each of your developers manages a microservice, that probably reflects that you do no actual teamwork.

We are a young startup in the ML-service space, with about a dozen engineers + data scientists. Our stack is based on all docker containerized python. We have 6 "micro"-services (not sure at which point they become micro) but each plays their own role, with ~4-30 REST endpoints each. It's been fantastic, and none of us are particularly experienced with microservices. We run on AWS east but you can spin most of the stack up locally with docker-compose. I don't even need k8s, if we wanted, we could probably deploy a local cluster with docker swarm.

- Fault isolation

I can't talk in depth but we were able to handle the recent east-1 outage with only parts of the stack degraded, others stayed functional.

Also, rollout is most likely when something will fail. Rolling back a services is way easier than disrupting the whole stack.

- Eliminating the technology lock

The ML container is a massive beast with all the usual heavy ML dependencies. None of the other containers need any of that.

- Easier understanding

Yep, definitely true in my experience. The API surface area is much smaller than the code under the hood, so it's easier to reason about the data flow in/out.

- Faster deployment

We can easily patch one service and roll it out, rolling out hotfixes to prod with no disruption in the time to run through the CI pipeline, or roll back a task spec, which is near-instant.

- Scalability

Emphatically so. The difference in scale between our least and most used service is over 100x.

We could probably get away with making the user-facing backend a monolith (and in fact it's the most monolithic, has the most endpoints) but for data pipelining, micro/"milliservices" has been a dream. I don't even know how it would work as a monolith.

As with everything in this field, it all depends on use-case and tradeoffs. If your services each handle roughly the same load, the independent scaling argument weakens. If your business logic is complex, tightly coupled, and fits on a single box, you'll waste a ton of cycles just communicating.

One code base is something I totally agree with. I would like this to include every dependency, at least the OSS once.