Solved: Currently Apigee on prem - wanted to move out of o...

Former Community Member

Our team is currently using apigee on prem. We wanted to move out of on prem. What are apigee/google options available?

related to that question, what if we want to use apigee on AWS?

feigal

The latest Apigee options to move out of your on-prem environment are:

Apigee X: both control plane and runtime planes run fully managed on Google Cloud. This is simplest and lowest TCO if you can go this path.
Apigee Hybrid: control plane runs on Google Cloud, runtime planes run anywhere you can run Anthos (now "Google Kubernetes Engine Enterprise") which could be Google, AWS, on-prem, etc. A bit more complex, but a solid solution if you have a "complicated" cloud strategy at your company.

(Apigee Hybrid is also your answer to your second question, if you need to run on AWS, the runtime planes will run there)

There are variety of migration paths. Best bet is to ask your Apigee account team (or reselling partner?), they can help guide to the right solution and migration process. Do you know how to find them or can I help hunt them down for you?

View solution in original post

dchiesa1

@Former Community Member wrote:

related to that question, what if we want to use apigee on AWS

Answering a question with a question: are you sure you have a good reason to "want to use Apigee on AWS"?

As @feigal noted, you can use Apigee hybrid to run Apigee gateways on your own infrastructure in AWS. But, Just because you CAN run your Apigee gateways on AWS, does not mean you SHOULD run your Apigee gateways on AWS.

Many people want to expose AWS-based services via Apigee API Management, and from that beginning requirement quickly conclude that the gateways must also run on AWS. This is not true. We live in a cloud-connected world. Your own business probably uses 10's or maybe 100's of SaaS apps that do not run on your corporate cloud, or in your corporate datacenter. You are exploiting multi-cloud today, though you may not think of it that way.

Similarly, you can use a Google-managed Apigee - called Apigee X - to serve APIs that have their implementations running in on-prem datacenters, or in AWS EC2 or EKS, or elsewhere. There's no technical requirement that your Apigee gateways must run in the same datacenter as your APIs. In fact, Apigee Edge, the pre-cursor to Apigee X, ALWAYS ran in a separate datacenter and separate network than the API implementations. Google has hundreds of customers using Apigee Edge. The connections between Edge and the upstream APIs was always over the public internet. People use mTLS to secure these connections.

With Apigee X, it's much more flexible. You can create private network connections between GCP and your own on-prem datacenter, or between GCP and Azure, or between GCP and AWS, to allow Apigee X to manage APIs wherever they run.

Using Apigee X means allowing google to run the Apigee gateways and insuyre their reliability. This removes that burden from your responsibility. And Google is really good at it. In my experience, Google is much better at managing Apigee gateways than... pretty much anybody else. X and hybrid are the same software. Same code base, same control plane. You can think of X as "Google-managed hybrid".

The first objection I hear to my suggestion to use Apigee X, and only use Apigee hybrid if you really really need it, is: "what about the latency!?!!? I don't want to incur the extra hop across clouds!"

That is often not valid, and here's why:

if your clients are connecting into your APIs from the public network, let's say from mobile apps or mobile phones or Point-of-sale systems or anything else that is not running in your datacenter, then the client requests need to traverse the public network to get to your APIs. If you use hybrid deployed on AWS, then these clients connect into AWS, then they use an AWS-managed point-of-presence (PoP), and from there into your own regional-based Apigee gateway clusters. On the other hand if you use Apigee X, then the clients connect over the internet into GCP through a google-managed point-of-presence, and from there into the AWS network via a high-throughput private nertwork backbone. Google maintains over 140 PoPs, and the time taken to hop from client to Google to AWS infrastructure is often LESS than the time taken to hop from client to AWS Pop to AWS infrastructure. Or at the very worst case, it's a wash, or there's a single-digit millisecond additional latency. If you tell me that your API services are so fast that adding 6ms of latency is unacceptable, then maybe you might want to consider hybrid to save on latency. In the vast majority of cases, the APIs themselves exhibit 200-300ms of latency or more, even without the external network costs. So, adding 6ms is irrelevant.
what if your clients are connecting into your APIs from your corporate network? Here again, if you're running Apigee hybrid on AWS, those clients need to connect into the AWS infrastructure layer. Usually they go through some sort of "Direct Connect" to get into your AWS VPC. And from there, into your EKS cluster running Apigee hybrid. If you're running Apigee X, then the client goes through the Interconnect to get into the GCP VPC where the Apigee gateways run, and from THERE, cross-cloud interconnect into AWS. This is a BFP link (big-fat-pipe!) and it's fast and reliable. You again may see a handful of additional ms. typically the AWS and GCP datacenters are very closely situated so that speed-of-light issues are not significant. The last time I lokoed at the numbers, I saw a ~2ms round trip times between AWS us-east-1 and GCP us-east1. (The GCP networking team constantly measures this, because multi-cloud is important to so many Google Cloud customers).

