{"APIs & Containers"}

The Ability To Deploy Your API Heroku Is A Gateway Drug To The Wholesale, Containerized API Economy That Is Coming

I was talking through the features, and roadmap for SecureDB with their team the other day, and one of the conversations that came up was around on-premise opporutnities for deploying encrypted user, data, and file APIs. In my opinion, on-premise is something that has morphed from meaning "in our data center", to where wherever we store data and run our compute power--which could be spread across multiple cloud vendors.

SecureDB offers an extremely valuable API commodity in 2015, encrypted user, data, and file stores--something EVERY website and mobile application should have as part of their back-end. When you have something this valuable, and potentnially ubiquitous, it needs to run wherever it is needed. With this in mind SecureDB is available on demand, as a retail API solution, but they will also deploy it for you "on-premise" on AWS or Heroku, with "more platforms in the roadmap".

While a wholesale, on-premise, deploy anywhere API will not be required for all APIs, as some SaaS solutions won't benefit from this type of distribution, if you are a core architectural building block, or utility APIs like SecureDB, to compete in the API economy, your API will have to deployable to anywhere it is needed. With the explosion of Docker and Kubernetes, your API should technically be able to able to be deployed in any containerized environment, with a business model, licensing, and legal framework to support the different use cases.

The ability to deploy your API on Heroku is just a gateway drug to the wholesale, white lable, containerized, API economy that is coming, where the most agile, flexible, and interoperable APIs will dominate. 

See The Full Blog Post

API PLUG, A New Containerized API Design, Deployment, and Documentation Solution

I started playing with the possibilities when it comes to API deployment using virtual containers like Docker early this year, exploring the constraints this approach to API deployment introduced, on my own infrastructure. The process got my gears turning, when it comes to deploying very simple data, content, and algorithmic APIs into any environment that runs Docker. 

As 2015 has progressed, I'm seeing containers emerge as part of more stops along the API life-cycle, specifically in deployment and virtualization. A new one that just came across my radar is API PLUG. I haven't played with the containerized API deployment solution yet, but after watching video, and looking through site it seems in line with what I'd expect to see from a next generation, containerized, API deployment solution.

Overlapping with my previous post on reconciling API orchestration, I'm seeing several stops along API lifecycle present in API PLUG, beyond just API deployment, it allows you to design, deploy, and document your API which moves well into the world of API management. As I'm seeing with other emerging solutions like API Studio from Apigee, I predict we will see testing, monitoring, and other critical layers of the API life-cycle emerge as orchestration layers of API PLUG.

I've added API PLUG to my API deployment research, and I am still considering the best way to include them in other areas of my API research. I'm increasingly finding that modern API management solutions are spanning multiple areas of the API life-cycle, which further encourages me to modularize my research, but also tells me I'm going to need to create some sort of Venn Diagram visualization to help me better understand the reach of emerging API products and services.

