What is a Service?

• Scalability

• Reliability

• Performance

Microservices Architecture

1. How do you communicate with these microservices with all these multiple services and service instances?

2. How do you consistently update the data across this distributed architecture? e.g. placing a order will involve multiple services interactions.

Microservices provide benefits…

• Strong Module Boundaries: Microservices reinforce modular structure, which is particularly important for larger teams.

• Independent Deployment: Simple services are easier to deploy, and since they are autonomous, are less likely to cause system failures when they go wrong.

• Technology Diversity: With microservices you can mix multiple languages, development frameworks and data-storage technologies.

…but come with costs

• Distribution: Distributed systems are harder to program, since remote calls are slow and are always at risk of failure.

• Eventual Consistency: Maintaining strong consistency is extremely difficult for a distributed system, which means everyone has to manage eventual consistency.

• Operational Complexity: You need a mature operations team to manage lots of services, which are being redeployed regularly.

Microservices Communication

• SOA with application-level scope for services

• Smaller services with a cohesive focus

• Independent data storage

• Scalable, performant, and flexible applications

• High availability and reliable application

• Technology agnostic services

• Independently changeable and deployable

• Network communication mechanism

• Sync and async com to avoid distributed transactions

• Centralized tooling for management

Monolith

• No restriction on size

• Longer development and deployment

• Inaccessible features

• Fixed technology stack

• High levels of coupling

• Failure could affect the whole system

• Inefficient scaling

• Minor change results in entire system deployment

• Easy to replicate the environment

• Quick solution for startups and prototyping

• Monolith is an alternative

Why Microservice Success?

• competitive software market

• mandatory reliability

• business domain-driven design

• automated test tools

• automated deployment tools

• agile practices

• cloud and on-premise hosting

• embrace new technology

• performance via async communication

• methodical transition strategies

• shorter development times

• reliable and faster deployment

• enable frequent updates

• decouple the changeable parts

• security

• increased uptime

• fast issue resolution

• highly scalable and better performance

• better ownership and knowledge

• enables distributed teams

Design Principles

• Autonomous: Each service is independently changeable and deployable

• Domain-driven cohesion: Each service represents a specific part of the business with a cohesive focus

• Ownership Culture: Each service is a product with a team behind it

• Resiliency: Each service fails fast and alternates functionality

• Observability: Workflows and component health are visible and traceable. Central Logging, Unique ID. Central Monitoring (health, performance, metrics), Capacity Planning and Alert

• Automation: Tools for automated hosting, testing and deployment

Autonomous

Loose Coupling

• Communication by network

• use open communication protocols like https

• limit downstream and upstream knowledge

• avoid client libraries

• avoid chatty exchanges

• avoid sharing databases

• honor contracts and interfaces

Contracts and Interfaces

• Http requests and message formats

• avoid breaking changes

• additive changes (endpoints / properties)

• clear input and output

• minimize external data exposure

Concurrent Dev

• Collaborate using contracts and interfaces

• agree on contract requirements

• team ownership

• visible contracts and interfaces

• Consumer-driven contracts

Backward Compatibility

• versioning strategy for contract changes

• support old and new versions concurrently

• coexisting endpoints

• compatible message formats

• automated integration tests

• semantic versioning

Stateless services

• no in-memory data for a request

• request or message contains data

• use identifiers to retrieve data from DZB

• use a shared cache for performance

• conceptual microservice made up of apps

• database per conceptual microservice

Independently Modifiable

• independently changeable and deployable

• need loosely coupled services

• services that honor contracts

Domain-driven cohesion

Ownership Culture

Resiliency

Observability

Automation