APIdays Paris 2019 - How Carrefour is leveraging API to activate new business Chanel by Daniel Pays, Carrefour
•Download as PPTX, PDF•
0 likes•63 views
How Carrefour is leveraging API to activate new business Chanel Daniel Pays, CTO at Carrefour
Recommended
Recommended
More Related Content
Similar to APIdays Paris 2019 - How Carrefour is leveraging API to activate new business Chanel by Daniel Pays, Carrefour
Similar to APIdays Paris 2019 - How Carrefour is leveraging API to activate new business Chanel by Daniel Pays, Carrefour (20)
More from apidays
More from apidays (20)
Recently uploaded
Recently uploaded (20)
APIdays Paris 2019 - How Carrefour is leveraging API to activate new business Chanel by Daniel Pays, Carrefour
- 1. How carrefour is leveraging API to Activate new business Chanel Daniel Pays CTO Carrefour
- 2. Our journey to API 2016: Classical Legacy ● Inconsistent ● Slow API is our answer for speed 𝛌 is our answer for consistency Legacy 𝛌 {..} {..} {..} {..}
- 3. first step: 𝛌 abstraction layer Enterprise abstraction layer based on hadoop ● Data acquisition method adapted to legacy ● Cleanup ● Data Exposition method adapted to digital native architecture 𝛌 Legacy {..} {..} {..} {..}
- 4. Second step: first usage & cloud adoption First usages ● Only get First digital back-ends ● API without 𝝺 Cloud initiative in // ● Not mandatory but a technological accelerator Legacy 𝛌 {..} {..} {..} {..}
- 5. Using an API manager For governance purposes ● API re-use ● Semantic homogenization ● Securitization, protocol break ● Supervision of usage As a convenient technical asset ● Internet exposition ● Back-end protection
- 6. Usage Third Step: General Adoption.. Handle the load Contenu 2018 20192017 60 API 115 API 300 API 3 M call/ month 200M call/ month 400M call /month billion expected 2020 Inertia was defeated ● Usage growing heavily and irregularly ● Some structuring project could have severe impact on load First alertes on API exposition ● Too many new APIs ● Be aware not re-creating legacy ! ??
- 7. Cloud Migration ● 𝝺 abstraction layer migrated to public cloud ● Significant increase of API consumer & producer on clouds ● Access to cloud technology ● Legacy Api Manager on the cloud ?
- 8. Next Step ● Being confident on the load we can handle ● Reinforced API visibility for developers to avoid near duplicate expositions ● Cloud back-ends have much smaller latencies than legacy’s one. Middleware should not add too much compare to back-end
- 9. Do we learn from the past API Legacy ● API Legacy can be create much faster than decades ago. ● Speed is a risk & an opportunity
Editor's Notes
- 2016: How to transform an SI Legacy Finding: Inconsistency and slowness Slow => API Inconsistence .. ben inconsistency .. Realtime Pivot illusory => Layer of abstraction The API approach on an inconsistent system brings mixed results. We must transform the bricks independently or create a layer of abstraction Legacy. APIsation of the abstraction layer APIsation of components allowing it
- First step: Collect business data in a modernized abstraction layer Collection methods adapted to legacy Restitution methods adapted to digital architectures
- Organizing APIs around an API Manager Start of use of API consumption Appearance of the first modernized back-ends natively exposing APIs Parallel Cloud Program: Not essential for the approach but allowing access to technologies that allow us to accelerate
- Either we use it as governance either as a technical tool: equivalent of the DMZ, a reverse proxy, ... and / or expose technical APIs not visible developers or users (exposed in GW without promoting in a portal).
- Example: placing orders in a proximity store 1 API / product and per store all at the same time (5000 stores) => several thousand calls / s (need to be scalable) Do not let everyone do local optimization => community governance. But difficult to put in place. Legacy: no secret sauce but a tool like APIGEE, thanks to the portal, allowed us to separate technical API from API we really want to promote.
- One of the questions to consider when choosing an API management solution is: is it cloud native or not? APIGEE is cloud native. Our previous solution Was not. Meaning it was complexe at all level, contractual, non functional requirement,... and costs. The only good choice for the cloud is to select a cloud native solution (containerization, Kubernetes, Scalability, Pay as you go,...).
- We chase performance especially when we expose services to customers or in case of massive processing.
- Certainly as said before we can create a legacy much faster than decades ago. But hopefully we can realize it faster as well and we have a chance to correct it before we forget it. And to avoid this risk the main idea and not to create an API for a particular need but to create APIs for the greatest number. That may be the concept of "API as a Product"