Anyways, more to come on API PLUG as I play with, and listen to the stories they tell via their blog, Twitter, and Github accounts (I can only find a Twitter account, but I'm sure they are working on that! ;-).

See The Full Blog Post

Algorithmic Transparency With Containers and APIs

I believe in the ability of APIs to pull back the curtain of the great OZ, that we call IT. The average business and individual technology consumer has long been asked to just believe in the magic behind the tech we use, putting the control into the hands of those who are in the know. This is something that has begun to thaw, with the introduction of the Internet, and the usage of web APIs to drive applications of all shapes and sizes. 

It isn't just that we are poking little holes into the corporate and government firewall, to drive the next generation of applications, it is also that a handful of API pioneers like Amazon, Flickr, Twitter, Twilio, and others saw the potential of making these exposed resources available to any developers. The pulling back of the curtain was done via these two acts, exposing resources using the Internet, but also inviting in 3rd parties to learn about, and tap into these resources.

Something that is present in this evolution of software development, is trust. API providers have to have a certain amount of trust that developers will respect their terms of service, and API consumers have to have a certain amount of trust that they can depend on API providers. To achieve this, there needs to be a healthy dose of transparency present, so API providers can see into what consumers are doing with their resources, and API consumers have to be able to see into the operations, and roadmap for the platform.

When transparency and trust does not exist, this is when the impact of APIs begin to break down and they become simply another tech tool. If a platform is up to no good, has ill intentions, selling vapor ware, or there is corruption behind the scenes, the API concept is just going to create problems, for both provider and consumer. How much is exposed via an API interface is up to the API designer, architect, and ultimatley the governing organization. 

There are many varying motivations behind why companies open up APIs, and the reasons they make them public or not. APIs allow companies to keep control over their data, content, and algorithmic resources, while also opening them up so "innovation" can occur, or simply be accessible by 3rd party resources to bypass the historical friction or bottleneck that is IT and developer groups. Some companies I work with are aware of this balance being struck, while many others are not aware at all, they simple are trying to make innovation happen, or provide access to resources.

As I spend some brain cycles pondering algorithmic transparency, and the recent concept of "surge pricing" used by technology providers like Uber and Gogo, I am looking to understand how APIs can help pull back the curtain that is in front of many algorithms impacting our lives. in the same way APIs have pulled back the curtains on traditional IT operations, and software development. As part of this thought exercise I'm thinking about the role Docker and other virtualized contaniners can play in providing us with more transparency in how algorithms are making decisions around us.

When I deploy one of my APIs using my microservices model, it has two distinct API layers, one for the container, and one for what runs inside of it. Docker comes ready to go with an API for all aspects of it operations--here is an Swagger definition of it. What if all algorithms came with an API by default, just like each Docker container does? We would put algorithms into containers, it would have an interface for every aspect of its operation. The API wouldn't expose the actual inner workings of the algorithm, and its calculations, but provide a complete interface for all its functionality.

How much of this API a company wished to expose, would vary just like with APIs, but companies who cared about the trust balance between them, their developers, and end-users, could offer a certain amount of transparency to build trust. The API wouldn't give away the proprietary algorithm, but would give 3rd party groups a way to test assumptions, and verify the promises made around what an alogorithm delivers, thus pulling back the curtain. With no API, we have to trust Uber, GoGo and other providers about what goes into their surge pricing. With an API, 3rd party regulators, and potentially any individual could run tests, validating what is being presented as algorithmic truth. 

I know many companies, entrepreneurs, and IT folks will dismiss this as bullshit. I'm used to that. Most of them don't follow my beliefs around the balance between the tech, business, and politics of APIs, as well as the balance between platform, developer, end-users, and what I consider to be an invetiable collison with government regulation. For now this is just a thought exercise, but it is something I will be studying, and pondering more, and as I gather more examples of algorthmic, or "surge pricing", I will work to evolve these thoughts, and solidify into something more presentable.

See The Full Blog Post

Where Is The Containerized API Marketplace That Businesses Will Need For Success In The API Economy?

Building on what Orlando (@orliesaurus) brings up in his story on the missing brick in the API Industry, we are missing a common place to discovery and share common API designs--something I've been working hard on with my API Stack. As I read this piece from Microsoft Azure on Container Apps now available in the Azure Marketplace, I'm reminded of how robust the app deployment, and management ecosystem has become with the containerization evolution, but when it comes to API deployment we are still way behind the times.

There are numerous containerized marketplaces of apps available out there today, what I am looking for is the same thing, but for common API patterns. After over 10 years of solid design, deployment, and management of web API patterns, we should have a wealth of API design patterns to choose from. I shouldn't have to launch my own user API, or image API, there should be the WordPress of APIs out there, ready for me to deploy.

These APIs should be available with common API patterns, well defined using Swagger and API Blueprint, available in a variety of server side languages from PHP to Go. I should be able to search, and browse these APIs, and with a single click of a button deploy into my containerized architecture of choice, from Amazon to Google, and Microsoft to the Raspberry Pi in my living room--think Heroku deploy button.

Ok, back to work on defining the common public APIs out there on my API Stack, could someone please get to work on this containerized API marketplace? I have a number of standardized API definitions I can share to get you going, and happy to focus on crafting any new ones you need, derived from common patterns I'm finding across my API Stack work.

There is a reason we have the bespoke API design, and deployment way of life--everyone is lacking the marketplace of ready-to-go, containerized APis, that individuals, businesses, institutions, and government agencies will need for success in the API economy.

See The Full Blog Post

DreamFactory Deploying APIs In Docker Containers Is How The API Economy Will Scale

I have been talking about virtualized API stacks for a while now, slowly evolving my own view of whats next for the world of APIs, based upon what I'm seeing happen across the sector. I am working hard to convert my own master stack of APIs, in 25+ separate container driven APIs, which I can then orchestrate into other collections for my own use, as well as the needs of my partners, and wholesale API clients. 

The post Running DreamFactory as a Docker Containers came across my monitors this weekend, which for me is a sign we are getting closer to a version of the API economy that I think will actually scale. The days where you launch one API platform, with one or many APIs, and you only sell that service via a single platform domain, have peaked. The technology, business, and politics of your API operations will have to be flexible enough to be deployed anywhere, by any partner you wish to give access, in a way that maximizes the same innovation we've seen popularize the API movement.

As John Sheehan (@johnsheehan) of Runscope says: Containers will do for APIs, what API have done for businesses over the last 15 years.

In 2015 all your APIs need to be modular, and containerized using common approaches like Docker, alowing your API infrastructure to be deploy-able anywhere, anytime. Hopefully by now you have your API management and service composition house in order, and the business of your APIs can also scale to meet this new, containerized landscape. If you are worried about discovery in all of this, you better start talking to me about APIs.json, and making sure you use a common API definition formats like Swagger or API Blueprint across all of your APIs.

Just like the early API providers like SalesForce, Amazon, and Twilio were able to out-innovate, and out-maneuver their business competitors using APIs in the last decade, companies who can containerize the approach to their API deployment and management like DreamFactory brings to the table, will realize entirely new levels of agility, and flexibility--in a time when you really, really, really need any competitive advantage you can to stay relevant.

See The Full Blog Post

@Broadcom, I Am Going To Need Your Switches To Support Virtualized Containers So I Can Deploy My Own APIs Too

While processing the news today over at API.Report, I came across a story about Broadcom delivering an API for managing their latest network infrastructure. The intersection of Software Defined Networking (SDN) and Application Programming Interface (API) is something I’m paying closer attention to lately. Hmmm. SDN + API = Brand New Bullshit Acronym? Meh. Onward, I just can’t slow down to care--{"packet keep moving"}.

At the networking level, I’m hearing Broadcom making a classic API infrastructure argument, "With the OpenNSL software platform, Broadcom is publishing APIs that map Broadcom's Software Development Kit (SDK) to an open north bound interface, enabling the integration of new applications and the ability to optimize switch hardware platforms.”, with examples of what you could build including "network monitoring, load balancing, service chaining, workload optimization and traffic engineering."

This new API driven approach to networking is available in the Broadcom Tomahawk and Trident II switches, looking to build up a developer community who can help deliver networking solutions, with Broadcom interested in giving, "users the freedom to control their technology, share their designs and boost application innovation.” Everything Broadcom is up to is in alignment with other valid Internet of Things (IoT) efforts I’m seeing across not just the networking arena, but almost any other physical object being connected to the Internet in 2015.

I think what Broadcom is doing, is very forward leaning effort, and providing native API support at the device level is definitely how you support “innovation” around your networking infrastructure. To keep in sync with the leading edge of the current API evolution as I'm seeing it, I would also recommend adding virtualized container support at the device level. As a developer I am thankful for the APIs that you are exposing, allowing me to develop custom solutions using your hardware, but I need you to take it one level further--I need to be able to deploy my own APIs using Docker, as well as working with your APIs, all running on your infrastructure.

I need your devices to support not just the web and mobile apps I will build around your around your hardware, and the API surface area you are providing with the new Tomahawk and Trident II switches, I need to also plugin my own microservice stack, and the microservices that vendors will be delivering to me. I need the next generation of switches to be API driven, but I also need to guarantee it is exactly the stack I need to achieve my networking objectives.

That concludes my intrusion into your road-map. I appreciate you even entertaining my ideas. I cannot share much more details on what I intend to do with your new SDN & API driven goodness, but if you work with me to let me innovate on your virtual and physical API stack—I feel that you will be surprised with what what the overall community around your hardware will deliver.

See The Full Blog Post

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.

See The Full Blog Post

Are Your APIs Ready For The Coming Containerization Evolution Of The API Space?

If you were at Defrag in Colorado last November, or in Sydney, Australia for API Days last week, you’ve heard me talk about what containers are doing to APIs. There is a subtle, but important shift in how APIs are being deployed occurring right now, and as John Sheehan (@johnsheehan), the CEO of Runscope says, containers are doing for APIs, what APIs have been doing for businesses.

As I was processing news for API.Report this morning, I found more evidence of this, with the release of logging API container from Logentries. APIs have made resources like “logging”, much more modular and portable, for use in multiple channels like mobile or via websites. A containerized logging API makes the concept of a logging API much more portable, by adding an entirely new dimension for deployment. You don’t just have a logging API, you now have a logging API that can be deployed anywhere in the cloud, on-premise, or on any physical object.

This opens up a whole new world of APIs, one that goes beyond just a programmable web, quickly evolving us towards a programmable world, for the better, and the worse. Last month I asked, when will my router have docker containers by default? I received an email from a major network equipment manufacturer this week, letting me know that they are working on it. This means little containers on the Internet enabled objects across our worlds, ushering in the ability to deploy localized, wholesale APIs, giving us the ability to manifest exactly the virtual API stacks that we need, for any objective.

I try not to hype up where things are going in the API space, so I will stick with calling containers a significant evolution in how APIs are done. This new way of deploying APIs will push the evolution around the business of APIs, changing how we make generate revenue from valuable resources, while also putting even more stress on the politics of APIs, with introduction of more privacy and security concerns—not to mention adding a whole new dimension of complexity.

I’m not 100% sure where all of this is going. As with the rest of the API space, I struggle with making sense of all of this in real-time, and the allocation the mental bandwidth to see the big picture. All I can say at this moment, is to make sure you work to better understand various approaches to containerization, and adopt a microservice approach to your API design. Beyond this, all we can do is keep an eye on what companies like Logentries are doing, when it comes to containerized API deployment, and try to learn as fast as we possibly can.

See The Full Blog Post

API Management Infrastructure And Service Composition Is Key To Orchestration With Microservices In A Containerized World

As I work to redefine my world using microservices, I have this sudden realization how important my API management infrastructure is to all of this. Each one of my microservices are little APIs that do one thing, and do it well, relying on my API management infrastructure to know who should be accessing, and exactly how much of the resource they should have access to.

My note API shouldn’t have to know anything about my users, it is just trained to ask my API management infrastructure, if each user has proper credentials to accessing the resource, and what the service composition will allow them to do with it (aka read, write, how much, etc.) My note API does what it does best, store notes, and relies on my API management layer to do what it does best--manage access to the microservice.

This approach to API management has llowed me to deploy any number of microservices, using my API management infrastructure to compose my various service packages—this is called service composition. I employ 3Scale infrastructure for all my API / microservice management, which I use to define different service tiers like retail, wholesale, internal, and other service specific groupings. When users sign up for API access, I add them to one of the service tiers, and my API service composition layer handles the rest.

Modern API management service composition is the magic hand-waiving in my microservice orchestration, and without it, it would be much more work for me to compose using microservices in this containerized API world that is unfolding.

Disclosure: 3Scale is an API Evangelist partner.

See The Full Blog Post

Using Swagger As Fingerprint For My Microservice Docker Containers

I'm rebuilding my underlying architecture using microservices, and docker containers, and I'm using APIs.json for navigation and discovery within these new API stacks that I use to make my world go around. As I assign each microservice, and APIs.json file, taking inventory of the building blocks that make the service operate, I also begin including docker into the equation, and I find myself using Swagger definitions as a sort of fingerprint for my docker powered microservices.

Each microservice lives as its own Github repository, within a specific organization. I give each one its own APIs.json, indexing all the elements APIs of that specific microservice. This can include anything I feel is important, like:

  • X-Signup - Where to signup for the service.
  • X-Twitter - The twitter account associated with the service.
  • X-Samples - Where you can find client side code samples.

As long as you put X- before the property, you can put anything you want. There are only a handful of sanctioned APIs.json property types, and one of them you will find in almost all my APIs.json files generated for my platform is:

  • Swagger - A reference to a machine readable Swagger definition for each API.

Another one I’m starting to use, as I’m building out my microservice infrastructure, is:

  • X-Docker-Image - A link to a docker image that supports this API.

Each of my microservices I have a supporting Docker image that is the backend for each API. Sometimes I will have multiple Docker images for variant back-ends for the same API fingerprint. Using APIs.json I can go beyond just finding the API definition, and other supporting building blocks. I can also find the backend needed to actually deliver on the API I have defined by a specific Swagger definition. I’m just in the early stages of this work, and this series of posts reflects me trying to work much of this out.

You can browse my work on Github, most of it is public. The public elements all live in the gh-pages branch, while the private aspects live within the private master branch. It is all a living workbench for me, so expect broken things. If you have questions, or would like more access to better understand, let me know. I’m happy to consider adding you to the Github organization as collaborator so that you can see more of it in action. I will also chronicle my work here on the blog, as I have time, and have semi-interesting things to share.

See The Full Blog Post

Using APIs.json For My Microservice Navigation And Discovery

I’m rebuilding my underlying architecture using microservices and docker containers, and the glue I’m using to bind it all together is APIs.json. I’m not just using APIs.son to deliver on discoverability for all of my services, I am also using it to navigate around my stack. Right now I only have about 10 microservices running, but I have a plan to add almost 50 in total by the time I’m done with this latest sprint.

Each microservice lives as its own Github repository, within a specific organization. I give each one its own APIs.json, indexing all the elements APIs of that specific microservice. APIs.json has two main collections, "apis" and "include". For each microservice APIs.json, I list all the properties for that API, but I use the include element to document the urls of other microservice APIs.json in the collection.

All the Github repositories for this microservice stack lives within a single Github organization, which I give a "master" repo, which acts as a single landing page for the entire stack. It has its own APIs.json file, but rather than having any API collections, it just uses includes, referencing the APIs.json for each microservice in the stack.

APIs.json acts as an index for each microservice, but through the include collection it also provides links to other related microservices within its own stack, which I use to navigate, in a circular way between all supporting services. All of that sounds very dizzying to write out, and I’m sure you are like WTF? You can browse my work on Github, some of it is public, but much of it you have to have oAuth access to see. The public elements all live in the gh-pages branch, while the private aspects live within the private master branch.

This is all a living workbench for me, so expect broken things. If you have questions, or would like more access to better understand, let me know. I’m happy to consider adding you to the Github organization as collaborator so that you can see more of it in action. I will also chronicle my work here on the blog, as I have time, and have anything interesting things to share.

See The Full Blog Post

When Will My Router Have Docker Containers By Default?

This is something I’m working on building manually, but when will the wireless router for my home or business have Docker container support by default? I want to be able to deploy applications, and APIs either publicly or privately right on my own doorway to the Internet.

This would take more work than just adding storage, compute, and Docker support at the router level. To enable this there would have to be changes at the network level, and is something I’m not sure telco and cable providers are willing to support. I’ll be researching this as a concept over the next couple months, so if you know of any read-to-go solutions, let me know.

It seems like enabling a local layer for docker deployment would make sense, and help move us towards a more programmable web, where notifications, messaging, storage, and other common elements of our digital lives can live locally. It seems like it would be a valuable aggregation point as the Internet of Thing heats up.

I could envision webhooks management, and other Internet of Things for household automation living in this local, containerized, layer of our online worlds. This is just a thought. I’ve done no research to flush this idea out, which is why its here on kinlane.com. If you know of anything feel free to send information my way.

See The Full Blog Post

Using Containers To Bridge What Swagger Cannot Define On The Server-Side For My APIs

When I discuss what is possible when it comes to generating both server and client side code using machine readable API definitions like Swagger, I almost always get push-back, making sure I understand there are limitations of what can be auto-generated.

Machine readable API definitions like Swagger provide a great set of rules for describing the surface area of an API, but is often missing many other elements necessary to define what server side code should actually be doing. The closest I’ve gotten to fully generating server side APIs, is when it came to very CRUD-based APIs, that possess a very simple data models--beyond that it is difficult to make "ends meet".

Personally, I do not think my Swagger specs should contain everything needed to define server implementations, this would make for a very bloated, and unusable Swagger specification. For me, Swagger is my central truth, that I use in generating server side skeletons, client side samples and libraries, and to define testing, monitoring, and interactive documentation for developers.

Working to push this approach forward, I’m also now using Swagger as a central truth for my Docker containers, allowing me to use virtualization as a bridge between what my Swagger definitions cannot define for each micro-service or API deployed within a specific container. This approach is leaving Swagger as purely a definition of the micro-service surface area, and leaving my Docker image to deliver on the back-end vision of this surface area.

These Docker images are using Swagger as a definition for its container surface area, but also as a fingerprint for the value it delivers. As an example, I have a notes API definition in Swagger, for which I have two separate Docker images that support this interface. Each Docker image knows it only serves this particular Swagger specification, using it as a kind of fingerprint or truth for its own existence, but ultimately each Docker image will be delivering its own back-end experience derived from this notes API spec.

I’m just getting going with this new approach to using Swagger as a central truth for each Docker container, but as I’m rolling out each of my API templates with this approach, I will blog more about it here. Eventually I am hoping to standardize my thoughts on using machine readable API definition formats like Swagger to guide the API functionality I'm delivering in virtualized containers.

See The Full Blog Post

Use APIs.json To Organize My Swagger Defined APIs Running In Docker Containers

I continuing to evolve my use of Swagger as a kind of central truth in my API design, deployment, and management lifecycle. This time I’m using it as a fingerprint for defining how APIs or micro-services that run in Docker containers function. Along the way I’m also using APIs.json as a framework for organizing these Swagger driven containers, into coherent API stacks or collections, that work together to accomplish a specific objective.

For the project I’m currently working on, I’m deploying multiple Swagger defined APIs, each as separate Docker containers, providing some essential components I need to operate API Evangelist, like blog, links, images, and notes. Each of these components have its own Swagger definition, and corresponding Docker image, and specific instance of that Docker image deployed within a container.

I’m using APIs.json to daisy chain all of these APIs or micro-services together. I have about 15 APIs deployed, each are standalone services, with their own APIs.json, and supporting Swagger definition, but the overall project has a centralized APIs.json, which using the includes properties, provides linkage to each individual micro-services APIs.json--loosely coupling all of these container driven micro-services under single umbrella.

At this point, I’m just using APIs.json as a harness to define, and bring together the technical aspects of my new API stack. As I pull together other business elements like on-boarding, documentation, and code samples, I will add these as properties to my parent APIs.json. My goal is to demonstrate the value APIs.json brings to the table when it comes to API and micro-service discovery, specifically when you deploy distributed API stacks or collections using Docker container deployed micro-services.

See The Full Blog Post

Project Idea: Codenvy-Like Containerized Spreadsheets

I wrote a story about a company I’m advising for last week called Codenvy, who is delivering modular, scalable, cloud development environments using their web IDE and Docker. I'm currently working my way through the spreadsheet to API, and API to spreadsheet solutions I track on, and it is making me think that someone should deliver a Codenvy-like containerized spreadsheet environment.

With this type of environment you could forever end the emailing of spreadsheets, allowing people to craft spreadsheets, complete with all the data and visualization goodness they desire, and clone, fork, share, and collaborate around these containerized spreadsheets. You could have a library of master planned spreadsheets that your company depends on, and manage user permissions, analytics, and even scalability, performance, and distribution of vital spreadsheets.

Using this platform you could easily spawn spreadsheet driven APis using services like API Spark, and you could come full circle and have spreadsheets that obtain their data directly from valuable API driven resources, to really blow your mind. Personally I'm not a big spreadsheet lover, but I do recognize that it is where a majority of the worlds data resides, and the user interface of choice for many business folk--making it a good candidate for the next generation of containerized API data sources, and clients.

Just another one of my random ideas that accumulate in my Evernote, that I'll never have time to build myself, and hoping you will tackle for me. As I review all of the existing spreadsheet APi solutions available currently, I’m sure I'll have more API centric, spreadsheet ideas bubble over t o share with you.

See The Full Blog Post

Now Our Development Environment Is Now Containerized And Scalable Like Our Production Environment

The production environment for delivering web and mobile applications has radically evolved in the last couple years, becoming more distributed, scalable, virtualized, and containerized. APIs, and new development frameworks are providing a smorgasbord of resources for developers to put to work, and devops is putting more power and control, throughout the development life cycle, directly into a developers hands. It is time that a developers environment evolves to keep pace with the environment developers are building applications for.

I’ve been talking about containerization in the API space for a while now, something that is still a very manual process, so I have been looking out for a potential development environment that matches my vision for orchestration with APIs for some time now. This is why I was stoked when I ran into Tyler Jewell (@TylerJewell) back in September, who introduced me to Codenvy—"a new SaaS developer environment that allows developers to create hosted environments optimized for creating, editing, compiling, testing and debugging applications authored in different programming languages”.

At first glance Codenvy appears to be just another web-based IDE, with autocomplete, data source management, and Github integration. As you play with more you begin to realize you can configure and share projects, allowing you to setup environments, share and even clone them. Then you realize the whole IDE is configurable, clone-able, shareable, and scalable using the ever popular Docker, complete with API or CLI access to all work spaces, projects and files. This is the environment I was looking for—this is the orchestration I envision for building applications using APIs.

My head is swimming with ideas of how I can orchestrate application development environments now that both the development and production environments are containerized, scalable, bite-size goodness, complete with a Github layer in the middle. While many users of Codenvy will be using to manage their own devop workflow, I will be pursuing it to manage my own infrastructure, but more importantly using it as a platform to craft custom API stacks, share and publish publicly, and explore more opportunities around being an API broker.

Disclosure: I am an adviser to Codenvy.

See The Full Blog Post

Relationship Between APIs And Containers

Containers are a fast growing trend when it comes to delivering compute resources online. Reflecting the world of API design, I feel containers are about deploying exactly the cloud resources you will need to complete a specific compute objective, then putting everything into a single virtualized container definition, that can be forked, clone, scaled, and evolved indpendently of any other resources. Each individual container posesses everything it will need from the operating system, file system, database, necessary libraries, and APIs to accomplish its given objective.

Virtual containers will make API driven resources even more agile, nimble and scalable--not just for providers, but also for consumers. Everything we have right now I would consider to be a retail API market—where even though APIs are often sold B2B, they are generally a one-size fits all API solution. Think about when API resources become modular, customizable, scalable, wholesale resources that can be bought and sold, and deployed anywhere, making all digital assets into commodities that are ready for use anywhere in the API economy.

My goal is to understand how APIs and containers work together, and as I do with all of my research I setup a Github repo for tracking every piece of container news I read that I feel is relevant, each company doing interesting things containers, tools for working with containers, and ultimately my analysis. Cloud computing will continue to be the lead driver of innovation in the API space, and I feel the introduction of cloud computing in 2006–2008 gave legitimacy to web APIs—you could now deploy global infrastructure using web APIs, game on. I think containerization will take API design, deployment, management and integration to the next phase, and closer the early visions of a programmable web we all started envisioning around 2005.

I will be taking each of my API designs, and developing an Amazon Machine Image, Heroku App version, as well as a docker container definition. I want every one of my open source API designs to have the option to be deployed in any cloud environment, and preferable with the click of a button, as with Heroku. In the future it won’t about knowing about all the APIs, it will be about having the right stack of APIs, that you can deploy anywhere, anytime.

I will be talking on this subject at @APIStrat in Chicago this September, and also at Defrag in Colorado this November, let me know if you want to connect around the subject.

See The Full Blog Post

Push Button API Deployment With The Heroku Button

The new Heroku Button gets us one step closer to a new age of API deployment, where anyone can deploy the APIs they need without any developer or IT resources. As I’m working on packaging up API designs for my screen capture API, and image manipulation API, this type of approach is what I’m envisioning for all of my APIs in the future—push button API deployment.

You shouldn't have to wait to deploy the API you need. Just as we are beginning to deploy pre-packaged application stacks like Wordpress, and Drupal, we should be able to deploy common API deployments for images, blogs, videos, and much, much more, with a single click of a button. Once any new API is launched it can be configured, and connected to other systems using the API, allowing it to operate as part of larger stack, or stay as completely independent node  that just checks in with the mother ship from time to time.

While there will remain a handful of API leaders like Twilio and SendGrid who will have a big presence, many of the APIs in this next wave of API deployment will be smaller, and more transient in nature, taking advantage of current cloud trends around PaaS, and containerization. This new type of APis will possess a self contained blueprint for the OS, database, server-side code, API definition, and even configuration, integration, and automation tooling for the API.

I’m working on Docker definitions for creen capture andimage manipulation AP, as well as other APIs I develop in the future, but first I think any API I deisn shouldl run as a Heroku app, that anyone can deploy in their own account with a single click of a button. It won't take much work to make this happen for any API I deploy, and since 3Scale API infrastructure, which I use to secure my APIs, already runs on Heroku--making securing, and managing my Heroku deployed APis seamless.

Disclosure: 3Scale is an API Evangelist partner.

See The Full Blog Post

Everyone Is About To Get An API With The New Wordpress API

While at API Craft in Detroit this week I had the pleasure of hanging with two leads on the WordPress(org) development team, and discuss the API strategy for the blogging platform. Andrew Nacin (@nacin), Lead Developer, and Ryan McCue (@rmccue), WordPress Plugin Developer, facilitated an open circle discussion to work through the challenges that WordPress is facing when developing an API for the open source blogging platform.

At face value, I know a number of API developers who will be less than pleased when they hear about a WordPress API, as both PHP, and WordPress are easy targets for developer’s hatred, for generating less than perfect code. ;-) But, in the end you can’t ignore some of the stats on WordPress usage:

