SlideShare uma empresa Scribd logo
1 de 17
April 10, 2014
The Power of Internal API Programs
Bala Kasiviswanathan
@balak
Chris von See
@apigee
CC-BY-SA
Youtube.com/apigee
3
CC-BY-SA
slideshare.com/apigee
4
CC-BY-SA
community.apigee.com/learn
5
CC-BY-SA
The Nature of API Relationships
API relationshipCuration Control
Consumption Exposure
Open adoption API
consumers
Business partners
Internally-developed
applications
Internal-only business
systems
6
CC-BY-SA
The Nature of API Relationships
API relationship
“External”
API program
Curation Control
Consumption Exposure
Open adoption API
consumers
Business partners
Internally-developed
applications
Internal-only business
systems
7
CC-BY-SA
The Nature of API Relationships
API relationship
“External”
API program
Curation Control
Consumption Exposure
“Internal”
API program
Open adoption API
consumers
Business partners
Internally-developed
applications
Internal-only business
systems
8
CC-BY-SA
“API First”
9
• API adaptations needed for
apps
• Enable developers for
business
• Security for app-to-API
• App and behavior analytics
• APIs architected for
abstraction
• Enable developers for API use
• Security for API-to-backend
• API analytics
APIAPI
API consumption API exposure
API tier ServicesApp
Analytics
CC-BY-SA
External API programs Internal API programs
Comparing External and Internal API Programs
• For open-adoption APIs, developer
outreach/evangelism is important
• Exclusively externally-accessible APIs
• Developer support resources (docs,
tools, etc.) all open
• Security on untrusted developers is
tighter
• Tighter resource access controls and
constraints are an integral part of the
developer relationship
• Monetization is often an important
aspect
• API capacity is usually shared
• Design is often optimized for specific
use cases
• Normally no evangelism except internal
• Combined externally and internally
accessible APIs
• Some developer support resources not
available externally
• Security constraints may be
implemented differently
• Resource controls may be substantially
loosened, at the risk of possible (and
inadvertent) over-consumption
• Monetization is rarely important, but
resource accounting may be
• API capacity can be shared or
dedicated
• Design is more general in nature
10
CC-BY-SA
Thinking “Internally” about API Consumption
• Consolidate interaction channels at the API tier
• Develop a strategy for leveraging things you already know in reusable ways
• User interactions
• Social media data
• Establish mechanisms for bi-directional data sharing that don’t necessarily involve APIs
• Backend-as-a-Service
• State data
• Re-evaluate authentication, authorization, resource allocation access scope definitions, and
threat protection
API Consumption
API
API Tier ServicesApp
API
API Exposure
11
CC-BY-SA
“Internal” Consumption Case Study: Apparel
12
The challenge:
• Be a social brand and control the social conversation
• Enhance the customer experience by building an application that brings disparate customer data
sources together to help employees personalize customer shopping experiences
Apigee infrastructure
Web Mobile Point of sale
B2E application
CC-BY-SA
Thinking “Internally” About API Exposure
13
• Ensure that you have visibility into the ways that services or systems interact for:
• Point-to-point interactions
• Operational visibility
• Resource accounting
• Business continuity
• Auditing
• Elimination of redundancy
• Consistency in API contracts can facilitate consumption-layer development
• Evaluate your API versioning and deprecation strategy in order to avoid “gut-
wrenching” change
• Build authentication into even your origin server interactions
• Think about ways to share data across APIs and services
API Exposure
API
API tier ServicesApp
API
API Consumption
CC-BY-SA
“Internal” Exposure Case Study: News and
Information
1414
The challenge:
• Build a shared service to integrate siloed business units
• Allow leveraging of services across business units without point-to-point integration
• Maintain visibility into and understanding of service usage
• Build a resource accounting model based on service consumption
Shared Apigee infrastructure
Business unit one Business unit two Business unit three
CC-BY-SA
• There’s a need to get “out of the box” and start thinking of APIs in ways
beyond the traditional external API program.
• This new “internal API program” can be thought of in terms of the “API
first” architecture and the distinctions drawn between API consumption
and API exposure.
• Both perspectives can benefit significantly from key functionality
available in the “API tier”
– Visibility through analytics that can give a clear understanding of service
interactions and help to avoid nasty surprises
– Control and threat protection through common authorization/authentication
and threat protection
– Shared state that facilitates building an optimal user experience
– Backend-as-a-Service capabilities to support API consumption and provide
an additional data-level integration capability
The Take-Aways
15
Bala Kasiviswanathan
@balak
Chris von See
@apigee
Questions?
Thank you
youtube.com/apigee
slideshare.com/apigee
linkedin.com/company/apigee

