Some tips based on my experience in a large project (30+ microservices, 70+ devs): DX - In cases where you have many microservices, running them all locally for development would rarely be possible. Devs would need beefy laptops to be able to run all the services, and you would also run into the issue of having different setups (eg. docker-compose) for local development and production (eg. kubernetes), which will get exponentially harder to keep in sync as you introduce more and more services and infrastructure pieces. Best approach for this (but pricy) would be to have on-demand remote environments, ideally running inside of kubernetes (or your platform of choice), in which case you eliminate most of the "works on my machine" problems, by having the devs work on the setup that's closest to production. As a bonus with this approach, you also get the benefit of being able to provide on-demand environments for QA/Compliance teams, or for any other purpose, without much effort, since it uses the same logic. Microservices - Please use kafka/rabbitmq/nats (or alternative tech) for communication between services, as opposed to having direct communication. This adds decoupling to your architecture, and will let each service run at it's own pace. This is especially useful when APIs change (like in the example from the video) so instead of having to now update all services that depend on the one that changed the api, you would only change that one, and the way it communicates with the "message bus".
Great explanation 👌🏽. I would like to know if a startup developping a multi-tenant SaaS (around 100k users predicted) should begin with microservices architecture or just start with a multi-layer monolith architecture (frontend, monolith backend, single DB) ?
@@prosperzegue6735 It really depends on your case. For example, if your team never worked on microservices, choosing to do so from the start will add unnecessary complexity and slow you down. You will inevitably have to go the microservice route with that scale, but starting with the monolithic approach and then slowly breaking apart the monolith into different services is still a valid strategy. You can make this process easier by not tightly coupling your code. This can be specific to the tech/language/framework you choose, but you can still take measures to make moving away from the monolith less painful. On the other hand, if you're confident in your team and have prior experience with microservices, I don't see a reason to start with the monolith except for development velocity (only in case where your team doesn't have experience with the microservice architecture). Just be careful of the premature optimization pitfall, and don't over engineer your setup.
Great job explaining this architecture. One crucial piece that I see missing is your observability/ monitoring layer. I’ll add prometheus, grafana to collect app and infrastructure metrics. You can even spice it up a bit with jaeger for traceability. This will equip you with a feedback loop to extend your pipeline to do canary releases later on.
Ahh yeah good call. This was the second time I recorded the video and I forgot the observability part. Probably should have written it down instead of doing it off the top of my head.
4:40 im using bun and my microservices can consume shared packages from the package.json at the root of the project. So if i need to upgrade a package shared across all microservices i can just update the root package json
Very nice video Tom!. But I am worried about running all the stack in a developer machine. From my experience, even a resourceful a machine can run out of resources pretty quick running everything at once. Also, as you are targeting a micro services architecture for the backend, how about using micro frontends for the web? It can enhance the work of several teams working separately in the same frontend. I also understand that micro frontends also facilitates to ship often.
I don't have any experience with micro frontends, from my understanding they sound good in theory but are a nightmare to work with. I think there's a way to get the whole thing running on Dev's machines, or at least the parts they need
Hey there. If we are using any other backend then do you think we could leverage proper type safety?? Like at that point it just becomes manually typing it out...
Or you can just deploy LOCALLY if your target audience requires strict data privacy, has unreliable internet connectivity, or needs low-latency access to critical systems, such as in healthcare facilities or remote locations.