These stats don’t even touch on the number of WordPress plugins and mobile solutions there are developed on the insanely popular website, and blogging platform. I couldn't think of a better platform to start rolling APIs out APIs to the masses, and quickly educating a very large group of tech savvy folks along the way.

Many of these WordPress sites are already integrated with popular API platforms like Twitter, Facebook, Google, and Amazon, so it makes sense to educate WordPress administrators on the APIs they are already using, as well as introduce them to the concept of having their own API around the potentially valuable content they generate.

We Are Talking About Developing 60 M+ Distributed APIs
There is no API deployment or management service provider that is even close to numbers of this magnitude. When ready, the WordPress API will give millions of websites, and the individuals, companies, organizations and government agencies behind them, an Application Programming Interface (API). (weird, I haven't spelled that out in a while) What does this mean for the API sector? I do not know yet, but to me it definitely resembles the long tail of API deployment, that I, and 3Scale have been advocating for the last four years. 

Building For The Lowest Common Denominator
One dominant theme in the conversation around the WordPress API at API Craft, was about building an API for the lowest common denominator. WordPress is an open source blogging platform built using PHP and MySQL, something that enables it to be installed on just about any hosting platform, which has contributed to the platform's growth. However, many of these platforms restrict common aspects of the Internet like the ability to use all of your HTTP verbs, like PUT or DELETE, or simply do not offer essentials like SSL, which is needed for oAuth. The bar for developing an API that will be used by 60 M+ providers has to be set pretty low, ensuring it will work across the entire ecosystem—something WordPress is already pretty damn good at.

Ensuring That The WordPress API Is Extensible
One of the hallmarks of WordPress is the ability to create custom themes and plugins, that extend the functionality of the blogging platform, and the API will be no different. WordPress is much more than just a collection of pages, posts, tags, and links. WordPress has been used as the core of just about any time of website, serving up books, photos, videos, maps, and any other content type you can dream up. The WordPress API has to be able to provide a common interface that can be used to create, read, update, and delete core WP content types, like pages and posts, as well as be extended to any other interpretation the WordPress community can dream up—adding another dimension to the already massive scope of delivering an API to 60M+ websites.

Single Place To Educate Everyone About APIs
I can't think of another platform that has introduced the average person to web programming, more than WordPress (maybe Drupal?). When you go back to the concept of lowest common denominator, WordPress employs PHP and MysQL to drive its functionality, and combined with the plugin and theme extensibility, the platform has provided a rich gateway to the world of web, and mobile app development. The opportunities to introduce, and educate the masses of the benefits (and downside) of APIs, is huge! While the already established API developer community may not want the WordPress community developing APIs, it will be the quickest way we from 10K APIs, into the millions of APIs. WordPress drives 22.0% of the top 10 million websites, which will instantly provide access to some potentially high value content and data, that will significantly increase the size of the overall API economy, as well as contribute to API literacy in every business sector, around the globe.

At the time of this post, the WordPress API is only a plugin, which means it is an optional part of the platform, requiring a WordPress site administrator to know about the plugin, and install as part of their individual WordPress installation. However, the goal is to bake the API into WordPress as part of the 4.1 release, which could happen as soon as this fall, or at the latest the first or second quarter of 2015. While not all 60 M+ WordPress sites will immediately update to the 4.1 release, a significant portion of websites around the world will instantly have an API--good or bad.

I’m pretty excited at the idea of so many websites having APIs, then at the same time I'm completely terrified. It is kind of like flooding the market, with some very high value APIs, while also adding millions of very shitty APIs, and I'm sure a lot in the middle. With a lot of the problems we are facing around discovery and integration at 10K, imagine what things will look like with millions of APIs all of a sudden. Do we want every website to have an API this fast?

Beyond just giving a website an API, I'm also very interested in the potential of using WordPress API as purely an API core, allowing it to be used to drive content and data for mobile, and single page applications (SPA). Considering the innovation we've seen around the core WordPress platform, from the community, I imagine we'll see similar when it comes to just raw API deployment, and when you start considering the potential when bundled with the latest containerization movement, led by Docker.io, and being driven by Amazon, Google, Microsoft, and Red Hat—your head will start to spin.

WordPress API + Virtual Containers = API Deployment As Part Of The Fabric Of The Cloud

I will be carving out more time to consider the implications of the introduction of the WordPress API, and hopefully provide more feedback to the WordPress API development team. If you are a seasoned WordPress developer, and experienced API consumer, you might consider getting involved too. You can get access to the source code for WP API over at Github, and you can submit issues via the issue management for the project—they also provide updates via the WP blog tagged as json-api.

See The Full Blog Post

The New StrongLoop API Server Provides A Look At Future Of API Deployment

I’m looking through the most recent API server release from StrongLoop, and I can’t help but see echoes of what I’ve been researching, and covering across the API Evangelist networkAPI management has been front and center for years, but API deployment is something that is just now being productized, with a wealth of new service providers emerging to provide API deployment solutions that go beyond DIY frameworks, and enterprise API gateways.

Let start with walking through their announcement of their StrongLoop API Server:

  • LoopBack 2.0 - An open source framework for quickly creating APIs with Node, including the client SDKs.
  • mobile Backend-as-a-Service - An mBaaS to provide mobile services like push, offline-sync, geopoint and social login either on-premise or in the cloud.
  • Connectors - Connectivity for Node apps leveraging over ten supported data sources including Oracle, SQL Server, MongoDB and SOAP.
  • Controller - Automated DevOps for Node apps including profiling, clustering, process management and log management capabilities.
  • Monitoring - A hosted or on-premise graphical console for monitoring resource utilization, response times and function tracing with the ability to send metrics to existing monitoring tools.

Just as StrongLoop did in their release post, let’s dive deeper into LoopBack 2.0, the open source core of StrongLoop, which they say "acts as a glue between apps or devices and data via APIs written in Node”:

  • Studio - A graphical interface to complement the command-line tooling and assist developers in building Loopback models.
  • Yeoman and Grunt - The ability to script tasks, scaffold, and template applications and externalize their configurations for multiple environments.
  • ExpressJS 4.0 - The latest update, for the well known Node.js package, bringing improvements by removing bundled middleware and refactoring them into maintainable modules, revamped router to remove confusion on HTTP verb usage and decoupling Connect, the HTTP framework of Node from the Express web framework. It is also the E in the MEAN stack (MongoDB, ExpressJS, AngularJS, Node.js).
  • Project Structure - An expanded directory structure has been expanded to make it easier to organize apps and add functionality via pre-built LoopBack components and Node modules.
  • Workspace API - Internal API making it easier to define, configure, and bootstrap your application at design time and runtime by simply defining metadata in the form of JSON.

This is one of the few sophisticated, next generation, API deployment frameworks I have seen. We have had gateways for a while, and we have a new breed of database and spreadsheet to API providers like APISpark. We also have a new wave of scraping to API solutions from Kimono Labs and Import.io, but I’d say Orchestrate.io gets us closest to the vision I have for StrongLoop, when it comes to API deployment.

I’ve referenced this ability in my stories on virtual API stacks:

This new approach to API deployment allows us to rapidly define, deploy, and orchestrate stacks of API resources for use in our web, single page, and mobile applications. I really feel like BaaS, as an entire company, was just a short growth phase, that leading us to this point, where anyone can quickly deploy their own BaaS, for any broad, or niche purpose. I also see my research into the world of APIs and Single Page Apps (SPAs) reflected here, in StrongLoops API platform vision.

I feel that StrongLoop has an important take on API deployment, one that reflects where leading API, web, single page, and mobile app developers have been for a while now. The difference is that StrongLoop is providing as a standardized platform, allowing developers to much more elegantly orchestrate their entire lifecycle. You have everything you need to connect to existing resources, generate new API resources, and organize work into reusable parts, to deliver the web, single page, mobile apps you need.

I am closely watching this new generation of API deployment providers, companies like StrongLoop, Orchestrate, Flynn, and Cosmic. I see these players being the next generation API gateway, that goes way beyond just providing an enterprise gateway to internal assets. This newer vision is much more directly aligned with the needs of developers, enabling them to rapidly design, deploy and manage the API services they need to drive the web, single page, and mobile apps that are the vehicles in the API economy.

See The Full Blog Post

Reclaim Your Domain LA Hackathon Wrap-up

I spent the weekend hacking away with a small group of very smart folks, at the Reclaim Your Domain Hackathon in Los Angeles. Fifteen of us gathered at Pepperdine University in west LA, looking to move forward the discussion around what we call “Reclaim Your Domain”. This conversation began last year, at the #ReclaimOpen Hackathon, continued earlier this year at Emory University, and we were looking to keep the momentum building this weekend at Pepperdine.

Here is a breakdown of who was present this weekend:

  • Jim Groom - University of Mary Washington (@jimgroom)
  • Michael Caulfield - WSU Vancouver - http://hapgood.us/ - (@holden)
  • Michael Berman - California State University Channel Islands (@amichaelberman)
  • Chris Mattia - California State University Channel Islands (@cmmattia)
  • Brian Lamb - Thompson Rivers University (@brlamb)
  • Timothy Owens - University of Mary Washington (@timmmmyboy)
  • Mikhail Gershovich - Vocat (@mgershovich)
  • Amy Collier - Stanford (@amcollier)
  • Rolin Moe - Pepperdine (@RMoeJo)
  • Adam Croom - University of Oklahoma (@acroom)
  • Mark C. Morvant - University of Oklahoma (@MarkMorvant)
  • Ben Werdmuller — Withknown (@benwerd)
  • Erin Richey — Withknown (@erinjo)
  • Kin Lane — API Evangelist (@kinlane)
  • Audrey Watters — Hack Education (@audreywatters)

If you are unsure of what #Reclaim is all about, join the club, we are trying to define it as well. You can head over to Reclaim Your Domain, or you can also look at Reclaim Hosting, and the original Domain Of Ones Own at University of Mary Washington which has provided much of the initial spark behind the #Reclaim movement, for more information. Ultimately, #Reclaim will always be a very personal experience for each individual, but Reclaim Your Domain is primarily about: 

Educating, and empowering individual to define, reclaim, and manage their digital self

The primary thing I got out of this weekend, beyond the opportunity to hang out with such a savvy group of educators, was the opportunity to talk through my own personal #Reclaim process, as well as my vision of how we can use Terms of Service Didn’t Read as a framework for the #Reclaim process. The weekend re-enforced the importance of APIs in higher education, in not just my own API Evangelism work, but contributing to the overall health of the Internet (which I will talk about in a separate post).

To recap what I said above, there are three domains, that you will need to learn about my current #Reclaim work:

  • Reclaim Your Domain - The project site for all of this work, where you will find links to all information, calendar of events, and link to individual reclaim sites.
  • Kin Lane Reclaim Your Domain - My personal #Reclaim website where I am working on reclaiming my domain, while I also work to define the overall process.
  • Terms of Service Didn’t Read - A website for establishing plain english, yet machine readable discussions around the terms of service for the platforms we depend on.

During the weekend I was introduced to some other very import tools, which are essential to the #Reclaim process:

  • Known - A publishing platform that empowers you to manage your online self, available as an open source tool, or available as cloud service. I’m still setting up my own instance of Known, and will have more information after I get setup, and play with more.
  • IndieAuth - IndieAuth is a way to use your own domain name to sign in to websites, which is a missing piece on the identity front for #Reclaim. Same as Known, I’ll have more information on this after I play with.

I also got some quality time, getting more up to speed on two other of tools that will be be important to #Reclaim:

  • Smallest Federated Wiki - A simple, and powerful wiki implementation that uses the latest technology to collaborate around content, with a very interesting approach to using JSON, and plugins to significantly evolve the wiki experience.
  • Reclaim Hosting - Reclaim Hosting provides educators and institutions with an easy way to offer their students domains and web hosting that they own and control.

Over the course of two days I was able to share what I was working on, and learn about @withknown, and what @holden is up to with Smallest Federated Wiki, and get a closer look at what @timmmmyboy, @jimgroom, @mburtis are up to with Reclaim Hosting, while also explore some other areas I think are vital to #Reclaim moving forward. #WIN There were also some other really important takeways for me.

POSSE is an acronym for Publish (on your) Own Site, Syndicate Elsewhere. For the first time I saw an application that delivers on this concept, while also holding potential for the whole reclaim your domain philosophy--Known. I am excited to fire up my own instance of Known and see how I can actually use to manage my digital self, and add this slick piece of software to the #Reclaim stack of tools that everyone else can put to use.

The Importance of API 101
During the second day of the hackathon, I was asked to give an API 101 talk. I headed to the other end of the meeting area, allowing anyone who wasn’t interested in listening to me, to continue hacking on their own. I was surprised to see that everyone joined me to learn about APIs--well everyone except @audreywatters (API blah blah blah). I felt like everyone had a general sense of what an API was, but only a handful of folks possessed intimate knowledge. I used the separation of websites being for humans, and APIs being for other applications and systems as the basis for my talk—showing how websites return HTML for displaying to humans, and APIs return JSON meant to be used by applications. Later in the day I also wrote a little PHP script which made a call to an API (well JSON file), then displayed bulleted list of results, to help show how APIs can drive website content. Once again I am reminded of the importance of API 101 demos, and how I need to focus more in this area.

The Importance of Github 101
One of the topics we covered was the basics of using Github. I walked through the basic concepts that surround Github usage like repositories, forks, commits, pull requests—demonstrating how multiple users can collaborate, and work together on not just code, but content. I demonstrated how issues, and milestones can also be used to manage conversation around the project, in addition to work with repository files. Lastly, I walked through Github Pages, and how using a separate branch, you can publish HTML, CSS, JavaScript and JSON for projects, turning Github into not just a code and content management platform, but also a publishing endpoint.

APIs.json Playing a Role in #Reclaim
After hearing @timmmmyboy talk about how Reclaim Hosting aggregates domain users within each university, I brought up APIs.json and how I’m using this as a index for APIs in both the public and private sector. While it may not be something that is in the immediate roadmap for #Reclaim, I think APIs.json will play a significant role in #Reclaim process down the road, and is worth noting here.

Containerization Movement
One pattern I saw across the Reclaim Hosting and Domain of One’s Own work from @timmmmyboy@jimgroom, and @mburtis, is that they are mimicking what is currently happening in the @docker dominated containerization movement we are seeing from tech leaders like Amazon, Google, Microsoft, and Red Hat. Then only difference is Reclaim Hosting is doing it as apps that can be deployed across a known set of domains, spanning physical servers, within a particular institution. Containers offer portability for the #Reclaim lifecycle, for when students leave institutions, as well as for the wider public space, when people are looking to #Reclaim their digital self.

Importance of APIs in Higher Ed
APIs are central to everything about #Reclaim. It is how users will take control over their digital self, driving solutions like Known. With #Reclaim being born, and propagated via universities, the API stakes are raised across higher education. Universities need to adopt an API way of life, to drive all aspects of campus operations, but also to expose all students to the concept of APIs, making part of the university experience--teaching students to #Reclaim their own course schedule, student data, and other portfolio, and other aspects of the campus experience. Universities are ground zero, when it comes to exposing the next generation of corporate employees, government workers, and #Reclaim informed citizens--we have a lot of work to do to get insitutions up to speed.

Evolving the Hackathon Format
The Reclaim Your Domain LA Hackathon has moved forward the hackathon definition for me. There were no applications built over the weekend, and there were no prizes given away to winners, but there was significant movement that will live beyond just this single event—something that the previous definition of hackathon didn’t possess for me. Fifteen of us came together Friday night for food and drink at @amichaelberman house. Saturday morning we came together at Pepperdine and spent the day working through ideas and tool demonstrations, which included a lot of open discussion. Saturday night we came together at our house in Hermosa Beach, where we drank, continued conversations from the day, and Jazzercised on the roof until wee hours of the morning. Then Sunday we came together for breakfast, and went back to work at Pepperdine for the rest of the day. Once done, some folks headed to airport, and the rest of headed back to Hermosa Beach for dinner, more drinks, and conversation until late in the evening.

Over the two days, there was plenty of hacking, setting up Known and Smallest Federated Wiki, as part of Reclaim Your Domain. Most attendees got to work on their #Reclaim definitions, and POSSEE workflow using Known, and learned how to generate API keys, commit to Github, and other essential #Reclaim tasks. At many other hackathons I’ve been to, there were tangible projects that came out of the event, but were always abandoned after the short weekend. #Reclaim didn’t produce any single startup or application, but deployed and evolved on top of existing work, and processes, that will continue long after this single event, and will continue to build momentum with each event we do--capturing much more of the exhaust from a weekend hackathon.

The Time Is Right For #Reclaim
I feel #Reclaim is in motion, and there is no stopping it now. Each of the three events I’ve done, have been extremely fruitful, and the ideas, conversation, and code just flows. I see signs across the Internet, that some people are beginning to care more about about their digital self, in light of exploitation from government, and technology companies. It is not an accident that this movement is coming out of higher education institutions, and will continue to spread, and build momentum at universities. The time is right for #Reclaim, I can feel it.

See The Full Blog Post

AutoDevBot Open Sources Their API Monitor

The API monitoring service AutoDevot has opened sourced their JavaScript API monitoring solution, built on Frisby.js, called API Monitor Runner. The API monitoring tool, allows for a pretty robust configuration file, that lets you detail exactly what the service should monitor, and how it should behave when something out of the ordinary happens.

I though the trigger actions stood out, allowing you to take common actions when something occurs with an API:

  • TRIGGER_EMAIL - enable email notification
  • TRIGGER_PAGER_DUTY - enable PagerDuty notification
  • TRIGGER_WEBHOOK - enable a generic webhook notification
  • TRIGGER_HIPCHAT- enable HipChat notification

AutoDevBot, even takes things to another level, providing a ready to go Docker container, to quickly deploy API Monitor Runner, and then configure it on setup, using Docker environment params--a very interesting approach to deploying open tooling to support APIs.

I really like this type of deployment for vital API services, focusing on providing a simple, valuable, cloud-based service, as well as an open source version that anyone can put to use. We just saw the same moves from 3Scale with the release of APITools, and now AutoDevBot with API Monitor Runner.

I’d love to see other critical building blocks of the API economy emulate this approach—there is plenty of money to be made from cloud services, while also providing open tool that will stimulate API growth across many business sectors. Which, creates more need for services.

See The Full Blog Post

Smallest Federated Wiki Blueprint Evangelism

I’m playing with a new tool that was brought to my attention called, the Small Federated Wiki (SFW), a dead-simple, yet powerfully extensible, and federated online platform solution, developed by Mike Cauffield. In his latest post about Smallest Federated Wiki as a Universal JSON Canvas, Mike opens up with a story of how hard tech evangelism is, with an example from Xerox PARC:

Watching Alan Kay talk today about early Xerox PARC days was enjoyable, but also reminded me how much good ideas need advocating. As Kay pointed out repeatedly, explaining truly new ways of doing things is hard.

First, without Mike’s continue storytelling around his work, it wouldn’t continue to float up on my task list. His story about it being a “Universal JSON Canvas”, caught my attention, lit a spark that trumped the shitload of other work I should be doing this morning. Evangelism is hard. Evangelism is tedious. Evangelism requires constant storytelling, in real-time.

Second, for the Smallest Federated Wiki (SFW) to be successful, evangelism will have to be baked in. I will be playing with this concept more, to produce demonstrable versions, but SFW + Docker Containers, will allow for a new world of application collaboration. The Amazons, Googles, and Microsofts of the world are taking popular open source platform combinations like Wordpress, and Drupal, creating container definitions that include Linux, PHP, MySQL and other platform essentials, that can be easily deployed in any environment—now think about the potential of SWF + Docker.

Following this new container pattern, I can build out small informational wikis using SWF, add on plugins, either standard or custom, and create a specific implementation of SWF, which I can deploy as a container definition with underlying linux, node.js, and other required platform essentials. This will allow me to tailor specific SWF blueprints, that anyone else can deploy with the push of a button. Think courseware, research, curation, and other collaborative classroom application scenarios--I can establish a base SFW template, and let someone else run with the actual implementation.

Now, bringing this back home to evangelism--Mike doesn’t have to run around explaining to everyone what SFW does, well he should be, but not to EVERYONE. People who care about specific domains, can build SFW blueprints, utilize containers on Amazon, Google, Microsoft and other providers to deploy blueprints, and through evangelizing their own SFW implementations, will evangelism what SFW is capable of, to other practitioners--federated evangelism baked in too! ;-)