Mais conteúdo relacionado

Mais de Apigee | Google Cloud

Mais de Apigee | Google Cloud (20)

How Secure Are Your APIs?
How Secure Are Your APIs?How Secure Are Your APIs?
How Secure Are Your APIs?
 
Magazine Luiza at a glance (1)
Magazine Luiza at a glance (1)Magazine Luiza at a glance (1)
Magazine Luiza at a glance (1)
 
Monetization: Unlock More Value from Your APIs
Monetization: Unlock More Value from Your APIs Monetization: Unlock More Value from Your APIs
Monetization: Unlock More Value from Your APIs
 
Apigee Demo: API Platform Overview
Apigee Demo: API Platform OverviewApigee Demo: API Platform Overview
Apigee Demo: API Platform Overview
 
Ticketmaster at a glance
Ticketmaster at a glanceTicketmaster at a glance
Ticketmaster at a glance
 
AccuWeather: Recasting API Experiences in a Developer-First World
AccuWeather: Recasting API Experiences in a Developer-First WorldAccuWeather: Recasting API Experiences in a Developer-First World
AccuWeather: Recasting API Experiences in a Developer-First World
 
Which Application Modernization Pattern Is Right For You?
Which Application Modernization Pattern Is Right For You?Which Application Modernization Pattern Is Right For You?
Which Application Modernization Pattern Is Right For You?
 
Apigee Product Roadmap Part 2
Apigee Product Roadmap Part 2Apigee Product Roadmap Part 2
Apigee Product Roadmap Part 2
 
The Four Transformative Forces of the API Management Market
The Four Transformative Forces of the API Management MarketThe Four Transformative Forces of the API Management Market
The Four Transformative Forces of the API Management Market
 
Walgreens at a glance
Walgreens at a glanceWalgreens at a glance
Walgreens at a glance
 
Apigee Edge: Intro to Microgateway
Apigee Edge: Intro to MicrogatewayApigee Edge: Intro to Microgateway
Apigee Edge: Intro to Microgateway
 
Managing the Complexity of Microservices Deployments
Managing the Complexity of Microservices DeploymentsManaging the Complexity of Microservices Deployments
Managing the Complexity of Microservices Deployments
 
Pitney Bowes at a glance
Pitney Bowes at a glancePitney Bowes at a glance
Pitney Bowes at a glance
 
Microservices Done Right: Key Ingredients for Microservices Success
Microservices Done Right: Key Ingredients for Microservices SuccessMicroservices Done Right: Key Ingredients for Microservices Success
Microservices Done Right: Key Ingredients for Microservices Success
 
Adapt or Die: Opening Keynote with Chet Kapoor
Adapt or Die: Opening Keynote with Chet KapoorAdapt or Die: Opening Keynote with Chet Kapoor
Adapt or Die: Opening Keynote with Chet Kapoor
 
Adapt or Die: Keynote with Greg Brail
Adapt or Die: Keynote with Greg BrailAdapt or Die: Keynote with Greg Brail
Adapt or Die: Keynote with Greg Brail
 
Adapt or Die: Keynote with Anant Jhingran
Adapt or Die: Keynote with Anant JhingranAdapt or Die: Keynote with Anant Jhingran
Adapt or Die: Keynote with Anant Jhingran
 
London Adapt or Die: Opening Keynot
London Adapt or Die: Opening KeynotLondon Adapt or Die: Opening Keynot
London Adapt or Die: Opening Keynot
 
London Adapt or Die: Lunch keynote
London Adapt or Die: Lunch keynoteLondon Adapt or Die: Lunch keynote
London Adapt or Die: Lunch keynote
 
London Adapt or Die: Closing Keynote — Adapt Now!
London Adapt or Die: Closing Keynote — Adapt Now!London Adapt or Die: Closing Keynote — Adapt Now!
London Adapt or Die: Closing Keynote — Adapt Now!
 

Último

Último (20)

WSO2CONMay2024OpenSourceConferenceDebrief.pptx
WSO2CONMay2024OpenSourceConferenceDebrief.pptxWSO2CONMay2024OpenSourceConferenceDebrief.pptx
WSO2CONMay2024OpenSourceConferenceDebrief.pptx
 
ASRock Industrial FDO Solutions in Action for Industrial Edge AI _ Kenny at A...
ASRock Industrial FDO Solutions in Action for Industrial Edge AI _ Kenny at A...ASRock Industrial FDO Solutions in Action for Industrial Edge AI _ Kenny at A...
ASRock Industrial FDO Solutions in Action for Industrial Edge AI _ Kenny at A...
 
