27 May 2015
I enjoy playing with simple, meaningful ways of leaning about APIs. The other day, during the regular monitoring of the API space, I came across a simple dice rolling API, which I decide to map out using Swagger. Shortly after I did this, I saw Mike Amundsen post an ALPS representation of the Dice Rolling API. Around the same time, I then imported my Swagger into my Postman client, and exported a Postman collection.
Once I had the three formats, I sat back to consider what each of these representations mean to me:
- Swagger - A map of the surface area that is dice rolling.
- Postman - A single representation of actions that can be taken--now.
- ALPs - A representations of the what it means to roll the dice.
I am constantly working to evolve how I view the available API formats that are emerging throughout the space. I will be spending more time generating machine readable definitions for APIs in my stack, trying to push these definitions through these valuable filters. I do not think any single approach provides me with a definitive view of the resources I am describing, but at least give me with various lenses to look through, during my journey.
Swagger left me feel like I am mapping out a vast expanse, but alone doesn't do much for me without more tooling to interpret the map. Postman left me feeling like I could do one thing, linked to the surface area I mapped with my Swagger, but was very confined to just that specific instance, within the world I have drawn with Swagger. ALPS left me feeling like I described something meaningful, closer to the actual experience of rolling a dice.
Ultimately I do not see any of the emerging approaches to defining API driven resources as 100% the solution, or in black and white terms as wrong or right. I see Swagger as very much a bridge to a better defined world, while Postman satisfies the more immediate urges that I have, but ALPS...ALPS has the potential to help me internalize, feel, and interact with my digital resources, in a way that is much closer to the real world (not quite, but closer).
27 May 2015
One of my areas of research that got boost of energy at Gluecon last week, was the area of Single Page Applications, aka SPAs. SPAs are one huge area of potential growth for the API space, but like many other areas, they haven't seen the wider, more meaningful deployments, or adoption, that I had hoped for early on. I think up until now the definition of what an SPA is has been heavily dominated by the technical side of things, as opposed to the delivery side--SPA are still mostly about providing solutions for developers, over solutions for the end-user or business owner.
When it comes to SPAs, I stay away from the more established frameworks, opting for a simpler design--minimal platform or framework adoption. Not that solutions like Angular and Backbone don't do amazing things, just at this point in my career, I'm looking to avoid the adoption, and resulting dogma and dependency that can often come from drinking a specific frameworks kool-aid. I guess the overall footprint needs to be small, before I will allow something to creep my day to day operational world.
While at Gluecon, I was given a demo of a new product, which i won't go into detail about now, but I feel moves us closer to the vision than I have in my head. Many of the existing SPAs employ APIs, but I envision a world where you can design, deploy, and manage APIs, which alongside you can also deploy and manage simple, useful SPAs driven by your valuable API resources. I keep an eye on the SPA space, so I can be in tune with anything that emerges--hopefully my stories and research will also stimulate other solutions in the space as well.
To help you understand the potential for APIs in the SPA space, I am talking about deploying a simple, and I mean as simple as you can SPA deployment, using an API that is defined using a machine readable API definition like Swagger or API Blueprint. I want to be able to deploy 10s or 100s of mini sites, landing pages, and apps from a single stack of API resources. API providers, and consumers should be able to easily deploy the SPAs they need, driven by the valuable APIs of their choosing, into the infrastructure they desire, like on Github Pages, Heroku, or their own internal infrastructure.
Some day, we will see the cleaner, simple example of an API to SPA solution, that for now, is trapped in my head. Now that I write about this, I would also think of it as a lightweight, API client, which I'd also like to see be hypermedia compliant--man I am a demanding shit. ;-)
26 May 2015
Yeah, I know, it is a click-bait title. My goal is to not flame the haters, but educate everyone involved, both the people looking to learn about microservices, and those who are practicing microservices, so I'm hoping you will forgive me--my goal is not page views.
I'm sticking to my goal of not making microservices a regular thing I talk about, but I wanted to share some observations after listening to folks talk at Gluecon last week--a week that was full of microservices love (and hate). In the past, I mentioned that I received a handful of emails, and DMS from folks letting me know I'm not doing microservices, and after Gluecon I think I have a beginning list of why I think people generally are telling me I'm doing it wrong.
- Tooling - People tend to identify with the tooling they use, and deeply associate the function with the tool. So if I don't use Puppet or Chef, I'm not orchestrating. If your not using Jenkins, your not doing continous delivery, and so on. This is dangerous for microservices storytelling, but also is something that will continue.
- Vendor - This is probably the most egregious reason I see people telling others they are doing microservices wrong, and is somewhat akin to the tooling item, but is really just rooted in selling you something. You will never do it right, unless you are their customer, so don't worry about it.
- Scope - You just aren't doing it at the scope someone else is doing it. Microservices is something large enterprises do, not small companies, or individuals. You have to be operating across many availability zones, many servers, etc. Horseshit. Microservices can be done at any scope, don't listen to them.
- Completeness - You are only doing some of the aspects of microservices. Maybe you don't need to orchestrate across many operational zones, and your traffic looks very different than some of the usual suspects. Microservices is very seldom a complete picture, it is more about doing what works for you, cherry picking the valuable items you can apply in your world, not any complete definition.
- Incomplete Info - Someone just read a single blog post you wrote, and hasn't been following the series, asked any questions, and just make assumptions about a single thing you wrote. While I feel you should make each post as complete as possible, the responsibility is on the reader to do their homework - Bwahahaha! yeah right, pundits will never do that.
So far these are the biggest reasons that I've extracted from people me telling me I am not doing it right. Ultimately it comes down to power and control, which I saw play out with SOA, REST, Linked Data, and other areas of "API". They either want to make you feel small, or not cool because you aren't using the tools they are using, or they just want you to buy their snake oil.
In the end, for me, microservices are just a new storytelling package. They are mostly marketing, as many of the skeptics like to point out, and the companies who are truly doing microservices, will care about sharing their real-world stories, and work overtime to help you understand--there are a handful of them out there, like Runscope and Iron.io.
For me, I will be focusing on the moving parts of microservices, which is why you'll see me talking about API design, deployment, management, testing, monitoring, security over just "microservices" umbrella. I could easily attack many of the pundits who challenge me, and say you aren't doing API management, evangelism, monetization, or other critical areas right, but why would I? Where does that get us?
As usual, if you have any questions, let me know how I can help. I'm happy to share, as I try to make sense of all of this. I'm adding some new research sites to support the conversation.
26 May 2015
I am going on five years of API Evangelist this summer, and I've been doing some reflecting about what the next five years will be about. While listening to my friend Mike Amundsen (@mamund), I had an idea, that I think I will evolve more during the operations of the next five years of API Evangelist (yes, sorry I'm not going anywhere).
First, I want to clarify that when I started API Evangelist in summer of 2010, I spent a lot of time trying to create a logo, resulting in me creating this temporary (5 years) logo, that you have seen on my t-shirts for the last five years.
After listening to Mike spin his yarn, I'm convinced that the next wave of growth for API Evangelist has very little to do with me, and my brand, than it does with the rest of the API community. I've spent a lot of time sharing stories, but for us to get to the next level, it has to be about the community sharing its stories, or we will never get to the scale all of us API delusionaries envision.
To support this vision, I'm going to play with a new logo for API Evangelist, and print up a round of t-shirts with this evolution of the logo.
I know I'll get a lot of flack from the restarfarians, and hypermedia folks about the design, but it is more about the storytelling, than it is about being technical, but in my opinion, they both work in concert. I've often answered, when people ask me what is scale for API Evangelist, that it is about having hundreds of people doing what I do, across many business sectors, around the globe--this new design reflects that.
While this is a marketing effort for my brand, it really is about the next phase of growth for the space. To get to that API economy thing we are all showcase across the space, we are going to need API Evangelists to step up and own each sector, region, and country around the globe. API Evangelist isn't something that can scale as a business, it will take people who are passionate to step up in their industries and regions, and help evangelize APIs in a way that isn't about products, but about ideas, stories, and the people and brands who make things go around.
I'll let you know when t-shirts are avaiable, if you'd like to have one let me know, but in exchange you have be the evangelist that is needed in your area--otherwise you will have to wear the regular conference schwag you get at conferences and hackathons. ;-)
26 May 2015
I look at a lot of API documentation, something that until recently has been pretty static--pun intended. As an API consumer I really appreciate standardized approaches to documenting an API, like using Swagger or API Blueprint, but I also really enjoy when people go the extra mile to add little details, that make the experience a little more fun.
A recent example of this is from the Spotify API team. When it comes to the search endpoint for the Spotify API, they put in this little addition:
The field filter tag:new can be used in album searches to retrieve only albums released in the last two weeks. The field filter tag:hipster can be used in album searches to retrieve only albums with the lowest 10% popularity.
I love shit like this. It makes the often mundane world of APIs, a lttle more bright. It shows that there is a human beneath the very technical story that is often being told as part of API operatoins.
I don't about you, while I enjoy the self-service nature of APIs, where I don't have to deal with people and sales teams to be able to put a valuable resource to usee--I also enoy knowing there is a human behind the scenes. Especially if it someone who cares enough about an API enough to have fun, and enjoy themselves along the way.