Seeking Advice: Deploying Monorepo-based Microservices + Alternative Architectures?

[trail perch]

New to microservices architecture and hoping to get some guidance.

Main Question 🚀
I'm working on a NestJS microservices application structured as a monorepo (using Nx/Turborepo) and need advice on deployment strategies. Specifically:

How to containerize (Docker/Kubernetes) interdependent services?
Best practices for CI/CD pipelines in monorepos
Recommended hosting platforms (AWS ECS, Kubernetes, etc.)
Managing shared libraries/env variables in production
Any gotchas or lessons learned from your experience?
Side Question 📚
While I'm committed to the monorepo approach for now, what other well-documented microservice architectures are popular with NestJS? I'm aware of:

Polyrepo (separate repos per service)
Serverless frameworks
Event-driven architectures
Hybrid approaches
...but would love to hear what works best with NestJS's ecosystem and has good documentation.
I've checked the Nest Microservices docs but would appreciate real-world insights. Thank you in advance! 🙏

[cunning bramble]

@trail perch - Um, I think you seem to be mixing things up a bit. Monorepos or poly-repos have nothing to do with microservices architecture.

Also, are you using Nx or Turbo repo?

Also, such a wide ranging question is often ignored here. The usual process is, you do your research and learning on your own, and when you come up with a specific technical question about Nest, you can ask it here and then you'll usually get a reply. Oh, and usually you should only ask one question per thread. Asking multiple questions, unless they are easy to answer, will get you silence here too.

[main elbow]

Your questions are packed and each one can have its own long thread about what to do. I've been through this before so I know how you feel.

I went from developing my mono repo locally in local dev servers, to having it fully deployed using docker-compose with 3 branches (develop, staging, main) with a complete CI/CD pipeline that builds, tests and auto deploys. There were alot of steps with a lot of gotcha's in between. Took me around 2-3 weeks to get it to a decent level (my experience level was a junior frontend dev)

I'd be happy to give you some pointers about it, but alot of it will depend on what you want to use since there are many options for each part. You can DM me and I can help point you in the right direction about where to start and what you need to do/know

The first steps you can take is go from simply running your applications locally to having them run locally within docker containers. Nestjs has documentation dockerizing a nestjs app.

[cunning bramble]

@main elbow - It's impressive you got all that done. Well done! It's just that, and I hope we can agree on this, but, Docker isn't a proper production environment for running containerized apps (despite it being a "how-to" in the Docker docs) .

Just to name a few missing features, Docker doesn't allow for native orchestration for high availability, self-healing or scaling. It has limited fault tolerance and has networking and security challenges. And, there is no built-in support for rolling updates. So, all updates cause downtime.

What I'm trying to get at is, if anyone thinks they have a good system running docker compose "in production", they'd be badly mistaken.

[main elbow]

Thanks for those insights! I really do appreciate. I haven't gone to production yet per se but I am close (have staging server up and ready). I was aware of many of those short comings, and it seemed to me like my deployment platform (Dokploy) takes care of most it, including zero-down-time deployments. It does runs docker swarm under the hood. I only started learning docker about a month ago, but is docker swarm a good choice for production environment?

[cunning bramble]

Docker Swarm and later "swarm mode" were built to take on the missing features of deploying a dockerized app in a better production environment. But, they lost a lot wind, once k8s came out. I'd say, for a smallish application, you can run with Docker Swarm in production. I'd just not be too thrilled by the ecosystem or the tools around it. Docker Swarm to k8s is like comparing Pluto to the Sun. 🙂

[main elbow]

For sure. I would've loved deploy with kubernetes too, seems just like my kind of platform. But I had time constraints and also I don't know if it was really worth going for it at the start. ~~If ~~Whenthe applications takes off I can scale it up to the moon with k8s (hopefully...)

[cunning bramble]

If anything, anyone just starting with getting an app going should be going with a monolithic approach and should avoid microservices. You can containerize a monolith too, right? And for sure, just for the start, using Docker Swarm to run the containerized app in production is perfectly fine.

[dapper ingot]

Thousands of projects use docker with docker-compose and its fine. What do you mean by "networking problems"? Some famous security troubles are easy to solve.
Moreover, if you wanna use one server and scale with it, you can just use docker-compose and traefik to load-balance container instances. The problem of downtime is also solved in NodeJS by pm2-runtime.

[cunning bramble]

@dapper ingot

Thing is, when you start to add your own load balancers, your own process managers, and any other tools like Keepalived for high availability, then you are getting very deep into infrastructure administration and away from development and very far away from the simplicity using docker compose is supposed be giving you. And, you are solving problems Kubernetes solves OOTB.

I can say this with certainty. Once you "get" k8s and can manage a cluster, then the simplicity of docker compose comes back to you. You have tools like Helm and "charts", which allow you to fire up any kind of application. Or, more simple yaml files for deployments are there too. But, you have a lot more power under the hood. A whole lot more! Not to mention all the tools available for everything from CI/CD, to secrets management, to monitoring and logging, networking, security, storage, other config mangement tools, service meshes, observability, policy management, development platforms, backup and recovery and more. k8s is THE standard for containerized orchestration.

What do you mean by "networking problems"?

By networking problems, I mean things like you mentioned, like missing load balancing, the need to manually manage ports, missing service discovery across hosts and general lack of network overlay management across hosts. That alone is a huge headache, once you need to scale out horizontally.

And, of those missing features I mentioned, networking is the least important for mission critical application deployment. The more important one is high availability. You mention load balancing of VMs. That's only a part of horizontal scalability. You also need tools to restart and report badly running processes in the VMs. By badly running, I mean, they are constantly freezing for some reason. Docker compose offers nothing for this scenario and thus, you'd have to manage another tool like Keepalived. Docker Swarm does have this facility, but the HA features in Swarm are less sophisticated than k8s.

As I also said, if you are willing to want these tradeoffs with Docker Swarm, then you can use it in production. I'd highly suggest though that just using docker compose in production is a mistake. It is NOT a safe production system. Just my opinion.