apidays LIVE Paris 2021 - Synchronous Communication Patterns by Sébastien Bergougnoux, Devoteam I nexDigital
0 likes206 views
The document outlines the evolution of communication patterns in technology from ESB to APIs and service meshes, emphasizing the need for secure, agile data exchanges capable of adapting to growing business demands. It discusses Devoteam's focus on technology driven by human values, the importance of modernizing IT systems, and the implementation of platforms that facilitate innovation and collaboration. Additionally, it highlights the use of the Kong API Gateway as a key component in their architecture to ensure security and efficiency in communication between services.
apidays LIVE Paris 2021 - Synchronous Communication Patterns by Sébastien Bergougnoux, Devoteam I nexDigital
- 1. Yohann Agostini CTO, Devoteam nexDigital Synchronous Communication Patterns: A Journey from ESB to APIs & Service Mesh Sébastien Bergougnoux CEO, Devoteam nexDigital
- 2. 2 Devoteam
- 3. Tech for people unlocks the future. 8,000 devoteamers in 18 countries across EMEA 25 years of passion for tech 4,000 certifications We believe technology with strong human values can actively drive change for the better. We make sure all our clients’ employees are fully on board with the transformation journey. We care about our people and offer them a workplace that fuels learning, innovation and engagement. 1 2 3
- 4. empowering you to imagine and realise better change and become a leading digital company. the platform way Tapping into their vivid ecosystems. Leveraging a tremendous source of innovation and resilience. the studio model Shifting to a product mindset. Setting up multidisciplinary teams in agile mode.
- 5. 5 5 1 We put the technologie at the heart of business transformations 2 3 A strong knowledge Our expertise is key for our partners, platform and software vendors Our Main Areas of intervention : IT modernisation to address the evolutions of the business needs of our customers Ease access to data in a secured way for their partners and customers Services orchestrations on cloud platforms « « Building together the exchange platform of tomorrow to meet the business challenges»
- 6. New York JULY Australia SEPTEMBER Singapore APRIL Helsinki & North MARCH Paris DECEMBER London OCTOBER Jakarta FEBRUARY Hong Kong AUGUST JUNE India MAY Check out our API Conferences here 50+ events since 2012, 14 countries, 2,000+ speakers, 50,000+ attendees, 300k+ online community Want to talk at one of our conferences? Apply to speak here
- 7. Simplify and control the access of the entreprise data ● Within the entreprise ● To the clients and partners ● While ensuring quality and security 1 2 3 Manage rapidly growing volumes and new uses, on demand. ● Available everywhere, all the time ● Multi device ● “Slow is the new Down” Marco Palladino CTO of Kong Facilitate agility to adapt to business needs Allow customization of services SIMPLICITY PERFORMANCE AGILITY The challenges of data exchanges
- 8. Our approach for a hybrid and modern exchange platform API SERVICE GRID EVENT DRIVEN Internal and external exchanges via API reusable (micro)services grid architecture Event streaming
- 9. 88 Creative tech for Better Change 8 8 The Mesh Use Case
- 10. The journey From ESB to API Gateway/microservices/Service Mesh Step by step
- 11. ESB ● Address the communication standards of the time: SOAP ● Ability to orchestrate and connect to heterogeneous protocols ● Platforms already designed in a devops way : ability to package, deploy and scale with central administration tools Many years ago
- 12. ESB ● Standards changed and synchronous communication became more and more REST API based ● CI/CD platforms became more and more mature to handle code and infrastructure ● The result of ESB was a implementation that mixed different aspects (protocol, security, functional mappings) ● Need vendor specifics consultants ● Scaling means also more expensive Pain points and IT standards evolution
- 13. New architecture ● API as a communication standard ● Java development with different granularity to feats with organisation roles ● A lot ot legacy to handle which resulted in a facade pattern i.e. small component to handle the API calls and abstract underlying services that can then evolve and change their granularity through the time. API
- 14. Kong project ● Time to market was really important when the decision was made to change the partner communication ● Security was a concern and an API Gateway was needed ● Kong OSS was the right software to start with for a very fast deployment in production Time to market
- 16. Kong project ● Window for the API Products ● Access for internal developers with their company credentials ● Registration for external access Portal
- 17. Kong project ● Transversal runtime referential including API exposition and upstream API. ● Use of Kong Admin API and tags. ● Proxy the Kong Admin API to authorize a ‘service account’ to only get information for this purpose. Referential
- 18. Kong project ● Standard use of OIDC ● Use of scopes in the IDP in order to handle authorization It allows to have generic implementation in Kong and handle the authorization by the team who manages IDP. Kong teams just need to know the right scopes to configure. Security
- 19. API to API communication ● The API gateway cluster deployed in DMZ to take care of the incoming flow. ● The communication between the facade API to other API requires some level of security and traceability. ● First architecture: reuse of the API Gateway, but it led to complex network communication. ● It is possible to add additional API Gateway cluster, but looking at the need we start and present the service Mesh pattern and Kuma product Complex network flows
- 20. Service Mesh Start with service mesh concept présentation Being a Kong Gateway Entreprise client, Kong materials such as Marco Palladino blog articles were highlighted Concepts The Difference Between API Gateways and Service Mesh By Marco Palladino on February 26, 2020
- 21. Kuma prototype ● Does the solution integrate well with in the information system ? ● Can the solution be deployed on our legacy infrastructure (VM redhat)? ● Is the solution in line with our strategy for managing our orchestrated container infrastructure (K8S)? ● What features are offered by the solution? ● How difficult is deployment, handling and maintenance? ● What is the level of support? (community, doc, tutorial, enterprise version) Criteria
- 22. Kuma prototype Hybrid (VM and K8s) was the key point to evaluate Integration with Kong API Gateway was also in the scope Standard architecture
- 23. Kuma ● There was no blocker during the set up ● Slack Channel is a good place to ask question ● Easy integration with the Kong Gateway ● Reduce a lot complexity in terms of networking, possibility to reduce load balancer use ● Prepare the migration from VM to K8s Feedback and Benefits ● Make the elements built around the API Gateway evolve to fit with the new architecture ○ Referential ○ Transversal security model Open challenges
- 24. Key elements ● IT standards evolve fast ● Adopt what brings value step by step ● Do not hesitate to start with simple version / use cases. ● The more you implement the more you learn and have the ability to decide. Prove the value by implementing
- 26. New York JULY Australia SEPTEMBER Singapore APRIL Helsinki & North MARCH Paris DECEMBER London OCTOBER Jakarta FEBRUARY Hong Kong AUGUST JUNE India MAY Check out our API Conferences here 50+ events since 2012, 14 countries, 2,000+ speakers, 50,000+ attendees, 300k+ online community Want to talk at one of our conferences? Apply to speak here