Where to Learn More About FDO _ Richard at FIDO Alliance.pdf
Where to Learn More About FDO _ Richard at FIDO Alliance.pdfWhere to Learn More About FDO _ Richard at FIDO Alliance.pdf
Where to Learn More About FDO _ Richard at FIDO Alliance.pdf
 
Intro in Product Management - Коротко про професію продакт менеджера
Intro in Product Management - Коротко про професію продакт менеджераIntro in Product Management - Коротко про професію продакт менеджера
Intro in Product Management - Коротко про професію продакт менеджера
 
Secure Zero Touch enabled Edge compute with Dell NativeEdge via FDO _ Brad at...
Secure Zero Touch enabled Edge compute with Dell NativeEdge via FDO _ Brad at...Secure Zero Touch enabled Edge compute with Dell NativeEdge via FDO _ Brad at...
Secure Zero Touch enabled Edge compute with Dell NativeEdge via FDO _ Brad at...
 
How we scaled to 80K users by doing nothing!.pdf
How we scaled to 80K users by doing nothing!.pdfHow we scaled to 80K users by doing nothing!.pdf
How we scaled to 80K users by doing nothing!.pdf
 
How Red Hat Uses FDO in Device Lifecycle _ Costin and Vitaliy at Red Hat.pdf
How Red Hat Uses FDO in Device Lifecycle _ Costin and Vitaliy at Red Hat.pdfHow Red Hat Uses FDO in Device Lifecycle _ Costin and Vitaliy at Red Hat.pdf
How Red Hat Uses FDO in Device Lifecycle _ Costin and Vitaliy at Red Hat.pdf
 
10 Differences between Sales Cloud and CPQ, Blanka Doktorová
10 Differences between Sales Cloud and CPQ, Blanka Doktorová10 Differences between Sales Cloud and CPQ, Blanka Doktorová
10 Differences between Sales Cloud and CPQ, Blanka Doktorová
 
Enterprise Knowledge Graphs - Data Summit 2024
Enterprise Knowledge Graphs - Data Summit 2024Enterprise Knowledge Graphs - Data Summit 2024
Enterprise Knowledge Graphs - Data Summit 2024
 
Connecting the Dots in Product Design at KAYAK
Connecting the Dots in Product Design at KAYAKConnecting the Dots in Product Design at KAYAK
Connecting the Dots in Product Design at KAYAK
 
Demystifying gRPC in .Net by John Staveley
Demystifying gRPC in .Net by John StaveleyDemystifying gRPC in .Net by John Staveley
Demystifying gRPC in .Net by John Staveley
 
WebAssembly is Key to Better LLM Performance
WebAssembly is Key to Better LLM PerformanceWebAssembly is Key to Better LLM Performance
WebAssembly is Key to Better LLM Performance
 
Introduction to FDO and How It works Applications _ Richard at FIDO Alliance.pdf
Introduction to FDO and How It works Applications _ Richard at FIDO Alliance.pdfIntroduction to FDO and How It works Applications _ Richard at FIDO Alliance.pdf
Introduction to FDO and How It works Applications _ Richard at FIDO Alliance.pdf
 
Linux Foundation Edge _ Overview of FDO Software Components _ Randy at Intel.pdf
Linux Foundation Edge _ Overview of FDO Software Components _ Randy at Intel.pdfLinux Foundation Edge _ Overview of FDO Software Components _ Randy at Intel.pdf
Linux Foundation Edge _ Overview of FDO Software Components _ Randy at Intel.pdf
 
Integrating Telephony Systems with Salesforce: Insights and Considerations, B...
Integrating Telephony Systems with Salesforce: Insights and Considerations, B...Integrating Telephony Systems with Salesforce: Insights and Considerations, B...
Integrating Telephony Systems with Salesforce: Insights and Considerations, B...
 
AI revolution and Salesforce, Jiří Karpíšek
AI revolution and Salesforce, Jiří KarpíšekAI revolution and Salesforce, Jiří Karpíšek
AI revolution and Salesforce, Jiří Karpíšek
 
Simplified FDO Manufacturing Flow with TPMs _ Liam at Infineon.pdf
Simplified FDO Manufacturing Flow with TPMs _ Liam at Infineon.pdfSimplified FDO Manufacturing Flow with TPMs _ Liam at Infineon.pdf
Simplified FDO Manufacturing Flow with TPMs _ Liam at Infineon.pdf
 
A Business-Centric Approach to Design System Strategy
A Business-Centric Approach to Design System StrategyA Business-Centric Approach to Design System Strategy
A Business-Centric Approach to Design System Strategy
 
