Deployment

Importance of Independent Deployability

• Emphasized that, alongside information hiding, independent deployability is a core principle of microservices.
• Having to release services in a specific order or simultaneously indicates a distributed monolith rather than proper microservices.
• Teams owning multiple services can manage coupling somewhat, but aligning releases across multiple teams should be avoided to preserve autonomy.
• Coordinating releases with other teams undermines the benefit of moving at your own pace.

Challenges from Breaking Changes

• Introduction of breaking changes (e.g., renaming an API property) disrupts independent deployability.
• Making changes to events or API schemas without knowing all consumers can force cross-team alignment and synchronization.
• Functional changes, even if subtle, might require coordinated releases if they impact other services or teams.

Strategies to Manage Breakage and Compatibility

• Advocated for information hiding and decoupling internal data structures from external interfaces using data transfer objects.
• Recommended making communication mechanisms friendly to backward-compatible changes wherever possible.
• Suggested versioning for synchronous APIs (e.g., /api/v2/products) and asynchronous schemas (e.g., publishing dual event versions temporarily) as ways to manage incompatible updates.
• Cautioned that maintaining dual versions increases complexity, especially for fixes across both versions.

Importance of Telemetry and Tracing

• Stressed the need for comprehensive tracing and telemetry to monitor service usage and dependencies across the microservices landscape.
• Noted that usage data helps in understanding system dependencies, not just for coordination but for broader system insights.

Key Takeaway

• The central message is to maintain independent deployability to avoid constructing a distributed monolith.
• Inability to deploy independently is a warning sign—microservices should always strive for autonomy.