{"API Evangelist"}

More Pondering On My Own Microservice Definition

Like API, the term microservice has emerged as a force, along with a meaning that is very precise, or very broad, depending on who you are. The only thing I’m sure of at this point, is the term microservice is very personal, and means very different things to different people, depending on where you stand in the industry.

Regardless I can't help but consider the implications of the term, internalize it, and see what value I can derive from its meaning in my own world. This exercise leaves me asking, what is a microservice? Over and over, acknowledging I may never fully know the meaning, and like API it will be more of a journey, then it never will be a destination.

First and foremost in my world a microservice means simple, and small. Simple and small. Simple and small. Say it until you can feel it, all Buddhist colliding with API Evangelist. Simple and small, penetrates all layer of meaning for me.

  • minimal surface
  • minimal on disk
  • minimal compute
  • minimal message
  • minimal network
  • minimal ui
  • minimal time to rebuild
  • minimal time to throw away

Ultimately I want all of this, coupled with the ability to achieve maximum scale, with minimum effort. I want to do one thing, as well as I possibly can, with as minimal resources necessary, but delivering the maximum value at any scale—with value benefiting myself, my API consumers, and the end-users being served, equally.

None of this is set in stone for me. I acknowledge this is my own perception, and that others will see microservices as something entirely different. Even so, I share my definition publicly, as also I enjoy reading others definition. I kind of think that is part of the whole microservices thing, sharing your own personal definition. In reality microservices do not change my API mission, but it does allow the conversation to be distilled down, for a new generation of business leaders working to make sense of all of this.



Weekly API.Report For March 16th, 2015

Phew!! This week was hard. I just couldn't find the mojo to plow through, but I did it. A little late on Monday evening, but still so worth doing--putting the week into perspective.

I'm still trying to assess the best balance with what I post as individual news stories on API.Report. I think more of this could be pulled out as actual news stories, but will have to see if I have the time. Overall I am happy with how the weekly API.Report is evolving, but there is so much more I could do.

The Weekly API.Report represents the best of what I've read throughout the week, and is only what I personally felt should be showcased. Each news item comes with a link, and some thoughts I had after curating the piece of API related news. I'm trying to break down stories into as coherent buckets as I can, but it remains something that is ever changing for me, but ultimately I will settle on a clear definition for each of the research areas.

I track on a lot of 3D Printing, but few of them are directly API related, finallky one that moves the conversation forward:

A handful of acquisitions I noticed this week, with one more stroy on last weeks IBM acquisition:

Several interesting API analysis related things I am tracking on:

Some API definition stories from me this week:

  • Crafting Exactly The API Definition You Need With Swagger Vendor Extensions · - Swagger vendor extensions were new to me, so I wanted to share the fact that they existed, in case you thought Swagger wasn't extensible. I will be using, and adding to the spec where it makes sense. 
  • What is ALPS? · - I'm working to better understand ALPS, and paying attention to conversations going on around it. What Mike and Mark are working on is important, and i just need to find some entry level use cases to help onboard people.

Some serious API deployment movement this week, with a couple of new offerings:

Some approahces to API Deprecation:

Mostly my own API design thoughts this week:

Again, mostly my own stories, but a handful of API discovery items this week:

A wide variety of API evangelism stories:

API integration related stories, with commerce taking over:

Some interesting shifts, and additions in the world of API management:

Thinking I'll keep breaking API monitoring, out of integration stories:

I can usually count on Zapier for one good API reciprocity story a week:

Like montoring, I will keep breaking out API testing stories into their own category:

I can usually find some API visualizations related stories, even it is more visualizaiton than just API:

Thought this was a very cool nod in the world of architecture:

Anything art related I can sneak in:

Two automobiles, API, and data related items:

Business of APIs is always a good catch-all bucket:

Putting any interesting API related job posts under what I call careers:

A small CDN related nuggest from AWS:

I call it city government, but put anything API, and data related to city operations here:

Always several cloud computing items to talk about betwwen AWS, Microsoft, and Google:

Two items standing out specifically dealing with cloud storage:

Didn't quite know how to categorize this one, so simply tagged as code:

Magento integrations was a big part of the commerce stories:

Not to much worthy enough talking about on the communications front:

Lighter lod of stories on the containerzation front:

Direct CORS stories isn't always something you see:

The always full list of data related stories I'm tracking on:

Some of the SDN related talks bleeding over into the data center:

