SOA DOING RIGHT

Microservices

the trendy BUZZword

WTC

• ONE electricity supply

• ONE water supply• ONE elevator

Monolithic Architecture

• Single SW application with ALL functionalities implemented/deployed

• Each floor a dedicate service (HR, Marketing ++) • Monolithic SOA

• Coarse-grained (depend on others. Eg. Shipping service waiting for approval from Admin service)

• Wider scope (manages many business cases)• Complex message formats

Monolithic Architecture : Layered Architecture

Monolithic Architecture

Shipping : API Logic Dao

98 Acres

• OWN refrigerator• OWN water supply• OWN power

generator• Tiny bit services are

bundled

CAN function INDEPENDANTLY

Microservices Architecture

Online retail store : ebay

Microservices

• Microservice • Develop single application• Fine-grained manner• Independent of other services• Deploy independently

• Misconceptions• Line of Codes• “Micro” (how small it is :O)• Team Size

Design Consideration

• Single Responsibility Principle(SRP) : limited and focused business scope. (IMPORTANT : righted sized services)

• Service boundaries + business capabilities

• Microservices = few Operations/Functionalities, simple Message Formats

• Evolving process – Micro service might decomposed into future.

Messaging in Microservices

• Monolithic Architecture• Function calls/ Language level methods• SOA : SOAP, WS* with HTTP, JMS ++• ESB

• Micro Services• Simple• Light weight• ESB Killer

Messaging in Microservices

• Synchronous Messaging• Client waits for response from service• REST, Thrift

• Async Messaging• NO or least expect a response• Light weight• AMQP, MQTT, STOMP

Integrating Microservices

• ESB Killer• Monolithic SOA – client connections are forward to different APIs• Microservices do not use ESB (different wiring mechanism)

• Microservices• Smart Endpoints – Moves business logic to services and clients• Dumb pipes – To connect services

Integrating Microservices

• Point to Point – Invoke service directly

Integrating Microservices

• API Gate-Way style

Integrating Microservices

• Message Broker style

Micro service can publish it’s service, as well as subscribe to services of others

Deployment & Orchestration

• Each MS – deploy as separate Docker(to deploy services) image

• Scaling - # of containers• Early days – minor change in

one, deploy total• Kubernetes - #Google

(Stratos)• Orchestration

Security & Governance

Pulse Security

• Salesforce Authorization• Federated authorization• OAuth

• Pulse Agent• Which POS Device

Microservices Security

• Central user repository store• OAuth 2.0

• Authorization• Token Sharing

• OpenId Connect• Authentication• OAuth + ID token (user info)

Daham

Asynchronous Processingin

Asynchronous Language

Is Node.js Really Single Threaded?

Is Node Actually Single Threaded?

Possible Task Strategies

• Possible Task Strategies

• Foreground (In-line)

• Parallel

• Local Messages (Forking)

• Queues

Foreground (in-line)

caterRequest (req, res, next) {  doTask(function(err, data) {       if (err) {           return res.send(‘fail');       } else {           return res.send(’success');       }   });}

Foreground (in-line)

• Good side

• Gives chance to other requests.

• Bad Side

• Using server resources to other tasks (e.g. email sending, AWS calls)

• Timeout to client for partially success.

Parallel

caterRequest(req, res, next) {

  doTask(function(err, data) {

   

   });

return res.send(’success');

}

Just ignore the callback

Parallel

• Good side

• Very fast.

• No extra codes needed for thread life cycle manipulation.

• Bad Side

• 0 callbacks 0 data. No idea about what happened.

Local Messages (Forking)

Local Messages (Forking)

• Good side

• Web server process is completely independent of task process.(i.e. email sender , AWS caller)

• Error handling, throttling and retrying can be achieved.

• Bad Side

• Only suitable for single host environment.

Queues

Queues

Advantages of Queues

• Decoupling work producers and work consumers

• Making retry logic easier to implement

• Distributing work load throughout time

• Distributing work load throughout space (nodes)

• Making asynchronous work

• Making external systems easier to integrate