Principles of a MicroService

I'm doing research for MicroServices for a new system and I thought I'd distill my reference materials in my own words as a different perspective. Please review the source for more info.

Principles in my words

  • Domain Driven Design: Focus on the purpose and objective of the MicroService and not the system as a whole. Avoid concepts defined in other aspects of the system.
  • Hide Implementation Details: A caller of the service shouldn't need to know "which order" a given set of endpoints needs to be called. The system should orchastrate this internally and this means that the REST endpoint might need to collect all the details upfront. Furthermore, internal data structures don't need to be exposed; accept and return data in user friendly structure as opposed to system friendly structures.
  • Decentralization: No external dependencies on other components of the system. If using a RDBS then databases should be separate and migratable. For example, you should be able to migrate the database -- schema and data -- to another instance, data center or even technology without affecting other components in the system.
  • Failure Isolation: If a given instance of the MicroService stops responding, the other instances should be able to continue to operate. This principle doesn't speak to logic errors or such bugs. Just that one MicroService doesn't depend directly on another (mirror) instance of a MicroService.
  • Continuous Delivery: The MicroService should be deployable without concern with when or if the other components are being deployed.

Header Photo by William Bout

Frank Villasenor

Frank Villasenor

Owner and principal author of this site. Professional Engineering Lead, Software Engineer & Architect working in the Chicagoland area as a consultant. Cert: AWS DevOps Pro
Chicago, IL