[AUTHOR]

1. [DATE] On-Premise Environment Specification [AUTHOR]

2. Preconditions and Disclaimer • This deck is based on documentation available from Blueprint Confluence Site: • Apigee-Enterprise-Sizing-Questionaire.doc: This document includes rough estimates provided by the customer on the anticipated demand. This document should be provided by Apigee Presales Team • After further analysis on the actual demand with the customer, it is recommended to review initial assessment to ensure that it is still appropriate to meet the demand • Generic Sizing Guide: This spreadsheet provides more information on how to calculate points based on API policies and the number of recommended nodes. Please be aware that this is a very rough estimate, but it is useful for approximate capacity estimation purposes. As API development progresses and it’s ready for production deployment, it is always recommended to run performance tests on an environment with actual production capacity requirements [ - Review initial estimation from Presales - Review sizing the guide]

3. Change Log [This document usually goes through several phases where client infrastructure team reviews, provides feedback, then feedback gets incorporated and presented again to the customer. See notes on each slide. For additional items to cover to complete this document.] • V1 • Added more information about inter-node communications • Moved Developer Portal back to application zone, and developer portal DBMS to secure data zone.

4. Architecture Overview (Component View) • The four high level blocks of Apigee Enterprise are API Services, Analytics Services, Developer Services and App Services [General architecture overview. This is generic and customer agnostic. No need to adapt to customer requirements] App Services Stack App Services Portal APP SERVICES API SERVICES Router Message Processor ANALYTICS SERVICES apacheds / openldap zookeeper cassandra qpidd Backend Client Key: Enterprise UI Management Server Qpid / Ingest Server Apigee 3rd party postgreSQL Note: All components of API and Analytics Services also talk to zookeeper Postgres Server Developer Portal DEVELOPER SERVICES mySQL

