Introduction
Apigee Edge comes in several flavours: the SaaS-variant (Software as a Service), the hybrid variant in which the management plane is hosted by Apigee (Google) but the runtime plane is under your own purview and finally the Private Cloud version, a completely self-managed installation either in the cloud or in your own datacenter(s).
This blog will be talking about the Private Cloud side of things, where I will be briefly discussing an on-premise installation in a multi-datacenter environment in which I am taking part. I’ll be talking about some of our findings that could be an added value to others who decide to venture deep into the Apigee ecosystem. The workings of underlying components are outside the scope of this blog.
What is Apigee
Apigee Edge is an API management platform that acts as a multi-functional gateway you can put in front of your APIs. This allows for increased functionalities such as transforming data, analytics, monetizing your APIs, security and other fun stuff. The image below shows how Apigee Edge becomes the “middle-man” for your frontend endpoints and backend (database) services.
There’s a lot more to say about Apigee itself, but for the sake of reading time I’ll be cutting that short here, onward to the installation insights!
Apigee Edge for Private Cloud
Context
As part of an on-premise installation we are performing here with i8c it has been my pleasure as a member of the team to dive deep into the underlying components that make up Apigee Edge for Private Cloud (from now on just referred to as Apigee Edge). This project is still ongoing but I can talk about some important lessons that we have learned about this product and the on-premise implementation thereof. Apigee Edge consists of multiple components (databases, routers, management server…) working together harmoniously. As such it is recommended that your production environment splits these components in separate nodes (virtual machines) to be able to handle the work being delegated to it.
Sizing
One of the most important aspects that you will have to look at concerning your use case is going to be sizing, since this has a direct influence on costs.
Apigee recommends a default sizing for all its customers, but in practice we have found that there are some caveats to this sizing. The biggest one being that this entire sizing is based on your production needs, it’s very easy to use these default sizings and have an overblown environment with high cost but underutilizing your Apigee Edge installation.
In our use case we decided to start with an MVP (Minimum Viable Product), scaling down some of these defaults and see how it performs under expected traffic during testing. This approach needs to be based on your SLA’s, in which you have to determine the risks you are willing to take based on the availability agreements (and other) you made with customers. Sure you can test extensively beforehand, but in production there will always be something that can go wrong, so a healthy balance is needed.
Network segmentation
Whenever you are performing a large scale installation it is always advised to maintain networking best practices. In this case it consists of separating the Apigee-Router component in a DMZ, where it is exposed to the internet and other internal components in a private VLAN with a firewall for obvious security reasons.
High availability
Another key step is to identify the need for HA (High Availability), this can definitely be achieved within Apigee Edge, but it increases sizing costs. Our use case diagram below incorporates a dual datacenter setup in which we achieve HA to a certain level (based on customer needs). These 2 datacenter installations are not identical, some components may be missing or added. For example we don’t need HA on analytics so we cut back on the Qpid/Postgres nodes that are responsible for this functionality. Another example is the New Edge UI that is not default installed, this is a default requirement for our customers so this increases the sizing of our installation. You will find that your sizing can grow alongside your customers’ needs. When going for an MVP-setup like I8c is doing, you might be required to have a certain willingness for adaptability when maintaining an environment of this scale, so approach with as much information as you can.
Installation topology
The below diagram is our installation topology, initially based on the 12-node setup over 2 datacenters which is a default recommendation by Apigee.
Source: 12-node setup over 2 datacenters
If you decide to inspect these components further you will find that some aren’t listed on the topology page by Apigee, these are to be added later to support specific functionalities, but as mentioned at the start, I won’t be talking about the intricacies of the components themselves.
Ending summary
In summary, there are a lot of factors that you have to take into account when installing Apigee Edge for Private Cloud. Every use case has different requirements and specific needs, so it’s important to have a clear view on what standards your Apigee Edge service needs to live up to. There is no “one true solution” for this product, load testing with expected traffic volumes will be key in determining if your installation sizing is the right fit for your needs. However network segmentation as I’ve highlighted is best practice for (almost) any use case for Apigee Edge on-premise.
If you’ve made it this far, thanks for taking the time to read my blog!
Author: Piet Jacobs 