The federation of evangelism, will be how the Smallest Federated Wiki spreads like a virus.

See The Full Blog Post

If I Could Design My Perfect API Design Editor

I’ve been thinking a lot about API design lately, the services and tooling coming from Apiary, RAML and Swagger, and wanted to explore some thoughts around what I would consider to be killer features for the killer API design editor. Some of these thoughts are derived from the features I’ve seen in Apiary and RAML editor, and most recently the Swagger Editor, but I’d like to *riff* on a little bit and play with what could be the next generation of features.

While exploring my dream API design editor, I’d like to walk through each group of features, organized around my indentations and objectives around my API designs.

Getting Started
When kicking off the API design process, I want to be able to jumpstart the API design lifecycle from multiple sources. There will be many times that I want to start from a clean slate, but many times I will be working from existing patterns.

  • Blank Canvas - I want to start with a blank canvas, no patterns to follow today, I’m painting my masterpiece. 
  • Import Existing File - I have a loose API design file laying around, and I want to be able to open, import and get to work with it, in any of the formats. 
  • Fork From Gallery - I want to fork one of my existing API designs, that I have stored in my API design taller (I will outline below). 
  • Import From API Commons - Select an existing API design pattern from API Commons and import into editor, and API design gallery.

My goals in getting started with API design, will be centered around re-use the best patterns across the API space, as well as my own individual or company API design gallery. We are already mimicking much of this behavior, we just don’t have a central API design editor for managing these flows.

