You may remember that last June we originally announced some “big improvements.” The improvements were so big, in fact, that the campus required a full architectural review to ensure that our mission critical service would be secure, performant, and supportable. The good news is that as a result of that successful review, we can now even more confidently announce that…
We're making big improvements to Berkeley's API Management service.
We're transitioning to the Amazon Web Services (AWS) cloud platform for our API Management service. While most changes are occurring behind the scenes and will be transparent to you, we'd like to highlight the impacts, familiarize you with the project, and preview upcoming communications.
Impacts on those who use APIs, starting August 16:
- You’ll need to change the host for all API calls from “apis.berkeley.edu” during a three month transition period.
- No changes or access requests will be allowed on the current “API Central” developer portal—it will be deprecated and “read-only.”
- The secret "app_key" portion of credentials will no longer be stored in the portal. It will be displayed only once upon creation, so you’ll need to copy, secure, and manage it locally. (The recommended way to do this is to create a group LastPass Enterprise account to manage them.)
Details
Our API Management service consists of two components–both changing as part of this transition.
API Central Developer Portal
The web application at "https://api-central.berkeley.edu" is the portal used to explore APIs and manage access to them. This application is already running in Amazon's Elastic Compute Cloud (EC2), and will remain largely the same.
Changes include:
- As mentioned above, the deprecated portal will be “read-only”—all changes must be made on a new version.1
- The URL for the portal will change (specifics to come).
- As mentioned above, you’ll need to manage your access secrets locally.
- The form used to submit or change APIs will be more detailed to meet the requirements of Amazon's API Gateway (details to follow).
API Service Gateway
The proxy service at "apis.berkeley.edu" forms a gateway unifying access and obfuscating physical locations of managed APIs. We are replacing this on-premise load-balanced NGINX with AWS Application Load Balancer and NGINX running in EC2. Behind the scenes, we've been using Red Hat's 3Scale product to manage access to and control usage of APIs. The greatest impact to our service is that we’re replacing this with Amazon's API Gateway. (For now, fine-grained authorization will still be provided by our on-premise IBM DataPower appliance.)
Changes include:
- As mentioned above, you’ll need to change the host for every API call (specifics to come).
- Hosts in Berkeley's RFC 1918 private network space will need to be configured for Network Address Translation (NAT) service in order to make API calls (details to follow).
- All APIs will have upper limits on the number of calls accepted per second and per day by any specific client. These initially will be set so far above current usage rates that no impact is expected. Over time API providers may choose to adjust these down to protect backend services better.
Milestones
August 15: API Central Developer Portal Deprecated
- Current developer portal deprecated and user interface set to ‘read-only”
August 16: Transition Period Begins
- New developer portal available for production use (specifics to come)
- Current API gateway deprecated, though still supported1
- New API gateway available for production use (specifics to come)
November 11: Transition Period Ends
- Deadline for API consumers to change their applications to call APIs via the new gateway
- Deprecated developer portal and API gateway taken off-line
Future Communications
In the coming weeks, we'll send targeted email
to API providers:
- Detailing applicable API Central portal and gateway changes
- Declaring initial rate limits for each of the APIs they own
- Alerting to the approaching developer portal freeze
to API consumers:
- Detailing applicable API Central portal and gateway changes
- Alerting those making calls from RFC 1918 space to arrange for NAT service
- Declaring initial rate limits for every API
- Alerting to the approaching developer portal freeze
During the transition phase, we'll send targeted email
to API providers:
- Reporting performance comparisons for their APIs
- Listing consumers still making calls via the deprecated gateway
- Alerting to the approaching shut down of the deprecated platform
to API consumers:
- Listing calls they're still making via the deprecated gateway
- Alerting to the approaching shut down of the deprecated platform
Upon project completion, well send email
to all clients:
- Reporting on the new platform’s performance and status
Stay tuned for more information over the coming weeks. If you have any questions, please reach out to us at eis-support@berkeley.edu.