Latency is almost never an issue.

On the other hand there are some cases in which data residency regulations require that you control the datacenters in which Apigee gateways run. I see this in EU countries specifically in regulated industries.

In basically every other scenario, hybrid is not necessary. In my experience, people mostly adopt Apigee hybrid for ... what I consider to be not quite valid reasons.

Latency concerns. This is the #1 reason. As explained above, this is generally not an issue. BTW, most people who cite "latency" as the reason to select Apigee hybrid over Apigee X, have literally never measured the difference. They're going with guesses. Not a good reason to use hybrid.
Their current job involves managing infrastructure and they don't like change. They don't like to relinquish the role of "managing gateways", so they default to "managing something that runs in the cloud." This is not a good reason to use hybrid.
Their current job involves managing PEOPLE who manage infrastructure, and the people manager does not want to lose responsibility. Using a managed service might mean that a team of 12 people...simply vanishes. These people can work on other things. but what happens to the manager of those people? That manager is left without a role. And sometimes organizations make decisions to preserve the status quo. This is also (my opinion) not a good reason for choosing Apigee hybrid.
It will cost more. It's true, Google charges more for a transaction running through Apigee X, than it does for a transaction running through Apigee hybrid. This is because the cost of supporting the X transaction is higher than the cost to support a hybrid transaction, because in the former case, Google runs the gateways! So you will end up paying Google more for running transactions through Apigee X, if you compare to what you pay Google for running transactions through a hybrid cluster. BUT, there are other costs to consider: the cost of the AWS cluster you must run. The cost of the people who must administer, monitor, operate, and upgrade the Apigee clusters. And multiply that out by all the various SDLC stages. So yes, you pay google more if you use X, but your net cost is less, typically much MUCH less, than if you managed the gateways yourself.

Ok, that's all I have to say about that.

I hope you found this helpful. 🙃😝

View solution in original post

feigal

The latest Apigee options to move out of your on-prem environment are:

Apigee X: both control plane and runtime planes run fully managed on Google Cloud. This is simplest and lowest TCO if you can go this path.
Apigee Hybrid: control plane runs on Google Cloud, runtime planes run anywhere you can run Anthos (now "Google Kubernetes Engine Enterprise") which could be Google, AWS, on-prem, etc. A bit more complex, but a solid solution if you have a "complicated" cloud strategy at your company.

(Apigee Hybrid is also your answer to your second question, if you need to run on AWS, the runtime planes will run there)

There are variety of migration paths. Best bet is to ask your Apigee account team (or reselling partner?), they can help guide to the right solution and migration process. Do you know how to find them or can I help hunt them down for you?

Former Community Member

I learned that I can get hold of the apigee account person. Thank you for offering to hunt somebody down 🙂

dchiesa1

@Former Community Member wrote:

related to that question, what if we want to use apigee on AWS

Answering a question with a question: are you sure you have a good reason to "want to use Apigee on AWS"?

As @feigal noted, you can use Apigee hybrid to run Apigee gateways on your own infrastructure in AWS. But, Just because you CAN run your Apigee gateways on AWS, does not mean you SHOULD run your Apigee gateways on AWS.

Many people want to expose AWS-based services via Apigee API Management, and from that beginning requirement quickly conclude that the gateways must also run on AWS. This is not true. We live in a cloud-connected world. Your own business probably uses 10's or maybe 100's of SaaS apps that do not run on your corporate cloud, or in your corporate datacenter. You are exploiting multi-cloud today, though you may not think of it that way.

Similarly, you can use a Google-managed Apigee - called Apigee X - to serve APIs that have their implementations running in on-prem datacenters, or in AWS EC2 or EKS, or elsewhere. There's no technical requirement that your Apigee gateways must run in the same datacenter as your APIs. In fact, Apigee Edge, the pre-cursor to Apigee X, ALWAYS ran in a separate datacenter and separate network than the API implementations. Google has hundreds of customers using Apigee Edge. The connections between Edge and the upstream APIs was always over the public internet. People use mTLS to secure these connections.

