API Management Transition to AWS

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.

Impacts:

  • 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.)

Impacts:

  • 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.

Benefits

  • 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.

Topics