Microservices vs monolithic

Microservices - Comparing with monolithic architectureThe good, the Bad and the Ugly

Xuan-Loi Vu

Vega’s Tech Department98 Hoang Quoc Viet

Hanoi, 06 - 01 - 2017

[email protected] (Tech Department) Microservices Comparing With Monolithic Hanoi, 06 - 01 - 2017 1 / 24

Introduction

Table of Contents

1 IntroductionMonolithic architectureMicroservices architecture

2 Microservices in action1 Bounded Context2 Service discovery and Orchestration (coordination)3 Latency and failure from dependencies4 Availability5 Security6 Database

Event-SourcingCQRSDistributed transaction


Introduction

Monolithic and Microservices


Introduction Monolithic architecture

Monolithic architecture

Characteristics:

one code base

usually one programming language

rarely, one application with more than two databases

deploy one WAR file (or directory hierarchy)

scale application by running multiple copies using load balancer

· · ·


Introduction Microservices architecture

Microservices architecture

Characteristics:

multiple code bases

full-stack or polygot

component’s database is independent

easy of deployment and scaling

· · ·



Pros and Cos

pros

Decentralize application so that easier maintain

Re-used component

Deployability - agility to roll out new versions

Reliability - fault affects that microservice alone and its consumers(bulkhead)

Availability - rolling out a new version of a microservice requires littledowntime

Scalability - can be scaled independently using pools, clusters, grids

Modifiability - more flexibility to use new frameworks, libraries,datasources, and other resources

Management - application management effort

Design autonomy - team has freedom to employ differenttechnologies, frameworks, and patterns



Pros and Cos - No silver bullet

cos

Determine “Bounded Context”

Deployability - more complex with many jobs, scripts, transfer areas,and config files

Performance - communicate over the network, whereas services withinthe monolith may benefit from local calls

Availability - belongs to dynamic discovery

Modifiability - database inconsistency, transaction, . . .

Testability - harder to setup and run

Management - application operation effort increases because there aremore runtime components, log files, and point-to-point interactions tooversee

Security


Microservices in action

Table of Contents

1 IntroductionMonolithic architectureMicroservices architecture

2 Microservices in action1 Bounded Context2 Service discovery and Orchestration (coordination)3 Latency and failure from dependencies4 Availability5 Security6 Database

Event-SourcingCQRSDistributed transaction


Microservices in action Overcome disadvantages

Overcome disadvantages

Determine “Bounded Context”

Deployability, testability and management - service discovery andcoordinator

Performance - latency and failure from dependencies

Availability - cluster or HA for dynamic discovery servers

Security between components

Database (most difficult and most important) - event source, CQRS,long-lived transaction


Microservices in action 1 Bounded Context

Determine Bounded Context

How do we do?


Microservices in action 2 Service discovery and Orchestration (coordination)

Service discovery and Orchestration (coordination)

Service discovery is the automatic detection of devices and services offeredby these devices on a computer network.

Orchestration is the automated arrangement, coordination, andmanagement of computer systems, middleware, and services

Supported and usually used tools:

Apache ZooKeeper

Consul IO by HashiCorp


https://zookeeper.apache.org

https://www.consul.io

Microservices in action 3 Latency and failure from dependencies

Latency and failure from dependencies

Review Netflix Histrix:

Give protection from and control over latency and failure fromdependencies accessed (typically over the network) via third-partyclient libraries.

Stop cascading failures in a complex distributed system.

Fail fast and rapidly recover

Fallback and gracefully degrade when possible

Enable near real-time monitoring, alerting, and operational control


https://github.com/Netflix/Hystrix

Microservices in action 3 Latency and failure from dependencies

Review Netflix Histrix - Circuit breaker


Microservices in action 4 Availability

Availability

Deploy cluster of Apache ZooKeeper or Consul:

ZooKeeper cluster

Consul cluster


https://zookeeper.apache.org/doc/r3.3.2/zookeeperAdmin.html

https://www.consul.io/intro/getting-started/join.html

Microservices in action 5 Security

Security

Usually using authentication and authorization servers:

Kerberos

Your own JWT system


Microservices in action 6 Database

Database - the most important and most difficult

Review three approaches:

Event-Sourcing

CQRS

Distributed transaction



Event-Sourcing

Characteristics:

all changes to application state are stored as a sequence of events

all events are immutable

use the events log to reconstruct past states

enable Reactive pattern

Supported tools: Apache Kafka, Akka actor, . . .

More detail: Event-Sourcing Pattern


https://msdn.microsoft.com/en-us/library/dn589792.aspx


Command-Query Responsibility Segregation (CQRS)

Characteristics:

separate the read and write by using commands and queries

performing modifications and querying data separately

command and query parts could live in different services, or ondifferent hardware, and could make use of radically different types ofdata store

often used in conjunction with the Event-Sourcing pattern

More detail: CQRS Pattern


https://msdn.microsoft.com/en-us/library/dn568103.aspx


Distributed transaction

Two-phase commit protocol

Long-lived transaction (SAGAS)



Two-phase commit protocol



Long-lived transaction (SAGAS)

Characteristics from Wikipedia:

a transaction that spans multiple database transactions. TransactionT can be viewed as a collection of sub-transactions T1, T2, . . ., Tn

a sequence of database transactions grouped to achieve a singleatomic result

support backward and forward recovery. When a failure interrupts,there are two choices: compensate for the executed transactions(backward recovery), or execute the missing transactions (forwardrecovery)


Conclusion

Should we prefer microservices over monolithic?

“Microservices architecture shows a lot of advantages”

However, it is not a silver bullet.


References

References

Microservice Architecture

Reactive Microservices Architecture

Pros and Cos

Event-Sourcing

Event-Sourcing CQRS stream processing with Apache Kafka

Akka Persistence

Two-Phase commit protocol

Long-lived transaction - SAGAS


http://transform.ca.com/API-microservice-architecture-oreilly-book.html

https://info.lightbend.com/COLL-20XX-Reactive-Microservices-Architecture-RES-LP.html

http://stackoverflow.com/questions/33041733/microservices-vs-monolithic-architecture

http://martinfowler.com/eaaDev/EventSourcing.html

https://www.confluent.io/blog/event-sourcing-cqrs-stream-processing-apache-kafka-whats-connection/

http://doc.akka.io/docs/akka/2.4/scala/persistence.html#Event_sourcing

https://docs.oracle.com/cd/B28359_01/server.111/b28310/ds_txns003.htm#ADMIN12223

ftp://ftp.cs.princeton.edu/reports/1987/070.pdf

Questions and answers

Questions and answers

Thank you for your attention!!!


Technology

Microservices vs monolithic