The document provides an overview of microservices architecture, highlighting its evolution from monolithic and SOA systems, and discussing key concepts such as service independence, communication patterns (synchronous vs asynchronous), and deployment strategies using technologies like Docker and Kubernetes. It also covers the organization of microservices, governance models, security considerations, and the integration of legacy systems through patterns like anti-corruption layers and strangler patterns. The importance of observability and service mesh for managing complex inter-service communications in microservices is emphasized as a significant challenge.

1. Director - Integration Architecture, WSO2
Microservices for Enterprises
Kasun Indrasiri

2. Pre-Microservices era
SOA/ESB with APIs
Consumers
ESB
System
Service 1 Service 2 Service 3 Service 4 Service 5
API Management
Application server

3. • The foundation of MSA is about developing a
single application as a suite of fine-grained
and independent services running in its own
process, developed and deployed
independently.
Microservice Architecture

4. Evolution of Microservices
Microservices
Web Portal Mobile Apps Store Admin Web Storefrons Promotion Mgmt
API Management
Product Details Shopping Cart Order Mgt Payment Proc. Payment Proc. Customer Mgt.
Account Mgt Order Tracking Financial Mgt Fraud Detection Tax Mgt Inventory Mgt Allocation-Release
Self-Service Giftcards Promotions Pricing Subscription Credit service CRM Mgt Shipping
Data Warehouse Finance System Shipping Inventory Payment Gateway Cloud ServicesE.g. Salesforce, Paypal etc

5. • Common Misconceptions
– Lines of Code, Team size, 'Micro' is a bit misleading term
• Single Responsibility Principle(SRP)
– Having a limited and a focused business requirement.
• Scope
– Find the service boundaries and align them with the business
capabilities (aka DDD)
• Miniservices
– “A miniservice is a coarse-grained, independently deployable and
independently scalable application component.”
– “Innovation Insight for Miniservices”
Designing Microservices : Size, scope and
capabilities
5

6. • In Monolithic architecture:
– Function calls or language-level method calls
– SOA/web services : SOAP and WS* with HTTP, JMS etc.
– Web services with several dozens of operations and complex
message schemas
• In Microservices architecture:
– Simple and lightweight messaging mechanism.
Messaging in Microservices
6

7. • REST
– HTTP 1.x
– OpenAPI/Swagger
– JSON
7
Messaging in Microservices
Synchronous Messaging

8. • gRPC - https://grpc.io/
– IDL, Protobuf
– HTTP2
– Internal service calls
• Other RPC styles : Avro, Thrift
8
Messaging in Microservices
Synchronous Messaging

9. • Propagating changes across multiple microservices
– Single-receiver message-based communication
– Multiple-receivers message-based communication
• AMQP, Kafka, MQTT
9
Messaging in Microservices
Asynchronous Messaging
Source : https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/architect-microservice-container-applications/communication-in-microservice-architecture

10. • Asynchronous microservice integration -> enforces microservices
autonomy
10
Messaging in Microservices
Synchronous vs Asynchronous Messaging
Source : https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/architect-microservice-container-applications/communication-in-microservice-architecture

11. • Not all microservices are similar
– Business logic heavy, while some contain a lot of
interservice calls
– Synchronous vs async communication
– Too fine-grained to be exposed as a business functionality
– Some services are exposed as APIs
Do all Microservices similar?
11

12. Technologies for Building Composite/Integration
Microservices
• General Purpose Languages/Frameworks - Java,
Node.js, Groovy, e.g. SpringBoot, Dropwizard
• Bulky traditional ESB architecture -> Not fully
compatible with MSA principles

13. Technologies for Building Composite/Integration
Microservices
• General Purpose Languages/Frameworks - Java,
Node.js, Groovy, e.g. SpringBoot, Dropwizard
• Bulky traditional ESB architecture -> Not fully
compatible with MSA principles

14. Technologies for Building Composite/Integration
Microservices
Ballerina - ballerinalang.org

15. Organizing Microservices
Microservice Types with Different Granularities
Consumer 1
API Service 1 API Service 2 API Service 3 API Service 4
Consumers
Consumer 2 Consumer 3
Service 6 Service 7 Service 8 Service 9
Service 1 Service 2 Service 3 Service 4 Service 5 Proprietary &
Legacy
Systems
Web API /
SaaS
API Services/
Edge Services
Composite Service/
Integration Services
Core Services/
Atomic Services

