We're transitioning to the Amazon Web Services (AWS) cloud platform for our API Management service, which consists of two components.
1. API Central Developer Portal
The API developer portal is used to explore APIs and manage access to them. This application is already running in Amazon's Elastic ComputeCloud and will remain largely the same.
- New URL
The URL for the portal has changed to https://developers.api.berkeley.edu.
- Read Only
The deprecated portal is “read-only”—all changes must now be made on the new version.
- Safer Secrets
You’ll need to manage your access secrets locally. (The Berkeley IT Security Office provides the LastPass Business service for this.)
- New API Form
The form used to submit or change APIs will be more detailed to meet the requirements of Amazon's API Gateway.
2. API Service Gateway
The proxy service forms a gateway unifying access and obfuscating physical locations of managed APIs. We're replacing the on-premise 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 is still provided by our on-premise IBM DataPower appliance.)
- API Domain
You’ll need to change the domain for every API call from "apis.berkeley.edu" to "gateway.api.berkeley.edu" before the November 11 deadline.
- RFC 1918
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.
- Rate Limits
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.
- Lower cost
Due to economies of scale, paying only for actual use rather than fixed capacity, and more automated operational tasks, our costs will be drastically reduced by moving to the public cloud.
- Increased and scalable capacity
Even while saving lots of money, we'll be able to increase the platform's overall throughput considerably. In addition, during peaks in activity the platform will scale up automatically to maintain performance.
- Improved security
The public cloud boasts a more secure environment than even our private network. It attracts the best security personnel available, has been mercilessly tested by benign and malicious hacking, and features the latest technology and patches.
- Better operational resiliency
As great as our operations engineering staff is, they just can't compete with the collective knowledge, cognitive bandwidth, and sleeplessness of the scores of engineers AWS employs.
- Faster, easier business resumption
The redundancy, physical distribution, and abstracted design of public cloud infrastructure results in better mitigation of, response to, and recovery from any conceivable disaster.
- Greater choice of future enhancements
Rather than being locked into a vendor's roadmap, we can meet Berkeley's particular evolving integration needs by making use of AWS' large and growing menu of modular IaaS and PaaS offerings.