According to Sam Newman’s “Building Microservices”, a foundational text, microservices are:

• Small, autonomous services: They are independent and self-contained, focusing on a single business capability.
• Loosely coupled: Services can be developed, deployed, and scaled independently without significant impact on other services.
• Communicating via well-defined APIs: Typically using lightweight protocols like HTTP/REST or asynchronous messaging.
• Organized around business capabilities: Teams own services that align with specific business domains (e.g., order management, user profiles).
• Independent deployment: Each service can be deployed without deploying the entire application.

Martin Fowler and James Lewis’s article “Microservices” (often cited as a primary resource, acting as a concise summary of the architectural style) emphasizes:

• Componentization via services: Services as deployable units.
• Products not projects: Long-lived teams focused on product ownership.
• Decentralized governance: Teams choose their own technologies and tools.
• Smart endpoints and dumb pipes: Communication via simple protocols, not complex ESBs.
• Automated infrastructure: DevOps practices for continuous delivery.
• Design for failure: Services must be resilient to failures in other services.
• Evolutionary design: The architecture can evolve over time.

 Key Characteristics & Principles of Microservice Architecture​ (From various books):

• Bounded Context (Domain-Driven Design): As highlighted in Eric Evans’s “Domain-Driven Design” (which predates microservices but heavily influences their design), each microservice should encapsulate a specific “bounded context.” This means a clear boundary around a particular domain model, preventing “leaky abstractions” and ensuring consistency within that context in Microservice Architecture​ .
• Decentralized Data Management: Instead of a single, shared database, each microservice often owns its data store. This is crucial for independent deployment and scaling. Newman discusses various approaches like polyglot persistence (using different database technologies best suited for a service’s needs).
• API Gateway: Chris Richardson’s “Microservices vs. SOA” (and other resources) often describe the API Gateway pattern. This acts as a single entry point for clients, routing requests to appropriate services, and handling cross-cutting concerns like authentication, rate limiting, and logging.
• Circuit Breaker: Introduced as a critical resilience pattern in Michael Nygard’s “Release It!”, the circuit breaker prevents a failing service from cascading failures throughout the system. When a service experiences too many failures, the circuit “trips,” preventing further calls to that service until it recovers.
• Service Discovery: How do services find each other? Books cover patterns like client-side discovery (e.g., Eureka, Consul) where the client queries a registry, or server-side discovery (e.g., AWS ELB, Kubernetes).
• Logging and Monitoring: With distributed systems, centralized logging (e.g., ELK stack) and distributed tracing (e.g., OpenTracing, Zipkin) become paramount for understanding system behavior and debugging issues. Adrian Cockcroft (known for his work at Netflix) extensively promotes these operational aspects.
• Configuration Management: Externalizing configuration is vital. Tools like Spring Cloud Config or Consul are often discussed for managing configurations across many services.
• Security: Implementing security in a distributed environment requires careful consideration. Books discuss token-based authentication (OAuth2, JWT), API keys, and secure communication channels (TLS/SSL).
• Testing in Microservices: This is more complex than monolithic testing. Books advocate for different levels of testing: unit, integration (contract testing being particularly important, as detailed in “Microservice Architecture: Aligning Principles, Practices, and Culture” by Irakli Nadareishvili, Ronnie Mitra, Matt McLarty, and Mike Amundsen), and end-to-end testing.
• Deployment Strategies: Techniques like blue-green deployments, canary releases, and rolling updates are crucial for deploying microservices with minimal downtime and risk.

Challenges and Considerations of Microservice Architecture​ :

Books also extensively cover the challenges of microservices:

• Increased Operational Overhead: More services mean more to deploy, monitor, and manage. Automation (DevOps) is key.
• Distributed Transactions: Handling transactions across multiple services is complex (e.g., Saga pattern).
• Data Consistency: Ensuring eventual consistency across services can be challenging.
• Network Latency and Reliability: Inter-service communication introduces network overhead and potential failures.
• Debugging and Troubleshooting: Tracing requests across many services can be difficult without proper tooling.
• Team Organization: Requires a shift towards small, autonomous, cross-functional teams.
• Complexity: While individual services are simpler, the overall system complexity increases.