The Microservices Paradox

In today's software landscape, microservices have emerged as the preferred architecture. While they solve specific problems, they also introduce new complexities.

Technical issues

Complexity: Increased management overhead
Distributed Transactions: Harder to achieve transactional consistency and rollback
Communication overhead: API calls are replaced with network requests.
Security: Increased attack surface. APIs and secrets to secure.
Debugging: Distributed debugging is hard. It requires additional tooling in the code and infrastructure support for tracing and logging.
Testing: integration testing and end-to-end testing complexities.

Operational issues

Cost: Increased infrastructure and operational cost
Dependency Issues: Service interdependencies cause release and compatibility problems.
Ownership and Responsibility Challenges
Change Management: Coordinating cross-system changes.
Alerting and Monitoring: Essential for swift issue resolution

Organizational issues

Communication Challenges: Multiple-team involvement.
Training: Skillset adjustment for developers and operators
Governance: Consistency and standards enforcements

So, what would be the right conditions to venture into microservices.

Getting Started

To ease into microservices, start by creating a single application or service. If you have web and mobile frontends, create separate applications for each (web and mobile). However, keep things simple.

At this stage, your development team should be small, typically fewer than 5 engineers. Ideally, all team members should be able to work on all aspects of the application.

This allows your team to: