Should you build or buy API Management? What criteria did you use?

Not applicable

Hey, folks. Ed Anuff and I are going to do a webinar next week around the topic of building v buying API Management. It's a juicy topic, right? I'm curious what kinds of questions and thoughts other people are having about this topic.

2 9 2,167
9 REPLIES 9

I see a lot of companies who slide their way into API Management. Almost accidentally. They start kinda in ESB land - where they've got an architecture that uses a "centralized intermediary", or something similar, to handle all inter-app messaging. And when I say "Centralized" I don't mean a single box. It could be a distributed architecture; the point is, there is a broker or handler that intervenes between all app-to-app exchanges.

Some people buy one of those, and others "build it", like maybe starting with JBoss ESB or an Oracle Gateway, or Datapower.

Then there's an app that mis-behaves, and it sends 100's of requests per second, and the ops people can't figure out who is sending all this traffic? so they institute a new policy in which every app (client) that sends messages into the CI needs to carry an app id, some "api key" like thing.

And there are only a handful of systems, that each send large numbers of transactions, so the ops people manually construct 20 GUIDs or uuids and hand them out to each of the users. Then they set up a webpage that describes this process and says "send email to ci_ops@example.com to get your own guid".

And they stuff all the guids in a properties file, which is read at startup by each of the nodes that implement the CI. And when they add a new guid, they restart the processes, and they only do that once per week maximum.

And in order to provision a new key, there's a manual process involved. So they have a run book that says how to create the guid, how to add it into the properties file, how to "sign" the operation (so they can track who created the guid, and who asked for it (the holder of the guid). And also the runbook describes how to restart the nodes that do the brokering and key validation.

At this point they have built api key verification, a "developer portal" and an "automated" provisioning system (automated = Chris in ops runs 3 scripts, and then prints out the guid and hand-delivers it to the requester, since email is not secure).

And what do you know! they have gradually built their own "API Management".

Then there is a request by someone to generate statistics on usage, especially comparative usage over time. So they add in some logic that logs transactions to Splunk or some other system, using a conversation id that gets generated for each new request, and also being sure to log the uuid of the client app. Now they have a bunch of log files and they can build queries out of Splunk for that. This is also somewhat of a manual process, so they have Raul in IT run the scripts and product Excel charts monthly.

Now they have analytics!

And then they invite partners to start using this CI. It's known, it performs well, they already have it in operation. But because partners will be using it, and traffic may arrive over the internet, now they need some extra security. Not all inbound requests should be honored, so they need some way to describe which apps (uuids) can do which things. Which means they go out and evaluate Authorization tools like Axiomatics and maybe IBM Tivoli Security Policy Manager, or some other XACML based thing. they choose one and then design all the permissions, and extend the runbook to explain how to provision new uuids to also include the steps about writing XACML policies.

And they build in some logic into the ESB that calls the authorization server. and the auth server needs to have its own server node, and it needs to be redundant, and its datastore, too, so that's about 5 new servers (counting the admin or jump server) to handle just the authorization management. And every time there is a new permission added to the auth server they need to track who asked for this permission, and who added it in, and which manager signed off on it.

So they hack together an auditing "solution" which is basically a google spreadsheet containing a list of rows, that they must fill out every time they make a change int he XACML server. And then there are some checks that verify that any new UUIDs in the XAML rules are also always mentioned in the google sheet, because without an audit record in the google sheet, there's no accountability. So they write a script that runs every week via a cron job to verify that things are still in sync.

Now they have an audit trail!

And that's how people do it. And as time goes on, they continue to get requests from different stakeholders in the business: "We need to onboard this new partner for a new marketing initiative". "we need to update our consumer app to allow users to save their preferences and favorites". "We need analytics to give us day-by-day updates". And the backlog of requests grows. But there are lots of stakeholders, and lots of people trained on the runbook, and the thing performs like .. .great! tons of transactions flow through the thing, and mostly they only reboot servers once or twice a week. And even then, the outage is only 12 minutes, max, and they don't lose many transactions. The pagerduty integration is working out pretty well, once they got the cron-jobs set up.