Two database stories stood out this week for me:

Several education related items that caught my attention:

I'll keep an eye on election related stories as we get closer to 2016 here in the US:

  • Quick Sketch – Election Maps - I will be tracking on data, analysis, visualization, mapping and other areas in support of elections. I'm all about shaking things up here.

Two encryption related thougths:

Always makes me happy when there are energy related stories:

Two sides of the enterprise API conversation:

Always lots of activity in the federal government:

The financial world is continuing to heat up with API conversations:

Another interesting view on using GitHub:

Handful of hackathons stories:

Appled fueled healthcare stories:

One item to add to my history of tech stories:

API related talk in the home:

One hypermedia discussion to note:

Infrastructure conversations out of Netflix are often worth showcasing:

Some crossover with other areas in the world of Internet of Things:

Couple of items to note in the legal bucket:

I wish I had more library related items each week:

The always interesting concept of machine learning:

Three mapping related items:

TWo interesting items on microservices that I read:

When it comes to date I'm going to start slicing off open data specific related stories:

Movement on the outdoors API front out of the government:

  • Open Data for the Outdoors - A nice call to action around the RIDB, and work in federal government around recreation API. 
  • mheadd/node-ridb - My man Mark got inspired and build an SDK for the RIDB database. nice! 
  • Agencies tap into recreational data - A view, a little closer to the government press side. I'm tracking on all stories I come across, to show the full view of story from all sides.

Always something payment related to discuss:

Only one entry in the area of policing this week:

Politics of APIs is where I put all the politically charged ideas from the week:

The growing concern of privacy:

PubNub is always good for some real-time stories:

Reporting stories coming out of SalesForce has caught my attention:

Anything related to scraping and Kimono is worthy of talking about:

Couple of SDK specific stories were interesting:

Lots of security items this wee, with cross-over from a couple of other areas:

Two Single Page Applications (SPA) items:

Smart watches will probably be tracked on separately from IoT in the future:

Single social related items:

  • Introducing the MailUp App for Facebook - I do not see as many announcements regarding new apps on Facebook, figured I'd record when I do. Keep track of what is being deployed in this environment.

The hot topic of Software Defined Networking (SDN):

A story I did on spreadsheets, sparked some interesting discussions, and finds this week:

The important area of transparency:

An interesting take on how educated about API versions:

Wearables will be tracked on separatelky from IoT:

Two interesting weather items:

The API for Wikipedia sucked me in this week, and worthy of showcasing the wiki API tech behind it:

  • RESTBase docs - I idid not know about RESTBase. I'm looking into adding it to my API deployment and management research. I just need to understand it better.

A handful of Women in Tech stories in my feed this week:

That concludes my report on what I read last week across the API space. I'm still working on pulling together a summary e-newsletter version, allowing people to get an executive summary of what I thought was important from the week--I am hoping it will be available next week. I'm also going to auto-generate some visualizations, and summary counts for each week. I'd like to see a tag cloud, and overall counts to help me understand the scope of news I cover each week.

As I did last week, I'm walking away with a better awareness of what is happening across the space. It isn't enough for me to read all of this API news in isolation, it helps to see it side by side with other news, allowing me to see and understand patterns that I may have missed. 

Thanks for reading. ;-)

 



The Enterprise Will Make The Same Mistakes With API And Microservices That They Did With SOA, Because Essential API Concepts Go Right Over Their Head

I would say the enterprise space fleet has successfully shifted their course, heading in the general direction of everything API. SAP, Oracle, IBM, Microsoft, and the rest of the usual suspects have pledged their faith to APIs, mobile, and IoT, all in a very public way. For those of us who jumped off the SOA bandwagon a while back (getting on the API bandwagon, yeehaw), this can be amusing to watch, cause the API bandwagon is better y'know?. ;-)

I sincerely hope that these large companies can make a shift towards an API way of life, or a microservice devops way of operating, or whatever the cool enterprise kids are calling it these days. Some companies will find success in these areas, while many, many others will just talk about it, and buy a wide range of vendor services that will help them talk about it—there will be a lot of money to be made (and spent).

The thing I fear, is that many of the core principles of why this whole thing is working will go right over the heads of many technologies and business leaders in the enterprise. Elements like simplicity, transparency, openness, and functioning in a decoupled, decentralized way. You are the enterprise, many of the essential ingredients of API, are just fundamentally at odds with what you are. You are a big, complex, powerful, and political corporate presence—a beast that does not like being taken apart, reinvented over and over, and being forced to work in concert with other internal, partner, and public resources, in an open way.

