A brief comparison between a fully service orientated architecture system and a microservices-based system; what each system looks like and how they differ.

1. Microservices
A brief introduction to services and microservices

2. What is a service?
“a mechanism to enable access to one or more capabilities, where the
access is provided using a prescribed interface and is exercised
consistent with constraints and policies as specified by the service
description. “
OASIS Reference Model for Service Oriented Architecture

3. What is a service?
“enable access to one or more capabilities”
• Delegated functionality to specialists (no general specialist)
“access is provided using a prescribed interface ”
• Enforces a distributed architecture, communicating by:
• REST, SOAP, AMQP, MSQM, JMS, etc..
” is exercised consistent with constraints and policies as specified by
the service description. ”
• Abides by the Service Contract

4. Service contract
Agreement between a service and its consumer that
specifies inbound and outbound data as well as the
format.

5. Service contract
We have to consider:
• Service availability
• Service responsiveness
• Circuit breaker pattern (if service is not in-memory/remote)
• Versioning (heterogeneous or homogeneous)
• Security (e.g. authentication)
• Transactions (ACID compliance)

6. Example
• Sys AV Scanner
• Enables access to a virus scanning service
• Access is provided using REST
• Responds using JSON
• Sys understands the communication protocol “inbound data”
• Sys understands the response “outbound data”

7. Advantages
• Scalable
• Decoupled
• Better control over development, testing and deployment
• Easier maintenance
• and theoretically is costs less for the business [once it’s up and running]

8. Heterogeneous & Homogeneous Versioning
Homogeneous versioning uses version numbers across the same
contract.
Heterogeneous versioning uses different types of the same contract.

9. Disadvantages
• Increased ancillary complexity
• Increased time cost
• ACID is difficult!
• Latency
• Mitigated by caching or another service / pre-empting requests
• Service contracts can be difficult
• What happens if a service I need to connect to is no longer available?

10. Microservices
Characteristics
&
Capabilities

11. Characteristics: Taxonomy
Many functional services and private-shared infrastructure services

12. Characteristics: Granularity
Microservices are small, fine-grained services. They do one thing, and
they do it well.
• Granularity affects performance!
• Service Contract overhead can add 100ms to the total response time
• Can impede ACID compliance if services are too granular

13. Characteristics: Choreography / Orchestration
Orchestration: coordination with a central mediator
Choreography: coordination without a central mediator
Microservices favour orchestration over choreography
Too much choreography can lead to higher efferent coupling
• The degree to which one component is dependent on other components to
complete a single business request

14. Characteristics: Choreography / Orchestration
Don’t be afraid to redefine services in a more coarsely-grained manner!

15. Characteristics: Topology
Microservices have an API layer
• Mediator in service orchestration
• Server-access façade
• Introduces abstraction
• Context awareness (single bounded context)
• Each service can share or have its own access to the infrastructure layer

17. Service 1:1 Data store
• Eradicates different read/write patterns
• Enables true separation between bounded contexts
• Logical separation between subdomains
• Now you have to consider how services will communicate
• (and the CAP theorem)

18. Capabilities: Heterogeneous Interoperability
The ability to integrate different programming languages and platforms
• Microservices support protocol-aware-heteronegeous-interopability
• Protocol between API layer and service MUST be the same
• SOA also supports protocol-agnostic-heterogeneous-interopability
• Hallelujah for that protocol-transforming middleware

19. Microservices vs SOA
Contract decoupling
Mediation / Routing
Protocol Transformation
Infrastructure

20. Contract decoupling
• Allow services to consume a message that does not abide to the
service contract… the holy grail of abstraction
• Message Transformation
• Convert XML to JSON
• Message Enhancement
• Normalise date/time format

21. Mediation / Routing
• Provides the ability to mediate (discover services) and route a request
• A service registry typically acts as the central service configuration
repository

22. Protocol Transformation
• Enables protocol agnostic heterogenous interopability
• Potentially allows service optimisation
• Service A can only communicate in SOAP, Service B is much faster at accepting
requests in REST

23. Infrastructure
• Microservices are easier to deploy and build
• Do not require dedicated enterprise business services (NO ESB/MB)
• Microservices can use “lightweight” communication protocols,
whereas SOA prefers standards and “heavier” protocols: XML, SOAP

24. Summary
• Loose coupling, high cohesiveness services
• API layer coordinates between itself and the microservice
• Each service is adequately insular