Don't start with microservices – monoliths are your friend (arnoldgalovics.com)

Article summary

The article discusses the potential drawbacks of starting a new project with microservices, arguing that monoliths can be a better choice initially. It highlights the complexity and infrastructure requirements of microservices, including the need for multiple compute instances, databases, and messaging systems. The author shares their personal experience with a project that had 80+ microservices, which led to slower deployments and more potential faults. The article concludes that while microservices can bring value, they come at a cost and may not be the best choice for every project.

Main themes

• microservices vs monoliths
• infrastructure complexity
• deployment strategies
• code architecture
• latency and performance
• authentication and monitoring

What commenters say

• Microservices add unnecessary complexity and latency, making monoliths a better choice for many projects.
• A well-designed microservice architecture can be beneficial, but it requires careful planning and execution.
• The concept of microservices is often conflated with other concepts, such as code architecture and deployment, leading to confusion.
• Microservices can be useful for specific tasks, such as converting PDFs to another format, but they require additional infrastructure and monitoring.
• The need for authentication, monitoring, and deployment strategies is not unique to microservices and can be handled in a monolith.
• The use of microservices does not absolve developers from changing code when data formats change.
• A single writer and multiple readers approach can be a useful hybrid in microservice architecture.