LinkedIn
Twitter
@Andrew Barickman , Welcome to Apigee Community !
Great Questions, Please find details below.
1. They are moving forward with implementing Apigee for API calls originating from outside their network and requiring access to internal systems. They are also likely going to be using it for internal application traffic. Does this pose any risks that they should be aware of? Is there a case to NOT do this?
- Above scenario is very usual that we see across our customers starting from Telcos to Banks, Retailers, HealthCare , FinTech, Insurance and many others. Apigee Edge platform is built for security by default. We support two way TLS between NorthBound & SouthBound endpoints.
- Apigee provides end to end security at all points of engagement.
- Apigee Edge can be hosted on 3 deployment models. Cloud, OnPremises,Hybrid. We do support onPremises where entire Apigee Edge platform can run on your own data centers. For example many Telcos use Apigee Edge OnPremises due to compliance & regulatory guidelines.
- Find more details related to Apigee Edge Security in this deck here.
2.They have external vendors who may need APIs to interface with other external vendors. They also have potential for public cloud applications running on AWS, or the like, to access other eternal vendors or platforms. In this case they don't want to have traffic routed through their network just to go back to the cloud. Is there a hybrid configuration of Apigee (cloud and on-prem) that would be recommended for this scenario?
- Yes, Apigee supports hybrid deployment model along with Cloud & OnPremises using a light weight micro-gateway called Edge Micro. Find more details about same here.
- Apigee Edge also has reference architectures & integrations with GCP, AWS, Pivotal & many other where you can use this hybrid concept. Find more about our Pivotal Integration service here and AWS here.
- We have active customers who use above deployment model for their APIs.
3. If they route all traffic through Apigee it creates a single point of failure. What does a mitigation strategy for this look like?
- High availability in an Apigee Edge implementation is achieved by deploying multiple nodes in each of the Apigee service layers to eliminate a single point of failure. For disaster recovery and geo-scaling, Apigee can be deployed in multiple data centers in geographically distributed regions.
- Apigee Edge is built for scalability & availability. Apigee Edge supports Multi Data Center Deployment, Multi Region Traffic Management, Zero DownTime deployment, Traffic Isolation, Scale with state, Independent scaling.
- 60 % of Top 10 global retail brands & Telcos API traffic goes through Apigee Edge. Some of the stats from last black friday include 99.999 % Availability, 50000 peak requests per second, 3x scale YOY, 1.5 Billion + Transaction / Day.
- The Apigee Edge software architecture is made up of a number of components to support fault-tolerance and high availability. All API traffic is handled by stateless components that are horizontally scalable. State is maintained in modern storage systems designed for the cloud, i.e. the storage components are fault tolerant and distributed by nature. We run in a virtual private cloud hosted by Amazon. Our SLA therefore is dependent on Amazon's stated SLA. For a single region deployment Amazon provides 99.9% availability SLA. We can offer 99.99% availability by deploying to multiple geographic regions in Amazon's cloud. Even in a single region deployment, any customer's API traffic is served through multiple layers of redundancy and Amazon availability zones. In an on-premises deployment availability is dependent on the infrastructure availability and the chose deployment footprint.
If you have any further questions, Apigee Team is happy to assist. Please keep us posted.