This doesn't mean that some enterprise entities won’t be successful—some will. I will be carefully watching the waves of enterprise organizations, for these tech savvy few, who internalize the core philosophy around APIs, successfully uploading their corporate soul to the API singularity. However, I predict I will have to work very hard to find these companies amidst the wreckage of the enterprise organizations that make the same mistakes they did with SOA, because APIs are just not compatible with their DNA, and ultimately will be rejected for reasons that are more enterprise than they are API.



Postman Collections As Unit Of Measurement For Transactions In The API Economy

I'm immersed in deep thoughts about the implications of machine readable API definitions like APIs.json, Swagger, and Postman Collections, which are being applied to APIs, in some very different, but overlapping, and complementary ways. Currently I’m working to define the overlap between APIs.json and Postman Collections, and how they work together.

For me, any good API starts with a Swagger definition, or API Blueprint, which is the single, machine readable truth of what is the surface area of any API, which I consider fingerprint for what is possible with any API or micro service. Additionally when I am working with any API, or stack of APIs, I am using APis.json to organize them into a single coherent set of APIs, then rely on each APIs properties to point to essential resources like Swagger, terms of service, pricing, and anything else I feel is essential to operations.

In addition to providing links to Swagger definitions for each APIs.json API entry, I’m also experimenting with adding a property that point to any Postman Collection for each API, and microservice. I’ll start by just calling the type “x-postman-collection”, and provide a URL to a Postman Collection I’ve generated around the API call, providing a link between what an API is, and a measurement of the transaction an API produces.

I’d say that Swagger is the promise of value an API delivers, and Postman is a machine readable representation of the value, ready for execution—which acts as machine readable unit you can then load into Postman, or any other system, and actually experience the result. When this unit is sitting in your Postman client, you can see the value behind a single collection, but when you see a couple hundred of these collections in your Postman, you start seeing the important role they can play in the overall API economy, as portable a unit of measurement for API transactions.



Making The API Feedback Loop Machine Readable With APIs.json

If you are following some of my recent stories, I’m heavily focused on APIs.json, as I work to organize my own stack of microservices, using APIs.son and Swagger. I’m working hard to define additional, machine readable layers to my microservices index that answer as many of the questions that I have about the microservices and APIs that I depend on.

The first machine readable definition I include in any APIs.json collection I’m building is Swagger, which provides a JSON or YAML definition of the surface area for any microservice or API that I depend on. The second thing I put to work for my own APIs, is API Commons, which provides a JSON definition for the licensing of my APIs. Beyond that I’m pushing forward a couple of other machine readable definitions, that help me make sense of not just a handful of APIs in my own collections, but potentially thousands of APIs in the public space.

I just published two potential new machine readable definitions to add to my stack of APIs.json properties:

  • api-pricing - My quest to understand the API pricing across the API space, from providers like Amazon to Twilio, there are some healthy patterns to follow when crafting API pricing.
  • api-questions - My realization that nobody would give a shit about a machine readable terms of service, so I created a simple JSON list of questions and answers that can be applied to APIs.

These are two areas that I am trying to better understand, as I build my machine readable index of the APIs, that I call the API Stack, which also helps fuel APIs.io. Another area I’m struggling to get a handle on, is the message layer around APIs, and more widely what I’d consider the feedback look around APIs. So, what the heck do I mean by this? I’m not entirely sure, I’m still trying to figure it out in real-time--which is why I'm writing this post. 

If an API is one of my internal APIs, the messaging, communication, and feedback loop starts with issue management in Github. Each API has its own Github repo as its home base, and any communication around its design, deployment, and management, happens there. However there may be other references to the API made on Twitter, Stack Overflow, or other channel, and I am looking for a way to aggregate them all in a single machine readable away, that is connected to the API.

To do this, I’m employing the same approach I’m using to get a handle on pricing, and other questions I have around API operations, and creating a new APIs.json API property type, which I’m going to call api-conversations. Right now I’m just going to include message entries for Github issues, but work to make as inclusive as I can, to include any possible channel. We’ll see where I go with api-conversations, right now I’m going to use it to manage the feedback loop within my own microservices stack, but then I’m also going to apply to the API Stack, and see what it looks like when I try and aggregate the feedback loop around public APIs.