[wso2con eu 2017] microservices for enterprises
TRANSCRIPT
Director - Integration Architecture, WSO2
Microservices for Enterprises
Kasun Indrasiri
Pre-Microservices era SOA/ESB with APIs
Consumers
ESB
System
Service 1 Service 2 Service 3 Service 4 Service 5
API Management
Application server
• 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
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
• 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
• 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
• REST– HTTP 1.x – OpenAPI/Swagger – JSON
7
Messaging in MicroservicesSynchronous Messaging
• gRPC - https://grpc.io/ – IDL, Protobuf– HTTP2 – Internal service calls
• Other RPC styles : Avro, Thrift
8
Messaging in MicroservicesSynchronous Messaging
• Propagating changes across multiple microservices– Single-receiver message-based communication– Multiple-receivers message-based communication
• AMQP, Kafka, MQTT
9
Messaging in MicroservicesAsynchronous Messaging
Source : https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/architect-microservice-container-applications/communication-in-microservice-architecture
• Asynchronous microservice integration -> enforces microservices autonomy
10
Messaging in MicroservicesSynchronous vs Asynchronous Messaging
Source : https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/architect-microservice-container-applications/communication-in-microservice-architecture
• 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
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
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
Technologies for Building Composite/Integration Microservices Ballerina - ballerinalang.org
Organizing Microservices Microservice Types with Different Granularities
Consumer 1
API Service 1 API Service 2 API Service 3 API Service 4
ConsumersConsumer 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
Organizing Microservices Microservice Types with Different Granularities
Consumer 1
API Service P API Service Q API Service R API Service S
ConsumersConsumer 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
Microservices Security Microservice security with OAuth2 and OpenID Connect.
17Refer : https://medium.facilelogin.com/securing-microservices-with-oauth-2-0-jwt-and-xacml-d03770a9a838
• 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
• 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 systemsAnti-Corruption Layer pattern
Source: https://docs.microsoft.com/en-us/azure/architecture/patterns/anti-corruption-layer
• 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 systemsStrangler Pattern
Source: https://docs.microsoft.com/en-us/azure/architecture/patterns/strangler
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.
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
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/consumerssource : https://www.nirmata.com/2014/08/13/getting-started-with-microservices-using-netflix-oss-docker/
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
Governance
Runtime Policy Enforcements and IAM
• Throttling, Caching, Security, Identity management • Centrally applied at API Gateway level
Governance in Microservices
Service Observability
• Metrics• Monitoring• Distributed logging• Distributed tracing.• Visualization
• “The most complex challenge in realizing microservice architecture is not building the services themselves, but the communication between services.”
27
Service MeshWhy Service Mesh?
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
Service MeshInter-service communication
30
Service MeshWhat is a ‘Service Mesh’?
31
Service Mesh in Action
• Istio : https://istio.io/ • Linkerd: https://linkerd.io/
32
Service MeshImplementations
• Use a pragmatic approach for adopting microservices architecture for enterprises.
• Select the appropriate patterns and technologies based on your business requirements.
33
Conclusion
• https://medium.com/microservices-in-practice • https://docs.microsoft.com/en-us/dotnet/standard/microservices-a
rchitecture
34
References