{"API Evangelist"}

Moving Away From Legacy Vendor Relationships To A Devops, Micro-Services Way Of Life At Nike

I had the pleasure of attending a gathering at Heavybit Industries last week, a community for developer-focused entrepreneurs, where one of the headlining speakers was Nike CTO Chris Satchell. I wish I had taken better notes, but the one thing that stuck with me from his talk was his story about moving beyond their love affair with almost any software vendor that came along, and diligentlywork towards a micro-service oriented environment.

As the CTO, Satchell was working to clean up the message of legacy applications used across the enterprise, which was the result of years of, as he put it, saying yes to almost any software vendor that came along. Music to the ears of the San Francisco audience, he was now working to move the company out of a single data center, into the cloud, redefining operations as micro-services, and instituting a devops mindset along the way. They are a long way away from achieving their goal, but I found the change in their mindset about how they acquire software, was extremely relevant to all the API talk in 2015.

While i’m sure there will still be plenty of opportunities for old school software vendors to hock their wares, I think this was a pretty clear sign of the API-centric approach that is changing not just how we develop and deploy software, but also how we buy software. If you are looking to sell software solutions to the enterprise in the future, you are going to need more than just yesterdays software, and a sales team—you are going to need the most agile, flexible, stack of micro-services possible, and let companies choose exactly the resources that they need.

Generating Client Side Code From Machine Readable API Definitions

This post has been open for almost two weeks now in Evernote. It began as a simple story about the possibility for generating code samples and libraries using Swagger. The longer it stays open, the wider the definition becomes, so I have to post something, just to draw a line in the sand. I’m not talking about generating code that runs on the server, this post is all about everything on the API consumption side of things.

Shortly after Wordnik launched the machine readable API definition format Swagger, they launched a library for generating client side code samples in a variety of languages. This was something that was evolved upon by Apiary, with the launch of their API design platform, and introduction of API Blueprint. Even with these advances forward, there were still many shortcomings, and debate around what you could actually auto-generate on the client-side using a machine readable API definition continued. I can’t tell you how many random Tweets I get from people saying, “Oh is auto-generation of code cool again?” or “I thought you couldn’t auto-generate client code or SDKs ;-)"

Amidst the debate about what is really possible, and the jokes about our SOA past, new players have emerged like Apimatic that are looking to raise the bar when it comes to generation of not just simple code samples, libraries or stubs, but sophisticated API SDKs. I am sure the jokes about automating client code will still occurs, but there is no denying that the overall conversation is moving forward.

As I’m exploring my own limitations of what is possible when generating client-side code with Swagger, I also come across new players like Lucybot, who are moving the conversation forward with API cookbooks, and Single Page App (SPA) generated from Swagger definitions. I’m not in denial that there is a lot of work ahead, but in the two weeks that I’ve been crafting this post, I’d say I have gotten a glimpse of what is next. When you bundle the latest movements in virtualization and containerization, and using API definitions like Swagger and API Blueprint to auto-generate client side code, I feel like the current potential is unlimited, and things are just heating up.

A Peek At The Future With White Label APIs

I’ve been talking about the possibilities around wholesale APIs for a while now, something that is only going to become more prevalent with the popularity of micro services and containers. I thought this company's approach to white label APIs was pretty basic, but worth showcasing, providing a glimpse of what is possible when you are talking about B2B APIs.

Recharge kit provides 15 separate APIs for wholesale usage. I thought it was a telco stack of APIs when I first landed, but it is an interesting mix of telco, utility, travel, and more. I predict companies will emerge with a much more nuanced stacks of micro-services than Recharge Kit, but their approach shows some of the thinking occuring in the space.

As part of the Recharge Kit white label package you also get a handful of API management tools, ranging from user management, and advertising, to billing, and support. The overall presentation is not that professional, but a lot of the essential API management building blocks are present. 

Delivering API management resources in this portable, and flexible way is reflected in my recent exploration with my 3Scale API management infrastructure on Alpha API Evangelist. I'm looking to understand how not to just manage my B2D or B2C API consumption, but also allow me to deliver on a new wholesale side of my operations. Wholesale APIs deployed as micro services via Docker containers adds a whole new dimension to API management, opening up more B2B, wholesale, and white label API opportunities like this.

