learning from fallacies of microservices - gids 2017(cr040317) · microservice architecture is a...

Learning fromFallacies of Microservices

Works @ PayPal

Working in Java for c lose to a decade

Architecture enthusiast

2

Microservices - Definition

Microservice architecture is a method of developing 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.

Source : https://smartbear.com/learn/api-design/what-are-microservices/

©2017 PayPal Inc. Confidential and proprietary. 3

Microservices – Definition

ØSmall services

ØUnique process

Ø Lightweight communication mechanisms

ØUnique business capabilities


Microservices – Definition

Ø Independently deployable

ØDifferent programming languages

ØDifferent data storage technologies.


Why Microservices?

ØEasier for a developer to understand

ØDevelopment is faster

Ø Independent Deployment - Easier to deploy new versions of services frequently

ØScalability

Ø Improved fault isolation.

ØNo long-term commitment to a technology stack



User Service

Cart Service Checkou

t Service

Shipping Service

Payment Service

Catalogue Service

Rating Review Service

Client Layer

Login Service

Why NOT to use Microservices?

ØMicroservices architecture is complicated

Ø If you are a new company

ØDon’t have DevOps support

ØNot facing scalability issues


Implementation Fal lacies

9


• Using whole lot of network to communicate

User Service


t Service

Shipping Service

Payment Service

Catalogue Service


Client Layer

Login Service

Are these network reliable?

Is latency 0?

Network - Reliability

ØNetwork is not reliable

ØConnections across firewalls

ØCascading failure


Network – Reliability - Solutions

ØDesign for Failure

ØConstant active monitoring

ØDiscovering Who to Blame



• Service Failure

User Service


t Service

Shipping Service

Payment Service

Catalogue Service


Client Layer

Login Service

Service Failure – Design for Failure

ØChaos Monkey (Netflix Example)


Source : http://techblog.netflix.com/2012/07/chaos-monkey-released-into-wild.html

Service Failure

ØDR Readiness

ØEffective monitoring



• Versioning

User Service


t Service

Shipping Service

Payment Service

Catalogue Service


Client Layer

Login Service

Specification change proposal for Payment Service


V1Checkout Service

V1Payment Service

V1Shipping Service DB1

DB2


V1Checkout Service

V2Payment Service

V1Shipping Service DB1

DB2

Semantic Versioning


Major, Minor & Patch

V1.yyCheckout Service

V1.xxPayment Service

V1.zzShipping Service DB1

DB2

Semantic Versioning





DB2

V2Payment Service

Semantic Versioning





DB2

V2Payment Service

V1.ppCheckoutService

Security

22


• Monolith System : Well defined point of access

User Service


t Service

Shipping Service

Payment Service

Catalogue Service


Client Layer

Login Service

Security

ØForm Auth/oAuth

ØConfused deputy attack

ØUnauthorized access to inner services

ØTransport Security


26

Login Service

User Service

Post Service

User Authenticates and get oAuth Token

Passes oAuth Token to access details

Tries to post something

27

Login Service

User Service

Post Service

User Authenticates as “ABC” and get oAuth Token

Passes oAuth Token to access details of “XYZ”

Tries to post something as “XYZ”

Confused Deputy Problem


• Transport Security

User Service


t Service

Shipping Service

Payment Service

Catalogue Service


Client Layer

Login Service

Security – Transport Security

ØUse HTTPS

Ø Server side check

Ø Payload is not manipulated

Ø No Client guarantee


Security – Transport Security

ØClient side certificates

ØClient guarantees

ØQuite cumbersome to manage


Security – Data Security

ØEncrypt data

ØAdvanced Persistent Threat

ØR-R-R

ØRotate: Short lived credentials

ØRepair: Patch your stuff

ØRepave: Burn it down


URL Hardcoding

32

Hardcoded IPs and Ports


Services are tied to specific IPs and ports. Moving them around requires code changes.

Solution: Service Discovery System


Consul

Service Discovery System


Service A

Service B192.168.0.3:1056

Where is service B?

192.168.0.3:1056

Hey There

Solution: Centralized Router


Router

Service A

Service A

Service A

Service B

Service B

Service B

37

DEBUGGING

Debugging


ServcieA

ServciceB

Service C

Service D

Service E

Log A Log B Log C Log D Log E

Correlation ID: 1234

Correlation ID: 1234

Correlation ID: 1234 Correlation ID: 1234 Correlation ID: 1234

Correlation ID: 1234 Correlation ID: 1234 Correlation ID: 1234 Correlation ID: 1234

Logs can be mapped to single session/user request via correlation ID

Conclusion

39

Conclusion

ØDefinition of Microservices

ØTenets of Microservices

ØWhy to use Microservices

ØWhy not to use Microservices

Ø Implementation Fallacies


Conclusion

ØNetwork Reliability – Effective Monitoring

ØService Failure – Design for failures

ØSemantic versioning of Microservices

ØSecurity – Confused Deputy Attack

ØSecurity – Transport Security

ØSecurity – Data Security (Advanced Persistent Threat)


Conclusion

ØService Discovery System

ØCentralized Router System

ØDebugging : Correlation ID


www.modsummit.com

www.developersummit.com

http://www.modsummit.com/

http://www.developersummit.com/

learning from fallacies of microservices - gids 2017(cr040317) · microservice architecture is a...

Documents