Editing My API Design
Now we get to the meat of the post, the editor. I have several things in mind when I’m actually editing a single API definition, functions I want, actions I want to take around my API design. These are just a handful of the editor specific features I’d love to see in my perfect API design editor.

  • Multi-Lingual - I want my editor to word with API definitions in API Blueprint, RAML and Swagger. I prefer to edit my API designs in JSON, but I know many people I work with will prefer markdown or YAML based, and my editor needs to support fluid editing between all popular formats. 
  • Internationalization - How will I deal with making my API resources available to developers around the world? Beyond API definition langugages, how do I actually make my interfaces accessible, and understood by consuers around the glob.e
  • Dictionary - I will outline my thoughts around a central dictionary below, but I want my editor to pull from a common dictionary, providing a standardized language that I work from, as well as my company when designing interfaces, data models, etc. 
  • Annotation - I want to be able to annotate various aspects of my API designs and have associated notes, conversation around these elements of my design. 
  • Highlight - Built in highlighting would be good to support annotations, but also just reference various layers of my API designs to highlighting during conversations with others, or even allowing the reverse engineer of my designs, complete with the notes and layers of the onions for others to follow. 
  • Source View - A view of my API design that allows me to see the underlying markdown, YAML, or JSON and directly edit the underlying API definition language. 
  • GUI View - A visual view of my API design, allowing for adding, editing and removing elements in an easy GUI interface, no source view necessary for designing APIs. 
  • Interactive View - A rendered visual view of my API, allowing me to play with either my live API or generated mock API, through interactive documentation within my editors. 
  • Save To Gallery - When I’m done working with my API designs, all roads lead to saving it to my gallery, once saved to my working space I can decide to take other actions. 
  • Suggestions - I want my editor to suggest the best patterns available to me from private and public sources. I shouldn't ever design my APIs in the dark.

