Microservices - Key Considerations
Microservices - Key Considerations
These considerations will help you design a successful microservice application with performance, scalability, and integration in mind.
Join the DZone community and get the full member experience.Join For Free
The new Gartner Critical Capabilities report explains how APIs and microservices enable digital leaders to deliver better B2B, open banking and mobile projects.
A microservice architecture consists of components/services with well-defined interfaces which can be deployed, maintained, and scaled independently and communicate over standard protocols.
Below are some key considerations to be taken into account when designing a well-defined microservice:
- Is the service granular enough?
- Is the service aligned to a single business activity and is responsible for that business activity.
- Is the service fully decoupled?
- Is it a self-contained and independent deployment unit? Does the service encompass all necessary resources to support the business activity?
- Does the service have a proper service boundary and does not expose the internal details outside the service boundary for other components/systems using/invoking it?
- Is the service independent? Can it be changed in an independent manner?
- Is the service easily upgradeable?
- Is the service independently scalable?
- Is the usage documentation for each service properly done?
- Is the service implementation-agnostic? Is it easy enough to change a microservice without changing its interface?
- Can a single team own the microservice from inception to production?
- Does the service use a standard mode of communication?
- Does the microservice have a well-defined interface with a published contract supporting standard protocols for data exchange?
- Does the service support design for retries and fallback?
- Does the service take into account failures of dependent services?
Performance, Exception Handling, and Scalability
- Is the service resilient?
- Can the service be independently deployed and scaled?
- Are the health and performance of the application monitored?
- Is there a centralized logging mechanism?
- Is performance monitored?
- Is load balancing ensured?
- Is elasticity handled?
- Are timeouts managed?
- Are metrics like infrastructure, file system operations, inbound requests, integrations, and external services monitored?
- Does the service publish adequate metrics on its uptime and response time,so that the monitoring infrastructure can monitor and take corrective measures?
- Does the service have timeouts with default behavior implemented if its dependent services do not respond in a specific interval?
- Are compensation transactions used for operations that cover multiple microservices?
- Does the service communicate on accepted enterprise standards?
- Do the messages exchanged by the service contain the required headers, such as reply-to queues?
- Does the service send metrics or make them available over a pull API?
- Do the events raised by the service follow a schema, and are they defined in JSON?
- Are the business services free of mediation and transformation logic and communicate in a canonical format (e.g. JSON)?
- Can the service be provisioned programmatically on short notice?
- Can the monitoring infrastructure detect if the service is running to its SLA, not to its SLA, or not running at all?
- Can the monitoring infrastructure detect a degradation in the SLA based on the metrics/heartrate the service is publishing?
- Can the alerting infrastructure raise an appropriate alert to the concerned team when it gets a failure log message?
- Does the monitoring system keep statistics of uptime or failures, SLA, and requests serviced and show them in appropriate dashboards?
- Is the service easily discoverable through a registry?
- Is the service runtime status in the registry reflected if the service is started or stopped?
Opinions expressed by DZone contributors are their own.