And now there's a team of people that is constantly maintaining this thing - care and feeding of the hand-built, hand-integrated system is demanding, and with more and more systems using it, they need more and more people.

And the plan is to build an automated testing tool, that will send in sentinel transactions periodically, just to gauge the health of the overall system, maybe measure response times. And they're busy working up a design on this system, when...

... some VP asks for JWT support. Urgently. And the CI team doesn't have that, and it's not in their 6-month schedule. And they don't have a way to add it, easily. JWT ... turns out that's kinda messy. Plus they have the big backlog of requests from last quarter, and there's no way they're gonna be able to deliver JWT verification by fall. So... they start looking at vendors.

Really they just want a JWT dispensary vendor. They want a point solution, something that JUST does JWT. This is in keeping with the approach all along, which is to build the core messaging system, and then buy other parts and integrate them in. At this point, that strategy has been proven out, and ... it works. True, there's a team of 12 people keeping the lights on, but .. hey, it's the Central Intermediary! It's important!

So they begin evaluating systems that can generate and verify JWT, and attach them to user identity (they need OpenID Connect, so they're looking at Identity vendors, too). And then someone else comes in and asks for a no-SQL store that they can use to store partner profiles. And the CI team starts a parallel evaluation of noSQL databases.

And at some point an executive comes in and says, "hey team, are you sure we need to be building all this? Isn't there a simpler solution that's integrated?"

And so they begin the "build vs buy" discussion internally.

@Dino I mostly agree with what has been posted so far. It would be great if you could take the discussion of build vs buy could extend to other parts of your platform. I tend to think of the collection of your offerings as an API Platform which includes development, API management, performance, support, data storage, etc.. What factors should be accounted when deciding to build or buy other aspects of your platform?

Can you please share the webinar registration details ?

kkleva
Participant V

@Dino I wish I could say I slid into API Management. More like a tumble with sharp rocks all the way down the trail.

The question presented to me is often "we bought it... but should we really use it for that?"

One of the largest hurdles I find as a product owner in the API management space is advocating that the platform *should* be used for any particular core use case.

Your app wants OAuth? Great... we've got a way to do that. JWT... No problem. NoSql backend... sure. Analytics... all over the place. Bots hitting the API... well, lets tag and block.

However, even though the product we selected to buy (or rent) does all these things, I'm continuously needing to direct folks not to re-invent the wheel by building in a feature that is clearly already supported by a purchased solution.

I hear they call this "not invented here" or "NIH" syndrome: https://en.wikipedia.org/wiki/Not_invented_here

I feel my personal observations in the wild would support NIH is often a barrier to gaining adoption of any purchased software product. API Management is no exception.

Especially, since much of what was going on with SOA/ESB was "invented here".

To combat NIH syndrome in the Enterprise I've found you need to start keeping a an eye on vendors that make an effort to be transparent.

In addition, I've prioritized getting educated about the open source software which is acting as the backbone of the product. It's also important to callout risks when projects claim to be Open Source yet rely on the sale of Enterprise support to fund the future development of their product.

For me this has cured NIH by changing the narrative to:

"I'm sure we could have invent it here, I see all the parts used to make it; I agree with *most* of those technology choices; I just do not want to because we have better things to do with our time."

So my question to @bpagano and Ed Anuff would be how would you approach the spread of NIH syndrome when rolling out API Management across the enterprise?

How should I best pick my battles? When it is important to advocate strongly a particular solution not be invented? What are the key use cases where we should absolutely built it ourselves?

Depends on to whom I am talking. When talking to management, I remind them of the risk involved and how much safer it is to buy something proven (like we discussed in the webinar). When talking with technical folks, I often focus on how an API Management platform is like a power tool. You use to build fantastic things. Like an IDE. You don't waste time writing your own web browser or databases, you build great things that leverage them.

kkleva
Participant V

The juiciest. I expected you not to look for more punishment after the APIs aren't SOA++ talk.

kkleva
Participant V

If I wanted to build my own API management stack how would I would it go about doing it?

I think mature teams are fine with handling parts of the platform. Say, Identity for example. I'd assert most would not want to build an identity management system. However, one could graft an existing solution into their API Management stack to deal with keys/tokens, app devs, etc?