5. [Aspects to consider: • This example includes several aspect, but not limited to: • # of data centers • Capacity Growth. if the capacity needs to anticipate a growth 200%, 300% growth. TPS baseline should be bumped up those values. • Payload Size • Caching • SOAP and Transformations • Rate limiting policies • Quota • Security (encryption and key management) • Data retention • Testing approaches. Similar production environment • Rule of thumb 1,000tps per CU, however it can be more complex. Use reference architecture document for additional examples • Inquire about processes that can drive storage increase. E.g. Storing data in key value pairs including its volume • Etc. • Review load requirements with customer. Refer to Instance Sizing Estimator and Sizing Questionnaire] Known Architecture Requirements • Development and Test • Single data center • Approximately 1/3 capacity of production • Development and Test are on two different Apigee instances • Staging and Production • Active-active configuration, with either data center able to handle all API traffic • 300 TPS sustained load with 500 TPS peaks • Payload sizes range from 10k (80%) to 100k (20%) • Response caching with 1 hour duration • REST to SOAP Transformation • Rate Limiting • Quota / SLA • OAuth and/or API key validation • XML and JSON attack protection • Analytics data retention: 6 months • Staging and Production are on two different Apigee instances

6. Data Center Layout: • Illustrate # of nodes to be laid out • In this example customer mostly deploys on VM (Virtual Machines) rather than physical boxes • Include number of nodes per component based from the estimation tool • Illustrate security applied to each node. In this example most nodes are behind a first line firewall and data is behind a secure data zone • Illustrate type of traffic from each node Preliminary Architecture Logical Overview: Enterprise-Level View, Production and Staging DMZ Zone Application Zone SECURE DATA Zone API Traffic QPid Apigee Gateways(x 2) Analytics DB - Postgres (1 x VM RHEL6) Analytics api.customername.com (ELB) LB VIP – 10.66.162.40 Health Check Prob: 443 https Qpid Ingest Data Replication OpenLDAP (1 x VM RHEL6) Browser (HTTP) Cassandra (3) + Zookeeper (3) (3 x VM RHEL6) ManagementServer DC 2 Consumer App api.customername.com (ELB) LB VIP – 10.66.162.40 Health Check Prob: 443 https QPid Apigee Gateways(x 2) Analytics DB - Postgres (1 x VM RHEL6) Qpid Ingest OpenLDAP (1 x VM RHEL6) Cassandra (3) + Zookeeper (2)(3 x VM RHEL6) ManagementServer DC 1 External Management App Apigee Developer Portal (1 x VM RHEL6) Developer Portal DBMS - MySQL (1 x VM RHEL6) Firewall Firewall

7. Notes: • Set expectations about high availability and disaster recovery aspects e.g. Which components require either automatic or manual intervention • Address any concerns about security by explaining VPN channel encryption • Set expectation about data security best practices e.g. Requirement of a second line firewall • Set expectations about which elements are critical for APIs to operate. E.g. If Developer Channel Services or Management Servers go down what happens to the APIs • Then explain the recommendation on having HA in some nodes Preliminary Architecture Characteristics: Staging/Production • Active-active topology for API traffic, both within and across data centers • Either management server can be used to control all active nodes • Analytics in active-passive mode; in the event of analytics component failure in one data center, requires manual action to switch Analytics to alternate data center • Connection between secure data zones is a dedicated line; The two data centers would be connected via VPN, then no further encryption is necessary • Developer Portal and associated MySQL DBMS hosted in a single data center; linked to Apigee via Management API (although it could be HA • Cassandra, Zookeeper, Postgres, OpenLDAP and Portal MySQL reside in secure data zone • Portal connection to MySQL DBMS is encrypted • Machine sizing as noted in the charts at the end of this presentation

8. Notes: • Explain the impact of a data center going down. E.g. what components need to be managed manually Preliminary Architecture Logical Overview: Data Center 2 Failure DMZ Zone Application Zone SECURE DATA Zone API Traffic seamlessly routed by session distribution and load balancer to active data center. No other impact. QPid Allas-apigw-test.lt.bwns.ch LB VIP – 10.66.162.40 Health Check Prob: 443 https Apigee Gateways(x 2) Analytics/Metering DB - Postgres (1 x VM RHEL6) Qpid + Secondary Ingest Cassandra + Zookeeper (3 x VM RHEL6) ManagementServer OpenLDAP (1 x VM RHEL6) DC 2 QPid Apigee Gateways(x 2) Analytics/Metering DB - Postgres (1 x VM RHEL6) Allas-apigw-test.lt.bwns.ch LB VIP – 10.66.162.40 Health Check Prob: 443 https Qpid + Primary Ingest Cassandra + Zookeeper (3 x VM RHEL6) Consumer App ManagementServer OpenLDAP (1 x VM RHEL6) API Traffic DC 1 Analytics Apigee Developer Portal (1 x VM RHEL6) Developer Portal DBMS - MySQL (1 x VM RHEL6) Data Replication Firewall Firewall

9. Preliminary Architecture Logical Overview: Data Center 1 Failure DMZ Zone Application Zone SECURE DATA Zone QPid Allas-apigw-test.lt.bwns.ch LB VIP – 10.66.162.40 Health Check Prob: 443 https Apigee Gateways(x 2) AnalyticsDB - Postgres (1 x VM RHEL6) Qpid + Secondary Ingest XSGTest 1/2 Cassandra + Zookeeper (3 x VM RHEL6) ManagementServer OpenLDAP (1 x VM RHEL6) DC 2 API Traffic seamlessly routed to active data center. Zookeeper observers manually promoted. Analytics manually switched to passive system. QPid Apigee Gateways(x 2) AnalyticsDB - Postgres (1 x VM RHEL6) Allas-apigw-test.lt.bwns.ch LB VIP – 10.66.162.40 Health Check Prob: 443 https Qpid + Primary Ingest Cassandra + Zookeeper (3 x VM RHEL6) ManagementServer OpenLDAP (1 x VM RHEL6) API Traffic DC 1 Analytics Apigee Developer Portal (1 x VM RHEL6) Developer Portal DBMS - MySQL (1 x VM RHEL6) Data Replication Firewall Firewall

10. Notes: • Clarify which environments are either single or multi data center • Clarify which elements are stateless and horizontal scalability possibilities • Explain specific aspects about C* nodes. Specifically about disaster recovery, replica managements and any requirements to secure data Preliminary Architecture Characteristics:Development/Test • Single data center topology • Redundant router-message processor pairs provide a level of redundancy for API traffic. Required to test failover • Analytics deemed non-critical; no redundancy specified • Cassandra, Zookeeper, Postgres, OpenLDAP and MySQL nodes can be moved to secure data center if needed • Machine sizing as noted in the charts at the end of this presentation

11. Single Data Center View: Illustrate data flow between each component for a single data center (for DEV and TEST) Preliminary Architecture Logical Overview: Single Data Center View Read from Ingest Internet Application Zone SECURE DATA Zone Ingest DBMS access Development Client (x) AnalyticsDB - Postgres (1 x VM RHEL6) Apigee QPid (1 x VM RHEL6) Apigee Qpid Ingest (1 x VM RHEL6) Analytics data Analytics data DMZ Zone API traffic api.customername.com (ELB) LB VIP – 10.66.162.40 Health Check Prob: 443 https Configuration and Key Management Access API traffic API traffic Cassandra + Zookeeper (3 x VM RHEL6) Consumer Apps (2) Apigee Gateway (2 x VM RHEL6) Configuration and Key Management Access HTTP traffic RPC LDAP access Management Server (1 x VM RHEL6) OpenLDAP (1 x VM RHEL6) Management API Database access Apigee Developer Portal (1 x VM RHEL6) Developer Portal DBMS - MySQL (1 x VM RHEL6) Firewall Firewall

12. Single Data Center View: Ports. This is generic and customer agnostic. No need to adapt to customer requirements] Deployment (Connections and Ports) w/o App Services client / load balancer • Notes: • For CS all nodes talk to all other CS nodes • For ZK all nodes talk to all other ZK nodes customer specific customer specific M R 80811100 Target Backend 4527 R 8998 M MP MP 8082 1101 CS ZK Key: MP 4528 MP ZK: 21812888, 3888 CS: 7000 7199, 9160 MS: management server UI: enterprise UI R: router MP: message processor QIS qpid/ingest server QD: qpid daemon PS: postgres server PG: postgreSQL (db) ZK: zookeeper CS: cassandra AD: apacheds OL: openldap DP: developer pportal MY: mysql QD:5672 ZK: 2181 CS: 9160, 7199 ZK: 2181 CS: 9160,7199 CS ZK QIS M QD QIS QIS: 80831102 QIS: 4529 QIS CS ZK MS MS MS MS MS 10389 UI MS AD / OL MS MS: 8080 UI: 9000 MS: 8080 PS: 4530 PG: 5432 PS PG-master PS PG: 5432 PG PG: 5432* to from PG: 5432 PG 1-way PS PG-standby PS svc:port M 2-way PS: 8084 1103 management calls, e.g. curl or browser DP M DP 3306 DP MY

13. Preliminary Architecture Logical Overview: Open Port Requirements - Single Data Center View HTTP (5672, tcp) Ingest SQLNet (5432, tcp) Internet Application Zone SECURE DATA Zone Development Client (x) Apigee QPid (1 x VM RHEL6) Apigee Qpid + Ingest (1 x VM RHEL6) Analytics DB - Postgres (1 x VM RHEL6) Postgres Client (5432, tcp) Zookeeper Client (2181, tcp) HTTP (5672, tcp) HTTP (5672, tcp) DMZ Zone HTTP/S (80, 443, tcp) Zookeeper Client (2181, tcp) Cassandra Client Thrift (9160, tcp) Allas-apigw-test.lt.bwns.ch LB VIP – 10.66.162.40 Health Check Prob: 443 https Zookeeper Client (2181, tcp) HTTPS (443, tcp) HTTP (80, tcp) Cassandra + Zookeeper (3 x VM RHEL6) HTTP/S (80, 443, tcp) Cassandra Client Thrift (9160, tcp) Apigee Gateway (2 x VM RHEL6) Zookeeper Client (2181, tcp) HTTP/S (80, 443, 8080 tcp) Apigee RPC (4526, tcp) XSGTest 1/2 (2) LDAP (389, tcp) HTTP/S (80, 443, tcp) OpenLDAP (1 x VM RHEL6) Management Server (1 x VM RHEL6) HTTP/S (80,443, tcp) default is HTTP on 9000) HTTP (8080, tcp) Management API MySQL DB Client (5432, tcp) HTTP/S (80, 443, tcp) nevisProxy WAF Ad Novum (1 x VM RHEL6) Apigee Developer Portal (1 x VM RHEL6) Developer Portal DBMS - MySQL (1 x VM RHEL6) Firewall Firewall

