Looking at apiman for lightblue

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Looking at apiman for lightblue

jewzaam
Administrator
http://www.apiman.io/latest/index.html

Took a look at this today.  It seems pretty nice in what it can do but lacks robust security.  It's api-key based and supports only basic auth.  I didn't spend much time with it and maybe I don't know what I'm doing, but I found it hard to cut new versions of a plan (which can be attached to a service contract).  It would also add a layer between the client and lightblue.  We won't be able to use it for throttling in a multi-region and/or multi-datacenter deployment because we won't have any shared state between apiman instances.  We simply can't do clustering in those scenarios and, frankly, clustering is a thing we'd rather not do in general.  Maybe if the database is replicated it would work, but we'd have to do some investigation on how disconnected deployments sharing the same database behave.  I didn't see anything in a brief search of the user guide.
Reply | Threaded
Open this post in threaded view
|

Re: Looking at apiman for lightblue

lcestari
I found it hard too, but it make sense (as it decoupled many different objects/key things about an API that we usually don't think about it, but it still complex (UI should be more intuitive and friendly) ).about multi-region/datacenter, if it have a LB which we use that to APIman manager, dont you think it would work? (like the LB would make the cluster seems to be a single instance)
Reply | Threaded
Open this post in threaded view
|

Re: Looking at apiman for lightblue

jewzaam
Administrator

Where does that load balancer live? It can't be in one dc or we're back to a single point of failure.


On Thu, Jan 15, 2015, 5:13 PM lcestari [via lightblue-dev] <[hidden email]> wrote:
I found it hard too, but it make sense (as it decoupled many different objects/key things about an API that we usually don't think about it, but it still complex (UI should be more intuitive and friendly) ).about multi-region/datacenter, if it have a LB which we use that to APIman manager, dont you think it would work? (like the LB would make the cluster seems to be a single instance)


If you reply to this email, your message will be added to the discussion below:
To start a new topic under lightblue-dev, email [hidden email]
To unsubscribe from lightblue-dev, click here.
NAML
Reply | Threaded
Open this post in threaded view
|

Re: Looking at apiman for lightblue

lcestari
Good point. I will borrow the basic idea which people from Fabric8 (Fuse) will (is) use http://kurtstam.blogspot.com.br/2015/01/api-management-on-fabric8.html , which basicaly there would be a LB infront of the the Apiman and the Apiman would know the different hostst you have in you (muti) region.  I'm not sure how easy Apiman is to manage all those services as once but I would guess that it might be one of its features or its is on roadmap (other features that I would also expect are things like canary release, rolling-update, etc)  
Reply | Threaded
Open this post in threaded view
|

Re: Looking at apiman for lightblue

Eric Wittmann
In reply to this post by jewzaam
Glad you guys had a look at apiman - fascinating to hear your experiences.  It's still relatively early days for the project, so if you have specific suggestions for improvements we'd love to hear them!

We do have an OAuth plugin (specifically supporting KeyCloak bearer tokens) and there are plans for additional security policies.  I'd be interested to hear your requirements.

Regarding state sharing - that's pretty much a requirement if you want to do rate limiting.  That said, we have designed it such that most of the runtime components are pluggable.  Currently for rate limiting (as an example) we can use an infinispan cache or an elasticsearch index to share the state (or in-memory only for small/test deployments).  Swapping in another approach is pretty simple, and I'd love to hear any suggestions you might have.

It can obviously sometimes be challenging to provide useful functionality unless we have all the use cases!  :)
Reply | Threaded
Open this post in threaded view
|

Re: Looking at apiman for lightblue

jewzaam
Administrator
Eric, thanks for the comments!  I expect apiman will evolve over time and we'll circle back around to see how things are progressing periodically.  We don't have a hard requirement for a gateway layer yet, but expect to see the need soon.

As for security, we're relying on client certificates for authentication with our REST applications.  We cut a cert from a trusted certificate authority and use the principal in the cert for checking what that authenticated request is authorized to do.  KeyCloak is something we looked at a while ago and plan on revisiting again soon (http://dev.forum.lightblue.io/Keycloak-td139.html).

I am interested in the rate limiting feature of apiman, but expect to have our application deployed across multiple regions / datacenters within the year.  This complicates sharing state.  The only state we share today for our application is database replication and I guess some degree at the load balancer.  Your thoughts on the best way to share this state across datacenters is appreciated.  A requirement would be that each apiman instance only interacts with a local datastore (read and write) and not have any issues locally if communication with other datacenters fails.