Craft Conference 2015 - Evolution of the PayPal API: Platform & Culture
-
Upload
deepak-nadig -
Category
Internet
-
view
450 -
download
4
Transcript of Craft Conference 2015 - Evolution of the PayPal API: Platform & Culture
Evolution of the PayPal API: Platform & Culture
Craft ConferenceApril 23, 2015
Deepak NadigHead of API Platform Engineering, PayPal
@deepak_nadig
OUTLINE
2
• Context and Challenge
• Goals and Target State
• Evolution of Platform
• Evolution of Culture
PAYPAL CONTEXT
3
– 162 million active digital wallets
– 203 markets and 100 currencies
– Serves 2M+ third-party developers
– 2013: Total Payment Volume was $180 billion
– Q4 2014
– Total Payment Volume was $64.3 Billion, $8083 / second
– Growing 24% YoY
– $12 Billion in mobile payments volume (20% of total)
– 1.06 billion transactions, 11.5 million payments / day
– 2014: Mobile – 20% of TPV, 25% of transactions
– 25% cross border trade
In a globally dynamic environment
– 300+ features per quarter; 100K+ LOC every two weeks
– 10K+ employees across the globe
PAYPAL EXTERNAL API EVOLUTION
4
PayPal External API
PayPal Capabilities
2001 Instant Payment Notification
2004 Transaction, Mass Pay API
2005 Direct Payment API, Express Checkout, Payflow
2007 Payment APIs (NVP)
2009 Adaptive APIs (SOAP/XML, NV, JSON)
2013 Payment APIs (REST)
API PLATFORM CHALLENGES (2012)
5
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
WHAT GOT US HERE WON’T TAKE US THERE
6
Social
Mobile Local
Digital
Time
Perf
orm
ance Limits
reached
Highgrowth
Kickoff
API PLATFORM – CURRENT (2012) & TARGET
7
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
PAYPAL API PLATFORM
9
Portfolio of APIs
aligned 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
BUILDING A GOOD API AND (MICRO) SERVICE
10
API First
API as a Product
• Work back from the use cases• API Design Standards
• API portfolio• Aligned by capabilities
Developer Experience• Easy to learn, integrate, diagnose• Time To First Hello World
API Quality Attributes• Response-time• Availability
Service Implementation• Encapsulation• Isolation of code and data
Elements of API Design .. 1
11
• API Portfolio
• Bounded context & Capabilities
• Organize cohesive resources
• Orthogonal and loosely coupled
id
id
/invoicing /payments
/risk
Domain Model API
• Entities, Attributes
• Verbs
• Relationships
• State machine, Domain events
API REST
• Resources, Namespaces
• Controller resources
• Hypermedia links
• Webhooks
• API Design
• Externalizable
• Domain model – Problem space
• Domain Events
• REST
• Pragmatic REST
• Consistency is built in
• Service granularity is easier
Elements of API Design .. 2
12
• Versioning
• Version products
/v1/payments
• API Specification
• Google Discovery Document
• Generate language bindings
• Loosely coupled specifications
• No shared structures
• Consistency
• Data dictionary
• Terminology
GenioGDD SDK
ISO 3166 codes, Invoice ID,
Customer ID
Invoice, Customer
Service Granularity
13
• 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
• Environments
• Should not mix constraints of different environment
Service granularity is usually a function of
company growth maturity and organization structure
TARGET STATE - RUN-TIME ARCHITECTURE
14
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
External
Notifications
Batch
APIsProtocol conversion
OAuth, CORS
Routing
Orchestration
WHAT IS CULTURE?
16
A way of thinking, behaving, or working
that exists in a place or organization
- Merriam-Webster
Organizational culture is the behavior of humans within an organization
and the meaning that people attach to those behaviors.
- Wikipedia
Culture eats strategy for breakfast
- Peter Drucker
DEVELOPMENT PROCESS
17
• Application development
• Web Page design Process
• Site design/Portfolio
Management
• API development
• API Design Process
• API Portfolio Management
• Use existing metaphors
App. Product
ManagerUED
Application
Engineering
API Product
Manager
API
Designer
Service
Engineering
HACKATHON
18
- Usability testing for APIs
- Know your developers
- Testing ground for overall DX
- Developer advocacy
ORGANIZATION STRUCTURE
19
- Conway’s law
- Reuse = Coupling
- Agreements based on standards
- Namespace != Organization
- Teams mature at different rates How do committees invent?
FACILITATING CHANGE
20
• People do what leaders do, not what they say
• Educate & evangelize
• Make it valuable to conform. Make deviations very expensive
• Enable evolution at different rates; competition helps!
• Recognize success!
SHARED GOALS & MEASURING PROGRESS
21
Maturity Level
Maturity 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 SLO (Service Level Objectives)
Level 5 IdealFully encapsulated, isolated, meets all design and implementation principles
Shared 2014 Goal for completing at least 75% of platform at Maturity Level 3+
Reported across functions and leaders
CUSTOMERS OF THE API PLATFORM
22
Customer Application: PayPal Web Application
APIs: /v1/apis/applications
Customer Application: PayPal Mobile Application
APIs: /v1/oauth2/token, /v1/wallet/{user-id}/financial-instruments
Customer Application: eBay Web Page
APIs: /v1/oauth2/token, /v1/vault/token
Customer Application: Third-party Mobile Application (based on mSDK)
APIs: /v1/oauth2/token, /v1/payments/payment
Customer Application: Third-party Web Application
APIs: /v1/oauth2/tokens, /v1/payments/paymentCustomer Application: Samsung Wallet (Samsung Galaxy S5, Gear 2, Gear Fit)
APIs: /v1/oauth2/tokens, /v1/wallet/activities
Customer Application: PayPal Touch
APIs: /v1/oauth2/tokens, /v1/payments
API EVOLUTION – THE JOURNEY
23
2016
NORM
2012
INITIATED
President buy-in
Company mandate
Seed organization
Right people
2013
EXTERNAL
Launched externally
Initiated internally
Early adopters
2014
EXPANSION
Complete majority
Educate, evangelize
Recognize success
2015
MANAGE LEGACY
Retire internal legacy
Transition to norm
TO CLOSE
24
• PayPal API & Services had internal and external challenges
• Started with API first, API as a product and Developer Experience
• Managed service granularity to fit our context
• Allowed culture change to evolve; at different rates across company
• Flexibility may be the most under-rated quality attribute!