16. Organizing Microservices
Microservice Types with Different Granularities
Consumer 1
API Service P API Service Q API Service R API Service S
Consumers
Consumer 2 Consumer 3
μ Service A
μ Service B
μ Service F
μ Service G
Proprietary &
Legacy
Systems
Web API /
SaaS
API Services/
Edge Services
Composite Service/
Integration Services
Core Services/
Atomic Services
μ Service I
μ Service H
μ Service J
μ Service E
μ Service C
μ Service D

17. Microservices Security
Microservice security with OAuth2 and OpenID Connect.
17
Refer :
https://medium.facilelogin.com/securing-microservices-with-oauth-2-0-jwt-and-xacml-d03770a9a838

18. • Ability to deploy/un-deploy independently of other microservices.
• Must be able to scale at each microservices level.
• Building and deploying microservices quickly.
• Failure in one microservice must not affect any of the other services.
• Docker and Kubernetes.
Microservices Deployment
18

19. • Isolate the legacy and modern systems
by placing an anti-corruption layer
between them.
• Translates communications between the
two systems, allowing the legacy system
to remain unchanged while the modern
application can avoid compromising its
design and technological approach.
19
Bridging Microservices and Monolithic
systems
Anti-Corruption Layer pattern
Source:
https://docs.microsoft.com/en-us/azure/architecture/patterns/anti-corruption-layer

20. • Incrementally replace specific pieces of
functionality with new applications and
services.
• Create a façade that intercepts requests
going to the backend legacy system.
20
Bridging Microservices and Monolithic
systems
Strangler Pattern
Source: https://docs.microsoft.com/en-us/azure/architecture/patterns/strangler

21. Data Management
Database per service
• Keep each microservice’s persistent data private to that
service and accessible only via its API.
• Create composite services to retrieve data from multiple
microservices.
• Eventual consistency between microservices through
event-driven communication and a publish-and-subscribe
system.

22. Governance
Decentralized Governance
• Decentralized governance of Service Design, Deployment
and Execution
– Give the teams the freedom to develop software
components using different stacks
– Define some ‘global standards’ that apply to the
methodology behind the software

23. Governance
Service Registry
• Central component which
supports:
– APIs to publish service
information (service endpoints,
contract, message models,
available service versions)
– APIs to query/discover service
information.
– Pull and push models to
retrieve service information
– Service ownership/consumers
source : https://www.nirmata.com/2014/08/13/getting-started-with-microservices-using-netflix-oss-docker/

24. Governance
Service Dependencies
• Managing/tracking and tracking
dependencies and associations
between services
• Derive service dependencies and
associations automatically, ability to
monitor/visualize them.
• Netflix Vizceral :
https://github.com/Netflix/vizceral

25. Governance
Runtime Policy Enforcements and IAM
• Throttling, Caching, Security, Identity management
• Centrally applied at API Gateway level

26. Governance in Microservices
Service Observability
• Metrics
• Monitoring
• Distributed logging
• Distributed tracing.
• Visualization

27. • “The most complex challenge in realizing
microservice architecture is not building the
services themselves, but the communication
between services.”
27
Service Mesh
Why Service Mesh?

28. Service Mesh
Why Service Mesh?
• With MSA, business logic
+ network communication
logic are dispersed across
independent services
Consumers
Microservice X Microservice Y Microservice Z
Microservice P Microservice Q Microservice R Microservice S
JAVA Node.js Python

29. 29
Service Mesh
Inter-service communication

30. 30
Service Mesh
What is a ‘Service Mesh’?

31. 31
Service Mesh in Action

32. • Istio : https://istio.io/
• Linkerd: https://linkerd.io/
32
Service Mesh
Implementations

33. • Use a pragmatic approach for adopting microservices architecture
for enterprises.
• Select the appropriate patterns and technologies based on your
business requirements.
33
Conclusion

34. • https://medium.com/microservices-in-practice
• https://docs.microsoft.com/en-us/dotnet/standard/microservices-a
rchitecture
34
References

35. wso2.com
35