With Apigee X, it's much more flexible. You can create private network connections between GCP and your own on-prem datacenter, or between GCP and Azure, or between GCP and AWS, to allow Apigee X to manage APIs wherever they run.

Using Apigee X means allowing google to run the Apigee gateways and insuyre their reliability. This removes that burden from your responsibility. And Google is really good at it. In my experience, Google is much better at managing Apigee gateways than... pretty much anybody else. X and hybrid are the same software. Same code base, same control plane. You can think of X as "Google-managed hybrid".

The first objection I hear to my suggestion to use Apigee X, and only use Apigee hybrid if you really really need it, is: "what about the latency!?!!? I don't want to incur the extra hop across clouds!"

That is often not valid, and here's why:

if your clients are connecting into your APIs from the public network, let's say from mobile apps or mobile phones or Point-of-sale systems or anything else that is not running in your datacenter, then the client requests need to traverse the public network to get to your APIs. If you use hybrid deployed on AWS, then these clients connect into AWS, then they use an AWS-managed point-of-presence (PoP), and from there into your own regional-based Apigee gateway clusters. On the other hand if you use Apigee X, then the clients connect over the internet into GCP through a google-managed point-of-presence, and from there into the AWS network via a high-throughput private nertwork backbone. Google maintains over 140 PoPs, and the time taken to hop from client to Google to AWS infrastructure is often LESS than the time taken to hop from client to AWS Pop to AWS infrastructure. Or at the very worst case, it's a wash, or there's a single-digit millisecond additional latency. If you tell me that your API services are so fast that adding 6ms of latency is unacceptable, then maybe you might want to consider hybrid to save on latency. In the vast majority of cases, the APIs themselves exhibit 200-300ms of latency or more, even without the external network costs. So, adding 6ms is irrelevant.
what if your clients are connecting into your APIs from your corporate network? Here again, if you're running Apigee hybrid on AWS, those clients need to connect into the AWS infrastructure layer. Usually they go through some sort of "Direct Connect" to get into your AWS VPC. And from there, into your EKS cluster running Apigee hybrid. If you're running Apigee X, then the client goes through the Interconnect to get into the GCP VPC where the Apigee gateways run, and from THERE, cross-cloud interconnect into AWS. This is a BFP link (big-fat-pipe!) and it's fast and reliable. You again may see a handful of additional ms. typically the AWS and GCP datacenters are very closely situated so that speed-of-light issues are not significant. The last time I lokoed at the numbers, I saw a ~2ms round trip times between AWS us-east-1 and GCP us-east1. (The GCP networking team constantly measures this, because multi-cloud is important to so many Google Cloud customers).

Latency is almost never an issue.

On the other hand there are some cases in which data residency regulations require that you control the datacenters in which Apigee gateways run. I see this in EU countries specifically in regulated industries.

In basically every other scenario, hybrid is not necessary. In my experience, people mostly adopt Apigee hybrid for ... what I consider to be not quite valid reasons.

Latency concerns. This is the #1 reason. As explained above, this is generally not an issue. BTW, most people who cite "latency" as the reason to select Apigee hybrid over Apigee X, have literally never measured the difference. They're going with guesses. Not a good reason to use hybrid.
Their current job involves managing infrastructure and they don't like change. They don't like to relinquish the role of "managing gateways", so they default to "managing something that runs in the cloud." This is not a good reason to use hybrid.
Their current job involves managing PEOPLE who manage infrastructure, and the people manager does not want to lose responsibility. Using a managed service might mean that a team of 12 people...simply vanishes. These people can work on other things. but what happens to the manager of those people? That manager is left without a role. And sometimes organizations make decisions to preserve the status quo. This is also (my opinion) not a good reason for choosing Apigee hybrid.
It will cost more. It's true, Google charges more for a transaction running through Apigee X, than it does for a transaction running through Apigee hybrid. This is because the cost of supporting the X transaction is higher than the cost to support a hybrid transaction, because in the former case, Google runs the gateways! So you will end up paying Google more for running transactions through Apigee X, if you compare to what you pay Google for running transactions through a hybrid cluster. BUT, there are other costs to consider: the cost of the AWS cluster you must run. The cost of the people who must administer, monitor, operate, and upgrade the Apigee clusters. And multiply that out by all the various SDLC stages. So yes, you pay google more if you use X, but your net cost is less, typically much MUCH less, than if you managed the gateways yourself.

Ok, that's all I have to say about that.

I hope you found this helpful. 🙃😝

Currently Apigee on prem - wanted to move out of on prem - what are our options?