SERVICES - ARCHITECTURE

Governance Team 10 Mar 17

• Traditional Approach • Issues in Traditional • Define MS• Characteristics of

MSA• Service Discovery• Communication /Integration in MS

– MSA

• Data Management in MS

• Deployment Strategy • Migration to MSA• PROS & Cons of MSA• Best Practices of MSA• Demo• QA

– MSA

Monolith – Architecture• Monolithic means

composed all in one piece. Monolithic software is designed to be self-contained.

• Components of the program are interconnected and interdependent (tightly coupled)

Monolith Characteristics• Extensibility is bit difficult since the code base is

very huge • Slow down the development and takes more

time to shipping the new features • CD – Impossible Task • Difficult to scale • Application Reliability • Long Term commitment in Technology Stack

Micro Service Architecture-MSA

• Small, and Focused on Doing One Thing Well• Software applications as a suite of Independently

deployable, small, modular services in which each service runs a unique process and communicates through a well-defined, lightweight mechanism to serve a business goal

• Large functionality or business capability is decomposed into set of small services

MSA – Characteristics

• Componentization via Services• Organized around Business Capabilities• Decentralized Governance• Products not Projects• Decentralized Data Management• Infrastructure Automation• Design for failure• Evolutionary Design(From Martin Fowler’s Link)

MSA – Interaction Style• Services are interacted using Inter process communication (IPV)Mechanism.IPC : One to one /One to Many Sync/Async

MSA – Interaction Style

IPC Style One to One One to Many

Sync Request /Response

Async Notification Publish /Subscribe

Request/Async Response Publish/Async Response

MSA – Interaction Style Sample

MSA – Service Discovery

MSA – Service Discovery

• Client Side Discovery Pattern • Server Side Discovery Pattern

MSA – Client Side Service Discovery

MSA – Server Side Service Discovery

MSA – Data Management

• Challenge in MSA Data Management– Since MSA handling the different DB with different

services the following challenges we are facing in the Data management Context• Transaction Management-2PC/Distributed Transaction • Retrieve the Data from Multiple DB

Event Driven Architecture

• You can use the events to implements Business transaction that span of Multiple Services

• Its not ACID Transaction instead its BASE Model • Its guarantees such as eventually consistency

Event Driven Architecture-

• Steps to Perform the Transaction in EDA– Update the Business entity and publish the event from

Service1– Publish the events into Message Broker– Service 2 consume the event , update the business entity

based on the event – Service 2 publish another event in the Message Broker – Service 1 consume the event and update the status in

their DB

Event Driven Architecture-Flow

Event Driven Architecture-FlowMaterialized View :

Read the data from Multiple DB Data is always eventually consistent.

Atomicity in MSAAchieving Atomicity in following ways Publishing event using local transaction Mining a Database Transaction log Event Sourcing DB Link/Trigger

Deployment StrategyMSA Deployment Patterns:

Multiple Service Instance /Host PatternService Instance /Host Pattern

Service Instance /VMService Instance/Container

Serverless Deployment Pattern

Migration StrategyFollowing strategy for Monolith MSA Migration• Stop Digging code –

• No further extension in the Monolith instead create the separate service for those new requirement

• Using glue code for internal integration between service and monolith• Separate the Frontend and Backend layer

• Separate the Presentation layer with Business /Data Layer • Communication between those layers through IPC

• Extract the Module from Monolith • Extract the key module from monolith and convert into service

MSA Design PatternAggregator DPProxy DPShared Data DPASync Message DPChain DPBranch DP

API Gateway

PROS -MSA

• Independent Deployment and Development• Code and Team size not grow rapidly • Define the services based on Business capability • Reliability • Easy to Scale • No long-term commitment to technology stack

Cons -MSA

• Complexity in terms of Architect/Testing/Deployment

• Increasing number of services will cause the Memory /Resource/ Maintenance issue

• Communication between the services bit complex • Duplication effort

Demo – Technology

• Java 8• Spring Boot • Spring Cloud • Postgresql • Cloud Foundry• Eureka • Maven

Demo

• Restful Service• Restful with DB• IPC Demo

QUESTIONS?

APPENDIX

Handling Partial Failure • Network Timeout • Limiting number of outstanding request- Throttling• Circuit Broker Pattern • Provide the Fallback – – Perform fall back logic when a request fails. For example,

return cached data or a default value, such as an empty set of recommendations

Message Channels• Point 2 Point – delivers a message to exactly one of the consumers that

are reading from the channel– IPC – One –to – One

• Publish – Subscribe – delivers each message to all of the attached consumers.– IPC – One –to-Many

HATEOAS

MSA-Chassis

• Its framework, which handles cross-cutting concerns like logging/Security/Health check/Externalize the configuration file,Service registration/service discovery and etc

Service Registry

• Key Part of Service Discovery• Its DB containing the network location of

services instance• Tools /API used to register the services in

Registry• Ex:– Etcd– Consul– Apache ZooKeeper

Service Registration

• Service instances must be registered with and unregistered from the service registry

• Two ways – Self Registration– Third Party Tool Registration

ACID

• Atomicity – – Changes are made atomically

• Consistency – – The state of the database is always consistent

• Isolation – – Even though transactions are executed

concurrently, it appears they are executed serially• Durable – – Once a transaction has committed, it is not undone

BASE

Polyglot Persistence

• MSA uses the mix of Database like No SQL/RBDMS and etc to store/query the different kind of data

A|B Testing

Single Responsibility Principle

Demo GitHub– https://github.com/parameshnon