I was being interviewed by an IBM group the other day, and I scribbled some thoughts on a piece of paper as I was rambling, which I just picked up trying to make sense of what was going through my mind, before I archive the chicken scratches.
It look like during the call I was talking about how I see the world of API deployment, based upon how I am currently organizing providers, services, and tooling that I find. I was discussing with them how I am moving towards breaking things down into four buckets:
- Gateway - The more enterprise focused, IT department led API efforts, usually conducted at larger enterprises, and institutions.
- Artisan - A more farm to table, hand crafted approach that employs organic open source REST frameworks in the process.
- Cloud - Leverage the latest breed of cloud API service providers that allow you to deploy APIs from common resources online.
- Serverless - Outdoing the artisan hipster approach, all the cool kids are doing it without servers, piece by piece using Iron.io and Lambda.
My API deployment research has just been a single list of service providers, and open source tooling for the last couple of years. Its time I started breaking things down a little more, and helping my readers find solutions based upon a more realistic approach to how APis are being deployed in the wild, or at least within their organizations.
I almost added database as layer here, but I want to keep these API deployment buckets more about the middle layer in between the backend infrastructure, and the clients that wll be consuming API resources. API deployment touches on API design and definitions, and stops short of API management, with some overlap with containers, and API virtualization.
This post also reveals the fact that I write most of these stories to help me think through the world of APis, get my thoughts in order, and help formalize them a little bit further, as I try to articulate to myself, (and you) via the this blog.
