developerweek 2016 - evolution of the paypal platform: journey to apis & microservices
TRANSCRIPT
Evolution of the PayPal Platform: Journey to APIs & Microservices
DeveloperWeek ConferenceFebruary 17, 2016
Deepak Nadig@deepak_nadig
2
PAYPAL CONTEXT– 179 million active customer accounts– 203 markets and 100 currencies– Serves 2M+ external developers
– 2015: TPV of $282 Billion, 4.9 Billion transactions– Mobile: 23% of TPV, 28% of transactions
– Q4 2015– TPV of $82 Billion, $10400 / second– Growing 29% YoY– 1.43 Billion transactions, 15.6 million payments / day– Mobile: 25% of TPV, 45% volume growth
– 22% cross border trade
In a globally dynamic environment– 300+ features per quarter; 100K+ LOC every two weeks– 17K employees across the globe
PAYPAL API PLATFORM USAGE OVER THE YEARS
3
PayPal API
PayPal Capabilities
API PLATFORM CHALLENGES (2012)
4
External API
• Multiple developer portals
• Overlapping, inconsistent APIs
• Learn from large documents
• Complex sign-up process
• Incomplete, unreliable Sandbox
Internal SOA
• Discovery through tribal knowledge
• Overlapping, inconsistent APIs
• Integrating with an API took weeks
• Tight coupling; monoliths
• Proprietary standards & technology
5
API PLATFORM – CURRENT (2012) & TARGET
API Definition Internal or External Universal
API Discovery Painful Developer Portal
API Design Project specific API as a Product
Architecture Tightly coupled SOA Loosely coupled SOA
Technology Proprietary Standards based
Integration Expensive TTFHW1 < x min
(1) Time To First Hello World – Time to make a simple call/application using APIs
6
PAYPAL API PLATFORM
Portfolio of APIsaligned by business capabilities,
realized by isolated and encapsulated services,that can be used by internal and external developers
to develop applications and integrations quickly and cost effectively
7
BUILDING A GOOD API AND MICROSERVICE
API First
API as a Product
• Work back from end customer use cases• API Design Standards
• Capability and domain modeling• API portfolio
Developer Experience• Easy to learn, integrate, diagnose• Time To First Hello World
API Quality Attributes• Response time• Availability
Service Implementation• Isolation of code and data• Encapsulation
MO
NO
LITH M
ICR
OS
ER
VIC
ES
8
LOOSE COUPLING• API Portfolio
• Orthogonal capabilities• Bounded contexts• Related by “foreign keys”
id
id
/invoicing /payments
/risk
Domain model API• Entities, Attributes• Verbs• Relationships• State machine, Domain events
How is your implementation prioritizing
customer needs vs. cost?
• API• Domain model Problem space• No shared definitions• Agreement on vocabulary & standards
• Service implementation• Reuse = Coupling• Tolerance to latency & availability• Code & data isolation
9
Microservice Granularity• Cohesive
• Should realize a cohesive and loosely coupled capability• Adaptability
• Should not mix functionality exposed to different rates of change• Scalability
• Should not mix different levels of scalability• Security
• Should not mix different levels of security
Granularity is usually a function of
company growth stage and organization structure
TARGET STATE - RUN-TIME ARCHITECTURE
10
API Facade
Payments Instruments Customer
Credit Risk Compliance
Invoicing
Disputes
PayPal Applications(Wallet, POS)
2nd-party Applications
(eBay, Braintree)
3rd-party Server Applications
(Online websites)
PayPal Web Applications
Experience APIs
Capability APIs
Event Bus
Webhooks
3rd-party Mobile Applications
(Uber, PhotoCard)
BatchProcessing
ExternalNotifications
Batch APIsProtocol conversion
OAuth, CORSRoutingOrchestration
11
MATURITY MODEL FOR MANAGING CHANGEMaturity
LevelMaturity Level
Name Characteristics (Design, Functional, Operational)
Level 1 Exists All services (classic & new)
Level 2 Functional Complies with API standards, fully tested, basic documentation
Level 3 Core API aligned with product structure, complete developer experience
Level 4 Performant Complies with Service Level Objective (response-time, availability)
Level 5 Ideal Fully isolated (code & data) and encapsulated
Shared 2014 Goal for completing at least 75% of platform at Maturity Level 3+Shared 2015 Goal for completing at least 50% of platform at Maturity Level 5
12
API EVOLUTION – THE JOURNEY
2016
NORM
2012
INITIATED
President buy-in
Company mandate
Seed organization
Right people
2013
EXTERNAL
Launched externally
Started internally
Early adopters
2014
EXPANSION
Complete majority
Educate, evangelize
Recognize success
2015
MANAGE LEGACYRetire internal legacy
Transition to norm
Webhooks
13
TO CLOSE
• Business imperative has prioritized agility over cost efficiency
• Agility comes from flexible architectures and short cycle times
• Flexibility comes from APIs and loosely-coupled (micro) services
• Moving to a flexible architecture needs persistence and air cover
• Culture has to go hand-in-hand with architecture for sustenance
14
Thank You