The API design editor should work like most IDE’s we see today, but keep it simple, and reflect extensibility like GIthub’s Atom editor. My editor should give me full control over my API designs, and enable me to take action in many pre-defined or custom ways one could imagine.

Taking Action
My API designs represent the truth of my API, at any point within its lifecycle, from initial conception to deprecation. In my perfect editor I should be able to take meaningful actions around my API designs. For the purposes of this story I’m going to group actions into some meaningful buckets, that reflect the expanding areas of the API lifecycle. You will notice the four areas below, reflect the primary areas I track on via API Evangelist.

Design Actions
Early on in my API lifecycle, while I’m crafting new designs, I will need to take action around my designs. Designs actions will help me iterate on designs before I reach expensive deployment and management phases.

  • Mock Interface - With each of my API designs I will need to generate mock interfaces that I can use to play with what my API will deliver. I will also need to share this URL with other stakeholders, so that they can play with, and provide feedback on my API interface. 
  • Copy / Paste - API designs will evolve and branch out into other areas. I need to be able to copy / paste or fork my API designs, and my editor, and API gallery should keep track of these iterations so I don’t have to. The API space essentially copy and pastes common patterns, we just don’t have a formal way of doing it currently. 
  • Email Share - I want to easily share my API designs via email with other key stakeholders that will be part of the API lifecycle. Ideally I wouldn’t be emailing around the designs themselves, just pointers to the designs and tools for interacting within the lifecycle. 
  • Social Share - Sometimes the API design process all occur over common social networks, and in some cases be very public. I want to be able to easily share all my API designs via my most used social networks like Github, Twitter and LinkedIn. 
  • Collaboration - API design should not be done in isolation, and should be a collaborative process with all key stockholders. I would like to to even have Etherpad style real-time interactions around the design process with other users.