The Alpha API Evangelist Workbench

The API Evangelist network is my open workbench, and I understand for many, it can be confusing to see some of my half-baked ideas alongside some of my more hardened API 101, business of APIs, and politics of APIs work. I try to keep the API Evangelist blog containing information for the API newbie, as well as my more advanced API leader crew--something that is tough to do.

I have a lot of ideas coming off the assembly line around my own infrastructure, Docker, microservices, and other more forward leaning areas. Normally I dump a lot of this mundane exhaust from my world over on Kin Lane, but that site gets picked up by DZone, due to historical connections, and that audience is pretty trollish, second only to Hacker News. I'm not looking to get into petty fights over choice I made around my own infrastructure.

To support my newer ideas, I launched Alpha API Evangelist, which will act as a kind of staging ground for many of the ideas you may eventually see here on API Evangelist. I do not want to alienate my just getting going audience, with rants about Docker and microservice orchestration, and I definitely do not want some of my unproven thoughts to getting taken out of context alongside some of my rants around important API topics in the business and politics of APIs.

I know some of you are like WTF, another blog, you are diluting your brand, blah blah. If you saw the API Evangelist Network like I do, as this open workshop for API research, and storytelling, you’d understand. Anyhoo….long story short…90% of the Docker, microservices, orchestration, Github API blah blah blah, is now over at alpha.apievangelist.com.

Driving Your Single Page Applications And API Cookbooks Using API Definition Formats Like Swagger And API Blueprint

During my monitoring of the API space this last week I had one of those rare discoveries, amongst thousands of misses, and around a hundred slightly interesting nuggets, a simple move forward called Lucybot emerges. 

I want to walk you through what I experienced as I had the tab open in my Chrome browser for the last week, in Lucybot's own words:

LucyBot is a tool for on-boarding new API developers, and is meant to be used alongside traditional API documentation such as Swagger and I/O Docs.

I really like this sentence when they start talking about generating API cookbooks:

LucyBot generates cross-language cookbooks for any REST API. Design step-by-step walk-throughs for any use case, and LucyBot will provide cross-language code snippets, which expand into a working, visually-rich demo.

Now you are talking my language. Swagger on Github is a powerful combo:

LucyBot can also push the code to GitHub, where users are free to build it out further, e.g. by pulling in data from their own servers or other APIs.

Add some API Blueprint to the mix, and now you have some serious API coverage. It can be difficult to understand the vision behind a new API driven start-up—I look at quite a few new companies. To help move the process forward, let’s start with the basics of what is significant about Lucynbot’s perspective n API. There are two things that stand out for me:

  • Learning About APIs - Lucybot takes an API definition like Swagger, and turns it into an interactive walk-through for on-boarding with an API. Think Swagger UI, but more interactive walk-through than interactive documentation--now add in a little Swagger driven Codecademy to help you authenticate, and navigate the request and response of each API. #Boom
  • API Driven Clients - Lucybot isn't just generating interactive documentation or walk-throughs, they are generating a single page application (SPA). Another move forward in how we learn about valuable API driven resources, how we on-board them, and how we engage with them, all in a single, fluid, API definition driven motion.

I have to admit, after exploring my thoughts around API visualization using Swagger from Chris, and seeing what is possible in generating “API Cookbooks”, and Single Page Apps (SPA), with Lucybot, I’m about to go into cardiac failure from the movement in the space over the last week. I’m excited about what Lucybot brings to the table. I haven’t even used their offering, but I can see the potential, and when you line up with the other movement in the API definition world around visualization, and the addition of hypermedia using API Blueprint, I can begin to see some of one possible future I’ve been imagining for the API Economy.

I am excited to see what Lucybot can deliver when it comes to cookbooks and SPAs. If they can deliver on the vision they are bringing to the table, it could further move the overall client and integration side of the API conversation forward pretty significantly. I’m seeing many of the important elements of delivering API and microservices coming together in 2015, and Lucybot reflects this. Adding yet another bonus incentive for creating machine readable API definitions using Swagger and API Blueprint to the API game.