Defining Virtual API Stacks Using The Service Broker API Over At IBM Bluemix05 Feb 2015
I've been talking about developing virtual API stacks for a while now, and as I continue understand current shifts in cloud computing, I am doing my own reshuffling towards a more microservices, and docker-centric way of life. When I say the phrase “virtual API stack”, I’m talking about the ability to deploy a stack of APIs you need for a specific organization, project, app, or other configuration. In 2015, you should be able to quickly define exactly the stack of private, and public API services you need to accomplish exactly what you need--nothing more.
As part of my research in this area, I’m tracking on similar patterns, that I see occurring at platform providers--today I found an example of defining virtual API stacks using the service broker API over at IBM Bluemix. Using Bluemix, you can build virtual API stacks from existing services they have setup, including Twilio, and Sendgrid, or register your own APIs using service broker, via their cloud marketplace (you have to be partner). The services deploy in this way, need to implement a common API surface area dictated by the platform (I’d love to see a Swagger spec for this IBM).
IBM is blending several areas I’ve been tracking on, starting with defining of virtual stacks, but also the aggregation of 3rd party services which opens up a wholesale layer of valuable API resources, and sets up world where API brokers can emerge, and prosper. I see that IBM has embraced machine readable API definitions like Swagger as part of their operations, and I’d love to see them adopt APIs.json for defining of their virtual API stacks or collections. APIs.json would make the API collections that users define, much more portable, shareable, indexable, and ultimately discoverable. If you need example of APIs.json + Swagger working, look through my API Stack inventory, as I map out the top APIs.
My vision of a future with API stacks and collections, is a world where we can buy and sell these modular resources, in IBM’s, Amazon’s, Google’s, and anyone other marketplace, but we can also run them in any infrastructure we choose. We would all possess our own stacks of resources, be able to choose from a wide array of public and private 3rd party resources, and deploy, remix, and re-use these resources in any way we choose, to drive websites, desktop solutions, system integrations, mobile apps, and devices.
It is good to see these patterns emerging over at IBM, via their Bluemix platform. This type of modular service definition, design, deployment, management and reuse is something I’m talking with several other companies about as well--making for a very “containerized microservice” 2015, from what I can see.