This practices work better for medium or large companies. So if you have less than 6 developers working on your system, it is not the time to leverage microservices.
- Model the domain first. This way, it will be possible to develop small applications that depend on each other minimally. Domain-Driven Design (DDD) can help with that.
- Each application should have its private tables. A shared database would bring a lot of complexity in terms of transactions and locks.
- The front end should also be considered when planning an architecture. This is where micro frontends come into play.
- Continuous Integration/Continuous Deployment (CI/CD) is vital to control such a vast ecosystem of applications.
- With several applications, it's complex to be aware of everything happening in those applications. To facilitate problem investigation and better decision-making, it's crucial to access logs, monitor statuses, and measure the speed of communications between services.
- Only use different technologies in a group of microservices when there is a clear advantage for doing so. For example, if many applications are using Java + Spring and you use Python in a machine learning-heavy application.
- Microservices should be as independent as possible. If communication between them is synchronous, performance problems and cascading errors will arise. To avoid this, communication should be asynchronous, for example, through queues or asynchronous REST.
- If a system has a future need to become a microservice, start it as one from the beginning. Transforming a monolithic application into microservices will cause much more work.
- Don't become dependent on libraries. In the near future, there may be technology or demand that makes libraries outdated.
- Consider the organization that owns the application. Creating a microservice is of no use if the team is not sufficient or there is no funding to maintain all the services.