Designing for Hardware Accessibility at Comcast
Designing for Hardware Accessibility at ComcastDesigning for Hardware Accessibility at Comcast
Designing for Hardware Accessibility at Comcast
 
Custom Approval Process: A New Perspective, Pavel Hrbacek & Anindya Halder
Custom Approval Process: A New Perspective, Pavel Hrbacek & Anindya HalderCustom Approval Process: A New Perspective, Pavel Hrbacek & Anindya Halder
Custom Approval Process: A New Perspective, Pavel Hrbacek & Anindya Halder
 

The Power of Internal API Programs

  • 1. April 10, 2014 The Power of Internal API Programs
  • 6. CC-BY-SA The Nature of API Relationships API relationshipCuration Control Consumption Exposure Open adoption API consumers Business partners Internally-developed applications Internal-only business systems 6
  • 7. CC-BY-SA The Nature of API Relationships API relationship “External” API program Curation Control Consumption Exposure Open adoption API consumers Business partners Internally-developed applications Internal-only business systems 7
  • 8. CC-BY-SA The Nature of API Relationships API relationship “External” API program Curation Control Consumption Exposure “Internal” API program Open adoption API consumers Business partners Internally-developed applications Internal-only business systems 8
  • 9. CC-BY-SA “API First” 9 • API adaptations needed for apps • Enable developers for business • Security for app-to-API • App and behavior analytics • APIs architected for abstraction • Enable developers for API use • Security for API-to-backend • API analytics APIAPI API consumption API exposure API tier ServicesApp Analytics
  • 10. CC-BY-SA External API programs Internal API programs Comparing External and Internal API Programs • For open-adoption APIs, developer outreach/evangelism is important • Exclusively externally-accessible APIs • Developer support resources (docs, tools, etc.) all open • Security on untrusted developers is tighter • Tighter resource access controls and constraints are an integral part of the developer relationship • Monetization is often an important aspect • API capacity is usually shared • Design is often optimized for specific use cases • Normally no evangelism except internal • Combined externally and internally accessible APIs • Some developer support resources not available externally • Security constraints may be implemented differently • Resource controls may be substantially loosened, at the risk of possible (and inadvertent) over-consumption • Monetization is rarely important, but resource accounting may be • API capacity can be shared or dedicated • Design is more general in nature 10
  • 11. CC-BY-SA Thinking “Internally” about API Consumption • Consolidate interaction channels at the API tier • Develop a strategy for leveraging things you already know in reusable ways • User interactions • Social media data • Establish mechanisms for bi-directional data sharing that don’t necessarily involve APIs • Backend-as-a-Service • State data • Re-evaluate authentication, authorization, resource allocation access scope definitions, and threat protection API Consumption API API Tier ServicesApp API API Exposure 11
  • 12. CC-BY-SA “Internal” Consumption Case Study: Apparel 12 The challenge: • Be a social brand and control the social conversation • Enhance the customer experience by building an application that brings disparate customer data sources together to help employees personalize customer shopping experiences Apigee infrastructure Web Mobile Point of sale B2E application
  • 13. CC-BY-SA Thinking “Internally” About API Exposure 13 • Ensure that you have visibility into the ways that services or systems interact for: • Point-to-point interactions • Operational visibility • Resource accounting • Business continuity • Auditing • Elimination of redundancy • Consistency in API contracts can facilitate consumption-layer development • Evaluate your API versioning and deprecation strategy in order to avoid “gut- wrenching” change • Build authentication into even your origin server interactions • Think about ways to share data across APIs and services API Exposure API API tier ServicesApp API API Consumption
  • 14. CC-BY-SA “Internal” Exposure Case Study: News and Information 1414 The challenge: • Build a shared service to integrate siloed business units • Allow leveraging of services across business units without point-to-point integration • Maintain visibility into and understanding of service usage • Build a resource accounting model based on service consumption Shared Apigee infrastructure Business unit one Business unit two Business unit three
  • 15. CC-BY-SA • There’s a need to get “out of the box” and start thinking of APIs in ways beyond the traditional external API program. • This new “internal API program” can be thought of in terms of the “API first” architecture and the distinctions drawn between API consumption and API exposure. • Both perspectives can benefit significantly from key functionality available in the “API tier” – Visibility through analytics that can give a clear understanding of service interactions and help to avoid nasty surprises – Control and threat protection through common authorization/authentication and threat protection – Shared state that facilitates building an optimal user experience – Backend-as-a-Service capabilities to support API consumption and provide an additional data-level integration capability The Take-Aways 15
  • 16. Bala Kasiviswanathan @balak Chris von See @apigee Questions?