Keep it simple!

Writing software is complex. You start a new project with all the energy and good intention.

First question:

"What technologies should we use?"

The usual answer:

We need microservices to be able to scale parts of the system independently.

Let's see the implications of running microservices.

To run the microservice we need a Kubernetes cluster (of course). Each service should have its own data store. So let's use a managed database service like Mongo Atlas to be able to create and run lots of independent databases.

The services need to talk to each other. Let's use grpc or better Kafka Streams, so the future Data Science team we may hire can consume the event streams.

Since we'll have lots of services to manage, we need to establish centralized logging early and think about the traceability of requests across the system. Lets' introduce correlation ids, which we pass in all our service calls. For logging, we introduce Kibana, Graylog, or similar log management services.

Our frontends are for sure micro and written in React. Are there even other options today? Since we have lots of logic in the front end we need something like sentry, to get a picture of the client-side issues.

We don't want to run our own Kubernetes (K8s) Cluster, though let's use something managed like AWS EKS.

To deploy all those microservices (we'll have 10+ for our Minimal Viable Product (MVP)), we need to standardize our build pipelines.

We haven't decided yet if we want monolithic git repositories or better use one repo for our service.

Since we have a small team and all members are working on all microservices, we want to make sure, that they are all in a way standardized. With standardization, we reduce the onboarding time for someone working on the service for the first time.

You might want to use tools to ensure consistency across your codebase. So let's think about how to share the configuration across the microservices.

Now, let's hold a bit and think about what we did so far... why do we need microservices again?  They don't come for free. We added lots of things to our technology stack to be able to manage the complexity.

The Product Management team is wondering why it takes months to deliver the MVP. Do you remember the initial functional requirements? - or got you already lost in all these fancy "must-have" technologies?

After shipping the MVP with some delay, and successfully scaling it, you realize that your cloud costs are exploding with all the managed services and instances required to run the clusters. But you are internet scale ready - in theory!

Don't get me wrong, all these technologies have their place and are uncertainly a great choice in lots of cases. But please don't make them the default response. Especially for small teams and systems, the additional complexity is usually not worth the afford.