Making My 3Scale API Management Portable With A Containerized Micro-Services

As I work to find balance in this new micro-service, container driven world of APIs, 3Scale is continuing to be an essential layer to the business of my API / micro service orchestration. In alignment with what I’ve been preaching for the last 5 years, I'm needing to re-define my valuable API infrastructure resources to be as agile, flexible, and portable as I prescribe in the public stories that I tell.

Using 3Scale I have the service composition for my platform pretty well defined. The problem is, this definition is not as portable, and flexible as it could be, for the next shift in my API operations, via Docker, allowing me to manage loosely coupled stacks of micro-services. Within this new approach to API operations, I need every single Docker container I orchestrate to ping home, and understand where in my business service composition it exists and operates. This service composition allows me to offer the same service to everyone, or multitide of a services to specific or as diverse of a group of customers as I need. I don't want people to just use my APIs, I want them to use them, exactly where and how they want and need to.

I need this stack of API management infrastructure available for me within any domain, complete, or partial, on any containerized driven architecture I need--aka AWS, Google, Microsoft, Rackspace, etc.

Even if this infrastructure is just a proxy of the 3Scale infrastructure API, I need it portable, living as a proxy anywhere I need it. I also need to be able to transform (maybe APITools?) along the way. I need a moodular set of 3Scale API management infrastructure to design my own API infrastructure no matter wherever it lives in the cloud, or on-premise, even if it is in my closet on a Raspberry Pi, or wifi router for my home.

I can sign up new users to my API infrastructure, and allow them to access and consume any API resources I am serving up. I use this same infrastructure to build my applications, as well as make it accessible it to my consumers. At any point one of my consumers, needs to become a provider—I need their infrastructure to be portable, transferrable, and as flexible as it possibly can.

To accommodate the next wave of API growth I need my news API to be as flexible as possible for my needs, and I need to be able to also deploy it in any of my clients infrastructure, when I need. This enters a whole new realm of wholesale API deployment and management. I can now segment usage of my APIs beyond just my own management service composition, and through my containerized deployment infrastructure, I can add entirely new dimension to my architecture. The only thing I need is for my 3Scale infrastructure to be portable, containerized, and reusable—and since3Scae practices what it preaches, and has an API, I can move forward with my ideas.

All of this is doable for me because 3Scale has an API for their API infrastructure (*mind blown*), I just need to design the right Docker image to proxy the API(s), and extend it in as I need. As I do with all of my micro-services, I’m going to use Swagger to drive the functionality. I can take the Swagger definition for the entire stack of 3Scale API management resources, and include or omit each endpoint as I need—delivering exactly the API management stack I need

More to come on my 3Scale API management micro-service Docker image, as I roll it off the assembly line.