API design actions are the first stop, in the expanding API design lifecycle. Being able to easily generate mocks, share my interfaces and collaborate with other stakeholders. Allowing me to quickly, seamlessly take action throughout the early design cycles will save me money, time and resources early on—something that only become more costly and restrictive later on in the lifecycle.

Deployment Actions
Next station in the API design lifecycle, is being able to deploy APIs from my designs. Each of the existing API definition formats provide API deployment solutions, and with the evolution in cloud computing, we are seeing even more complete, modular ways to take action around your API designs.

  • Server - With each of my API designs, I should be able to generate server side code in the languages that I use most. I should be able to register specific frameworks, languages, and other defining aspects of my API server code, then generate the code and make available for download, or publish using Github and FTP. 
  • Container - Cloud computing has matured, producing a new way of deploying very modular architectural resources, giving rise to a new cloud movement, being called containers. Container virtualization will do for APIs, what APIs have done for companies in the last 14 years. Containers provide a very defined, self-contained way of deploying APIs from API design blueprints, ushering a new ay of deploy API resources in coming years.

I need help to deploy my APIs, and with container solutions like Docker, I should have predefined packages I can configure with my API designs, and deploy using popular container solutions from Google, Amazon, or other coud provider.

Management Actions
After I deploy an API I will need to use my API definitions as a guide for an increasing number of areas of my management process, not just the technical, but the business and politics of my API operations.

  • Documentation - Generating of interactive API documentation is what kicked off the popularity of API design, and importance of API definitions. Swagger provider the Swagger UI, and interactive, hands-on way of learning about what an API offered, but this wasn’t the only motivation—providing up to date documentation as well, added just the incentives API providers needed to generate machine readable documentation.
  • Code - Second to API documentation, providing code samples, libraries, and SDKS is one of the best ways you can eliminate friction when on boarding new API users. API definitions provide a machine readable set of instructions, for generating the code that is necessary throughout the API management portion of the API lifecycle. 
  • Embeddable - JavaScript provides a very meaningful way to demonstrate the value of APis, and embeddable JavaScript should always be part of the API lifecycle. Machine readable API definitions can easily generate visualizations that can be used in documentation, and other aspects of the API lifecycle.

I predict, with the increased adoption of machine readable API formats like API Blueprint, RAML and Swagger, we will see more layers of the API management process be expanded on, further automating how we manage APis.

Discovery Actions
Having your APIs found, and being able to find the right API design for integration, are two sides of an essential coin in the API lifecycle. We are just now beginning to get a handle on what is need when it comes to API discovery.

  • APIs.json - I should be able to organize API designs into groupings, and publish an APIs.json file for these groups. API designs should be able to be organized in multiple groups, organized by domain and sub-domain. 
  • API Commons - Thanks to Oracle, the copyright of API of API definitions will be part of the API lifecycle. I want the ability to manage and publish all of my designs to the API Commons, or any other commons for sharing of API designs.

The discovery of APIs has long been a problem, but is just now reaching the critical point where we have to start develop solutions for not just finding APIs, but also understanding what they offer, and the details of of the interface, so we can make sense of not just the technical, but business and political decisions around API driven resources.

Integration Actions
Flipping from providing APIs to consuming APIs, I envision a world where I can take actions around my API designs, that focus on the availability, and integration of valuable API driven resources. As an API provider, I need as much as assistance as I can, to look at my APIs from an external perspective, and being able to take action in this area will grow increasingly important.

  • Testing - Using my machine readable API definitions, I should be able to publish testing definitions, that allow the execution of common API testing patterns. I’d love to see providers like SmartBear, Runscope, APITools, and API Metrics offer services around the import of API design generated definitions. 
  • Monitoring - Just like API testing, I want to be able to generate definition that allow for the monitoring of API endpoints. My API monitoring tooling should allow for me to generate standard monitoring definitions, and import and run them in my API monitoring solution.

I’d say that API integration is the fastest growing area of the AP space, second only to API design itself. Understanding how an API operates, from an integrators perspective is valuable, not just to the integrator, but also the provider. I need to be thinking about integration issues early on in the API design lifecyle to minimize costly changes downstream.

Custom Actions
I’ve laid out some of the essential actions I’d like to be able to take around my API definitions, throughout the API lifecycle. I expect the most amount of extensibility from my API design editor, in the future, and should be able to extend in any way that I need.

  • Links - I need a dead simple way to take an API design, and publish to a single URL, from within my editor. This approach provides the minimum amount of extensibility I will need in the API design lifecycle. 
  • JavaScript - I will need to run JavaScript that I write against all of my API designs, generating specific results that I will need throughout the API design process. My editor should allow me to write, store and execute JavaScript against all my API designs. 
  • Marketplace - There should be a marketplace to find other custom actions I can take against my API designs. I want a way to publish my API actions to the marketplace, as well as browse other API actions, and add them to my own library.

We’ve reached a point where using API definitions like API Blueprint, RAML, and Swagger are common place, and being able to innovate around what actions we take throughout the API design lifecycle will be critical to the space moving forward, and how companies take action around their own APIs.

API Design Gallery
In my editor, I need a central location to store and manage all of my API designs. I’m calling this a gallery, because I do not want it only to be a closed off repository of designs, I want to encourage collaboration, and even public sharing of common API design patterns. I see several key API editor features I will need in my API design gallery.

  • Search - I need to be able to search for API designs, based upon their content, as well as other meta data I assign to my designs. I should be able to easily expose my search criteria, and assist potential API consumers in finding my API designs as well. 
  • Import - I should be able to import any API design from a local file, or provide a public URL and generate local copy of any API design. Many of my Api designs will be generated from an import of existing definition. 
  • Versioning - I want the API editor of the future to track all versioning of my API designs. Much like managing the code around my API, I need the interface definitions to be versioned, and the standard feature set for managing this process. 
  • Groups - I will be working on many API designs, will various stakeholders in the success of any API design. I need a set of features in my API design editor to help me manage multiple groups, and their access to my API designs. 
  • Domains - Much like the Internet itself, I need to organize my APIs by domain. I have numerous domains which I manage different groups of API resources. Generally I publish all of my API portals to Github under a specific domain, or sub-domain—I would like this level of control in my API design editor. 
  • Github - Github plays a central role in my API design lifecycle. I need my API design editor to help me manage everything, via public and private Github repository. Using the Github API, my API design editor should be able to store all relevant data on Github—seamlessly. 
  • Diff - What are the differences between my API designs? I would like to understand the difference between each of my API resource types, and versions of each API designs. It might be nice if I could see the difference between my API designs, and other public APIs I might consider as competitors. 
  • Public - The majority of my API designs will be public, but this won’t be the case with every designer. API designers should have the control over whether or not their API designs are public or private.

