The university featured in this blog began their API management story 2 years ago when they decided to adopt an API-first architecture that follows a governed process. With over 451 APIs for both external and internal customers, and several development teams working independently of one another, it is almost like managing a small city.
Modernizing the university's API management was a result of a problematic system that existed at that time. For one, the API manager in existence was closed-sourced and used an old, unsupported third party code. Adding some confusion to the mix, this university had two versions of their API infrastructure in production - having started with one version, developing a second version along the way and the migration process forever a work in progress. Due to a memory leak, boxes had to be rebooted nightly (if not all API traffic ceased by noon the next day). Furthermore, there was no monitoring of API usage and the documentation support was out of date.
Faced with all these scenarios, the university was looking to implement a new API management solution. A key need was to create a centralized repository for all the APIs, which enables developers to search for and find all the available APIs, in addition to the respective authorization processes. A seamless transition without drastic changes to their existing developer work was another one of their important requirements. Low latency, up-to-date documentation, integrating with legacy systems and the ability to keep track of all the APIs being utilized completed their wish list.
To implement their requirements, they turned to WSO2 API Manager and WSO2 Identity Server. The university now has subscriptions that allow consumers to get through to the API and subsequent monitoring; they were able to integrate all legacy systems with message mediation, minimized latency even while mediating quite heavily and of course, it is all open source. The university's model works on open subscription first, however, there are instances where they have needed to block a subscription until further approval was granted. They have been able to do this with an open source platform. Another huge plus has been the ability to utilize industry standards and the university even got something that was not available to them previously - monitoring and analytics to support their business decision making. Improving discoverability and keeping the documentation up to date were the last pending issues for the university, ultimately solved by their developer portal in the second stage of their implementation.
“Our developers who have migrated are having a fantastic experience. They're able to use things in a standard way, able to find the documentation they are looking for, utilize libraries, things aren't drastically different, all of their old systems are continuing to work and they are getting a lot better reliability out of what they're trying,” says a software engineer from the university. Adding to this success, the university has seen higher API consumption as of late and with the improvements in place, they're excited about the future.