14. Deployment Planning: Installation Prerequisites • Operating System • RedHatEnterprise Linux 5.8 / 6.3, or Centos 5.7 / 6.3 • 64-bit architecture only • Java • 64 bit Oracle JDK 1.6 (32 bit JDKs, JDK 1.7 and OpenJDK are not supported) • IP settings • The commands ‘hostname’ and ‘hostname –I’ should show the correct hostname and IP address (not 127.0.0.1) • Firewall • Depending on final system configuration, some ports may need to be opened in the firewall • Disk space • Large disks are suggested to accommodate Cassandra databases, log files, Postgres databases, etc. • Additional Tools • The following UNIX tools are used during installation: awk, basename, bash, curl, date, dirname, echo, expr, grep, hostname, id, ls, ps, pwd, python, rpm, rpm2cpio, sed, tar, tr, uname, unzip, wc, yum • If the servers are not time synchronized, consider using ntpdate

15. General considerations applicable to all installations. Include anything relevant Deployment Planning: Resource Considerations • All other things being equal (and cost aside!), physical hardware will perform better than virtualized • Whenever possible, use GbE (Gigabit Ethernet) on routers, message processors and Cassandra nodes • Disk space is a major consideration for Cassandra and QPid nodes and for Postgres DB. Actual requirements depend heavily on API policy implementation, Analytics data retention policies, etc.

16. Based on estimation tool and review with PreSales and Ops. Slide based on average requirements Deployment Planning: Development and Test Server Requirements

17. Deployment Planning: Development and Test Server Requirements (cont’d.) * subject to change as policy requirements become known

18. See sizing guide. Use complexity points to review # of nodes paying particular attention to MPs, Routers and C* Nodes. Since there is the bulk of processing. e.g. 24 nodes in HA can be assigned as: 4-6 Routers, 12 MPs, and 6 C* nodes Deployment Planning: Staging and Production Server Requirements

19. Deployment Planning: Staging and Production Server Requirements (cont’d.) * subject to change as policy requirements become known

20. Capture action items during the review. This slide may include hints monitoring, disaster recover, backup action items procedures. Refer to monitoring and backup guide Next Steps • Further refinement of specific API requirements, including (for example): • REST API design (if not complete) • Transformation characteristics • Specific details of SLA, rate limiting parameters, etc., including possibility of managing two different endpoints with different SLAs • Developer Portal • Consent application • Further discussion regarding OAuth best practices (if needed) • Elaboration on operational and management considerations around: • Monitoring (Nagios) • Disaster recovery (failover/failback) procedures • Backup and recovery procedures

21. Questions?