My API design gallery will be the central place i work from. Once I reach a critical mass of designs, I will have many of the patterns I need to design, deploy and manage my APIs. It will be important for me to have access to import the best patterns from public repositories like API Commons. To evolve as an API designer, I need to easily create, store, and evolve my own API designs, while also being influenced by the best patterns available in the public domain.

Embeddable Gallery
Simple visualization can be an effective tool in helping demonstrate the value an API delivers. I want to be able to manage open, API driven visualizations, using platforms like D3.js. I need an arsenal of embeddable, API driven visualizations to help tell the store of the API resources I provide, give me a gallery to manage them.

  • Search - I want to be able to search the meta data around the API embeddable tools I develop. I will have a wealth of graphs, charts, and more functional, JavaScript widgets I generate. 
  • Browse - Give me a way to group, and organize my embeddable tools. I want to be able to organize, group and share my embeddable tools, not just for my needs, but potentially to the public as well.

A picture is worth a thousand words, and being able to easily generate interactive visualizations, driven by API resources, that can be embedded anywhere is critical to my storytelling process. I will use embeddable tools to tell the story of my API, but my API consumers will also use these visualizations as part of their efforts, and hopefully develop their own as well.

API Dictionary
I need a common dictionary to work from when designing my APIs. I need to use consistent interface names, field names, parameters, headers, media types, and other definitions that will assist me in providing the best API experience possible.

  • Search - My dictionary should be available to me in any area of my API design editor, and in true IDE style, while I’m designing. Search of my dictionary, will be essential to my API design work, but also to the groups that I work with. 
  • Schema.org - There are plenty of existing patterns to follow when defining my APIs, and my editor should always assist me in adopting, and reusing any existing pattern I determine as relevant to my API design lifecycle, like Schema.org.
  • Dublin Core - How do I define the metadata surrounding my API designs? My editor should assist me to use common metadata patterns available like Dublin Core.
  • Media Types - The results of my API should conform to existing document representations, when possible. Being able to explore the existing media types available while designing my API would help me emulate existing patterns, rather than reinventing the wheel each time I design an API. 
  • Custom - My dictionary should be able to be driven by existing definitions, or allow me to import and and define my own vocabulary based upon my operations. I want to extend my dictionary to meet the unique demands of my API design lifecycle.

I want my API design process to be driven by a common dictionary that fits my unique needs, but borrows from the best patterns already available in the public space. We already emulate many of the common patterns we come across, we just don’t have any common dictionary to work from, enforcing healthy design via my editor.

An Editor For Just My Own API Design Process
This story has evolved over the last two weeks, as I spent time in San Francisco, discussing API design, then spending a great deal of time driving, and thinking about the API design lifecycle. This is all part of my research into the expanding world of API design, which will result in a white paper soon, and my intent is to just shed some light on what might be some of the future building blocks of the API design space. My thoughts are very much based in my own selfish API design needs, but based upon what i’m seeing in the growing API design space.

An Editor For A Collective API Design Process
With this story, I intend to help keep the API design process a collaborative, and when relevant a public affair. I want to ensure we work from existing patterns that are defined in the space, and as we iterative and evolve APIs, we collectively share our best patterns. You should not just be proud of your API designs, and willing to share publicly, you should demonstrate the due diligence that went into your design, attribute the patterns you used to contribute to your designs, and share back your own interpretation—encouraging re-use and sharing further downstream.

What Features Would Be Part of Your Perfect API Design Editor
This is my vision around the future of API design, and what I’d like to have in my editor—what is yours? What do you need as part of your API design process? Are API definitions part of the “truth” in your API lifecycle? I’d love to hear what tools and services you think should be made available, to assist us in designing our APIs.

Disclosure: I'm still editing and linking up this post. Stay tuned for updates.

See The Full Blog Post

An Operational Harness For My Screen Capture API

I am evolving my own approach to deploying my API resources, and I needed an important sounding name for it, so came up with “operational harness” over a couple pints of IPAs. Ok, so what do I mean when I say operational harness?

Based upon the way that I evolve my stories, I evolve my API projects in real-time with the help of Github. For my screen capture API I will be focusing on delivering four separate architectural pieces:

  • Open Source Version - An open source, server implementation of my screen capture API, which will PHP initially with other languages next.
  • API Service - A publicly accessible, cloud version of the screen capture API, allowing users to a certain amount of calls in a specific time frame before they are charged a per call rate, depending on their service their.
  • API Containers - OpenShift and AWS CloudFormation version of the screen capture API for rapid deployment in cloud environment.
  • Wholesale Service - A wholesale version of the screen capture that a partner can pay me to deploy and / or manage in mine or theirs cloud environment.

I call this my operational harness because I will be operating live instances of these components, scaling as I need in the cloud, but will also be maintaining the open source version, and container versions on Github, while also supporting wholesale deployment.  My definition will act as a sort of harness holding together all the architectural pieces of the screenshot API, but also in sync with other utility APIs I will be deploying--helping guide me as I push it all forward.

I’m enjoying putting together my strategy around my own API platform. It gives me some good material to work through for stories here on the blog, and helps me push forward with new approaches to API deployment, like deploying and scaling in virtual containers, and providing wholesale access to resources.

See The Full Blog Post

Virtualized API Stacks

Up until now we tend to think of APIs individually--we approach integration in terms of the Twilio API, Twitter API or the Facebook API. But as the number of public APIs has grown beyond 8K, and an unknown amount of internal and partner APIs become available, we are seeing new patterns of aggregation and interoperability emerge from companies like Singly, but also seeing automation be added into the mix by companies like Temboo, and entire backend stacks from providers like Parse.

These new aggregated or backend stacks of API driven resources can be as general as object and key-value stores, user management and other developer commodities we see backend as a service providers (BaaS) bring to the table, or they can be very personal like the photos Singly is aggregating across Flickr, Facebook and Instagram and with friends and followers across Facebook, Twitter and LinkedIn.

As I see these new aggregate and BaaS providers emerge, at an ever increasing pace, I can’t help but think--this still isn’t fast enough (its my nature, you should try being me). If I want common mobile developer resources I can adopt one of these new BaaS platforms like Kinvey or Parse, or if I need personal and social resources, which have become part of the fabric of web and mobile apps, I can go to Singly. But what if I want a more specialized network, say just for education? I might need user management, object storage, key-value storage, access to commons social tools like friends and photos across multiple social networks, but I also need access to open courseware, teacher and student directories all via a very secure, auditable, efficient stack tailored just for K-12? I will have to wait, for the next wave of startups to emerge.

While in NYC on Friday I had a great discussion with Temboo about virtualization. Not just the virtualization we’ve come to depend on with cloud computing--which is the virtualization of compute, storage, and database resources, but the virtualization of network resources and software defined networking. Companies like Nicira, Pluribus Networks, Anuta Networks, Arista, and Vyatta are emerging with new products that are allowing the virtualization of networking resource into new and meaningful network stacks for any possible implementation that you can imagine.

After these conversation with the Temboo team, over the weekend I continued to think about the potential of virtualized API stacks. Why can’t I assemble my own API stack? Why do I have to go to each API individually, or wait for new Singlys' to emerge in other verticals? Why can’t I assemble Parse, Singly, Twilio, Schoology, SendGrid into a virtualized API stack that provides not just ease of use, but the security I need to deploy a backend tailored just for K-12 education?

In this vision of the future, API providers could focus on what they do best, and not worry about every use case out there. Providers like Singly, Temboo, Parse can build abstracted layers on top of this. With this abstraction I wouldn’t be limited to just the friends and followers features on Twitter or Facebook, I could take advantage of the next generation of friend discovery tools like what Singly is delivering--in addition to the value of individual API providers.

With a virtualized approach, I could build the stack that is most meaningful for my internal, partner or public developers and if one piece of my stack is proving unreliable, I can replace it with another. APIs resources would be further commoditized, required to provide JSON definitions of their interfaces (or die a quick death), which virtual API stack platforms could use to discover and offer API resources. API ranking algorithms would emerge allowing anyone to make sure they were discovering, selecting and using the best of breed API resources in the areas that matter for any vertical.

With a virtualized API stack I could launch any specialized set of resources that I desired from the best of breed providers out there. I could blend private and public resources together and in return offer them for use in private or public environments, further blurring the lines of what is an API and how they are consumed.

As we see APIs continue to become a driving force in government, healthcare and education and bridge the online and physical worlds via our automobiles, homes, buildings and further grow within healthcare via the quantified self, potentially disrupt manufacturing with 3D printing and drive everything around us with the internet of things--the manual assembling of individual or even aggregated API stacks won’t be enough. We will need the ability to virtualize APIs stacks for any purpose within hours, not months or years.

See The Full Blog Post