I have hundreds of existing services, how to onboard them on Apigee?

I have been asked this question few times, it appeared fairly straight forward to me on how we could do this, for eg,

Step 1 > Edge has an API to import a proxy definition, so we should be able to create a script that probably creates proxies [probably form a template] for all of your services

Onboarding service is fine - but now since these are existing services there are going to be existing consumers and you also want them to go through Apigee,

Step 2 > My understanding is this should be a simple DNS switch [update the CNAME to apigee endpoint - and ofcourse update the target endpoints in proxy accordingly]

With these 2 steps you should have all your services onboarded on Apigee, existing service consumers sending traffic thro Apigee

and with that,

You will get analytics/visibility into your service consumers and the services consumed.

Obviously you could also add 'transparent' API management functions, like, Traffic Management policies [quota, spike, cache], Threat Protection policies [XML,JSON, Reg ex] or Custom Ax or Logging

[transparent = things that do not break your existing consumers]

and all of this could be done to the proxy template definition you would create in Step 1 itself.

I understand - a service is very loosely defined or maybe not defined at all - i think for this discussion we could treat them as distinct HTTP URLs from one or more hosts

What do you think about this approach, in general?

Did i over simplify this process? what are the other gotchas you think we should consider when someone tries to do this?

Any other thoughts/opinions?

1 2 448
2 REPLIES 2

So I think that's an approach to putting service traffic through Edge, but I'm going to argue you aren't really setting up for an API program that way. I understand the desire to not disrupt existing consumers of existing services, which is perfectly valid.

But I think APIs are different. We have a lot of content that talks about why. Design for consumption, design from the outside-in, etc. But I think the easiest way to think about it is this. If your existing services could get you what you want (innovation, sharing by default, more adoption, whatever it is)... if they could get you what you want, why aren't they doing that today? It's not because you don't have analytics on them. The problem is that those services are not APIs. I just don't think that taking what you have and running it through a new layer is going to result in that much change for you. It's not going to give you what you really need.

Now, if you're asking because you want to do this _AND_ you want to start thinking about APIs, then great. Fantastic! Get analytics on existing services in a lightweight way, and in parallel think about how you can turn those existing services into valuable APIs. I'm happy to support that idea. 😉

yes @Carlos Eberhardt, you are right - i should clarify it in the question, this is just a means to get started and provide 'life support' for existing stuff, while you are starting to build 'APIs'. After you have started, it also serves as a means to identify the consumers still on 'life support' and migrate them