Integration plays an essential role at Elsevier, a global information analytics company and one of the world's major providers of scientific, technical, and medical information. Founded in 1880, Elsevier has a bold tradition of innovation and has embraced APIs to increase availability, security and adoption of information. John Underhill, an integration architect at Elsevier, will share the success story of moving to the right API maturity model by adopting microservices and automated DevOps using WSO2 API Manager. John will discuss how they implemented a successful API program, the challenges they faced, and some of the lessons learnt. Watch the session: https://wso2.com/integration-summit/london-2019/

1. November 2019
John Underhill, Integration Architect
An API-enabled Journey
Towards Empowering the
World with Knowledge
WSO2 API Management at Elsevier
Business Technology Solutions
• The Scientific, Technical & Medical segment of the RELX
Group

2. Agenda
• Who are Elsevier?
• Why did we adopt API
management?
• How we have deployed WSO2 API
Manager
• Share some lessons learnt
2
@
Business Technology
Solutions

3. Elsevier is a global
information analytics
business specializing
in science and health

4. A few numbers about Elsevier
4

5. Elsevier employs over
1,500 technologists

6. RELX Group
• RELX is a global provider of
information-based analytics and
decision tools
• 30,000 employees
• 180+ countries
• FTSE100 company with market
cap. of £36.1bn
6

7. Business Technology
Solutions
• BTS works across the business to
identitfy and leverage advanced
technology to deliver operational
efficiency
• We work closely with colleagues in
Elsevier developing our digital products
• Based near Oxford, with colleagues
globally
• Home of the Data Insights and
Integration team

8. Why adopt API
management?
It’s been a journey…

9. Evolving integration at Elsevier: SOA
• Let’s go back to 2012
• Meanwhile, Elsevier integration is:
• On-premise
• Locked-in vendor platforms
• Lots of batch and file integrations
• Some SOAP-based web services
9
SOA Open-source APIs

10. Evolving integration at Elsevier: Open-source
• 2015 migration to Red Hat Fuse:
• Cloud deployment in AWS
• Apache Camel open-source integration framework
• Java OSGI containers
• Adopted good Continuous Integration practices
• Support for REST APIs (but we still have lots of SOAP…)
10
SOA Open-source APIs

11. Evolving integration at Elsevier: Open-source
• We needed:
• Developers to spend time
building solutions and designing
re-usable services
• To be able to on-board service
consumers quicker
• To adopt standards-based
security that could be managed
by the consumers
• It’s now 2017 and service-based
integration is working
• But…
• Integration developer experience
frustrating
• Security still inside each
integration service
• Extracting analytics and usage
data is bespoke
11
SOA Open-source APIs

12. Agile integration with APIs
• We looked for an API management
solution:
• WSO2 provided a proven solution
• Open-source fitted our direction
• Enterprise support provided a safety
net on such a critical component
• Initial PoC in late 2107
• OpenShift Container Platform adopted to
solve container issues
• Production February 2018
12
SOA Open-source APIs

13. What did WSO2 API Management give us?
• API security management
• Immediately simplified all our RESTful micro services and their lifecycle
• OAuth 2.0 used for all new REST APIs
• Developer portal
• Consumers now able to manage their own credentials
• Adoption of OpenAPI specifications
• Interactive API testing
• API lifecycle management
• Analytics
• Single view of all our integration service traffic
• Including measuring legacy passed-through SOAP and REST
13

14. Where are we now?

15. WSO2 API-M
• 3 API environments
− AWS-hosted and
fully scripted
deployment
• APIs deployed
using automated
pipelines
• Migrated to v2.6
earlier this year
15

16. APIs deployed to WSO2 API-Manager
16

17. Recent traffic through WSO2 API-Manager
17

18. Some lessons learnt

19. Use throttling
• API back-ends usually have a maximum capacity
− Particularly non-production
− Only takes 1 consumer
− Can cause a cascading failure if API Manager is not protected
• We quickly learnt API-M throttling was our friend
− WSO2 provides built-in protection
• We now insist on setting a maximum throttle for APIs
− Must be based on evidence from performance testing
19

20. Micro services != APIs
• Shift was required to consider the API as a separate product
− Interface had previously been part of integration service
− Allows more deployment flexibility
− Prevent micro APIs
• Helps facilitate design and deployment of API
− Required so we could provide API management to other teams
• Enabler to handing over further control
− Aim to handover deployment controls to API owners
20

21. Embrace OpenAPI specification
• Provides a common language
− Between teams, for design, for review
− Wide support across platforms
• May require some changes to your processes
− It’s the place to document an API
o Developer portal provides central reference
o Consumers require less support
• The developer portal quickly shows up inconsistencies between APIs
− A shared API style-guide or company standard helps
21

22. Plan your governance
• API management is process as well as technology
• Governance needs to:
− Manage on-boarding APIs
− Enforce standards
− Drive capacity planning
− Not slow delivery down
o Be appropriate to your organisation
22

23. Evolve
• We started with:
− Small number of APIs, OOTB security
• WSO2 API-M is flexible
− Being open-source means extending is straightforward
− Many deployment options
• Some examples
− Added custom security for certificates and Azure JWT
− Testing our first websocket API
− Currently exploring options for different gateway placements
23

24. In summary
• Deploying WSO2 API management has:
− Given us better API tools and security
− Provided analytics and visibility of traffic
− Simplified our integration code
− Given better developer experience
− Given faster access to APIs
− Devolved responsibility for building APIs
24
@
Business Technology
Solutions

25. Thank you
John Underhill, Integration Architect,
BTS Data Insights & Integration
November 2019