Holger Reinhardt

Holger Reinhardt

Holger Reinhardt is a Product Architect & Business Developer at Layer 7. In this role, he explores opportunities related to IoT, M2M and Big Data for Layer 7. Holger has over 16 years of software development experience in Telecom and SOA appliances. Prior to joining Layer 7, he was part of the in-house incubator team at the office of the CTO of IBM WebSphere. He joined IBM through the DataPower acquisition.

July 16th, 2014

The Maker Manifesto

Written by
 

The Maker ManifestoOne of the few perks of having to travel for work is the opportunity to read books (remember those?), from cover to cover, in one go. I recently had the chance to read The Maker Manifesto by Mark Hatch, the CEO of TechShop. It is one of those rare books that make you want to jump up and start “making” something (which isn’t very practical when you happen to be on an airplane, I admit). But I will talk about this more in a minute.

I’ve been struggling lately with the overbearing Internet of Things (IoT) coverage and hype. All the ingenuity and potential seems to becoming increasingly directed towards creating yet another platform for advertising. Most if not all IoT presentations start out by citing the same one or two studies talking about billions of devices and trillions of dollars just beyond the horizon (I call it the x+1 syndrome – it is always one year out). This is usually followed by promises about how this or that gadget/protocol/framework/alliance is going to liberate us from our earthly burdens like switching off lights or turning on the coffee maker.

Of course, everything is open to debate but I personally prefer my simple wall-mounted light switch over having to pull out my smart phone and tap on an app.

In these challenging moments it is refreshing to remind myself what has drawn my interest to IoT in the first place. For me, the Internet of Things is simply a term describing a much deeper and more fundamental shift in society. And this shift – or rather the anticipation of this shift – is being called the “Internet of Things” in IT circles, the “Industrial Internet” by GE and the “Fourth Industrial Revolution” (aka “Industry 4.0”) in Germany. Meanwhile, The Economist and the previously-mentioned maker movement have been throwing around the term “artisan entrepreneur”.

The common theme across all of these manifestations is that technology is democratizing the way things are made. Maker-centric technologies like 3D printing could vastly increase the number of people who have direct access to the manufacturing process – which could be truly revolutionary.

To catch a glimpse of the future, look no further than Etsy, which has made a billion-dollar-plus business from selling individually-made crafts. And for what it’s worth, Etsy’s engineering blog is one of the finest – I love their mantra “Code as Craft”.

This brings me back to The Maker Manifesto. While Mark Hatch is coming at it from a maker perspective, someone could (and maybe should) have written a very similar book from a software perspective. Cloud IT, HTML5, Javascript, Node.js, Raspberry Pi, Arduino, GitHub – these are the tools for the coming “software maker” revolution. Both books would meet where our ability to create, to make is only limited by our imagination – and where individuals will be able to provide viable alternatives to industrial-scale production. It is my conviction that the Internet of Things describes the “place” where both software and hardware makers will meet. Having skills in both areas will become key to unlocking IoT’s potential.

It’s worth noting here that Hatch points to an emerging type of company that is built on software but reliant on a physical delivery platform. This is particularly prominent in the “sharing economy” created by companies like Uber, Airbnb and Getaround. It is a demonstration of how combining software with physical things like spare rooms and idle cars can be hugely disruptive to the way real-world products and services are delivered.

You might wonder where APIs are in all this. Well, just as cloud computing commoditized access to compute and storage resources, APIs are democratizing access to all manner of data and application functionality. Organizations across the private and public sectors are using APIs to open their information assets for use by external developers. In turn, these developers are creating apps that make previously siloed corporate information assets available to a vast number and variety of people.

As new hardware and software technologies combine with IoT and the good-old-fashioned physical world, APIs will be the glue that holds everything together. And – of course – API Management technology will be there to make sure it all happens securely and efficiently.

May 29th, 2014

Toward a Lean API Strategy

Books on Lean Business Strategy“Lean”, “API” and “IoT” are probably the most hyped terms in our industry right now. Normally, I tend to blog about the latter two but – for a change – I would like to balance that out by talking about the former: the concept of Lean and how it relates APIs.

You have probably heard about or even read The Lean Startup by Eric Ries. And you may have noticed that this book sparked a whole cottage industry of Lean publications, like Lean Analytics, Lean UX and the widely-misunderstood concept of “minimal viable product”.

But few of you may have ventured back to explore the texts that laid the foundation for the Lean startup. The Four Steps to the Epiphany by Steve Blank, for example. Blank outlines a business process called “customer development”, which helps startups find “problem solution” and “product market” fit. Even fewer will have ventured right back to the very origins of the Lean concept: the Toyota Lean Production System with its emphasis on pull over push and ever-decreasing batch size towards one-piece-flow manufacturing. And we have not even touched upon the “theory of disruptive innovation” that Clayton Christensen outlines in The Innovator’s Dilemma or Rita McGrath’s concept of “discovery-driven planning” outlined in Discovery Driven Growth.

But the purpose of this post is not to provide a comprehensive reading list for those of you hoping to learn more about Lean and discovery-driven business strategies. My real goal is to explore if and how these concepts can be applied to API design best practices. However, if you are curious and want to know more about the books mentioned, I suggest you head over to a blog post I wrote for launchd.io. And for your next long-haul flight, you might want to consider starting with The Goal, which will provide you with some truly novel-like business reading.

Before I explore how Lean and API design come together, let me first make a confession – I got an MBA a couple of years back. I know that this is not going to win me any brownie points and I still prefer code to spreadsheets – no contest! But it goes some way to explaining why I think business and API are joined at the hip. The business value of an API does not come from the interface’s intrinsic technical features but from its ability to provide access to a business asset or service. APIs provide a technical means to do (more) business.

From this follows the assumption that API design and implementation need to focus on the intended business outcome. Which means that you must have a clear view of your business goals before you can start to implement your strategy. Unfortunately – in my experience – most of us on the technical side are not equipped to talk to the business side of the house (and they are seldom well prepared to talk with us). This is why I went back and got an MBA – so that I could learn to speak with “them” and build better products.

Starting with Toyota’s lean product development process, I began to see approaches and tools that could help bridge the semantic gap between the technical and business sides. I plan to share some of these with you in subsequent posts. I will start by discussing Alexander Osterwalder’s Business Model Canvas. To get a little background on what I’ll be talking about in my next post, I suggest that you read this post on ProgrammableWeb, where Mark Boyd uses the Business Model Canvas to analyze Walgreens’ QuickPrints API. Also, you might want to take a look at my Lean API Strategy presentation from the recent APIdays in Berlin.

April 24th, 2014

SDKs Work Until They Don’t

SDKs and APIsOver the last couple of months, I’ve had many great opportunities to road test my findings on SDKs vs. APIs, with a wide variety of audiences – at our API Academy Summits in New York and London, on tour with the Nordic APIs team in Stockholm and Copenhagen and at my most recent API Workshop in Istanbul. Given the apparent relevance of the topic and the lively discussions I’ve had around it, I’d like to take this opportunity to summarize some of the insights and recommendations that have come up.

If you’ve been following our blog, you will remember that I started this topic with the observation that leveraging an API increasingly seems to involve using an SDK rather than the API itself. I followed up with a post talking about my decidedly mixed experiences of trying to use SDKs. My own experiences inspired the headline of this post: SDKs work until they don’t.

So, what are the main motivations to invest in an SDK, from an API-provider perspective?

  • Simplifying API design by extracting business logic into the client
  • Maximizing scalability by exploiting client-side processing
  • Empowering developers to leverage the API more quickly
  • Presenting an optimized client from a target-platform perspective (e.g. for mobile connectivity or constrained hardware)
  • Providing a strongly-typed presentation of the API in a variety of programming languages

Let’s contrast all this with the main drawbacks of SDKs:

  • Picking which platforms, languages and frameworks to support – some of your target developers are going to end up disappointed
  • Relying on third-party frameworks – any developer who has to integrate with two or more APIs leveraging the same framework at different version levels is bound to experience some headaches, for example
  • Adding carry-on weight of unused functionality to the application
  • Incurring long-term support costs for the SDK

But to me, the biggest risk of a SDK-first approach lies in making API design an afterthought. We have come to this point in the API evolution because pragmatic REST introduces just enough constraints to force us to think about how we can abstract the underlying business asset into a resource-based model restricted to CRUD-style interactions. An SDK-first approach might tempt us to go back to a RPC-style API design mirroring the backend implementation, resulting in all the inherent integration complexities we had with Web services.

So, if and when you decide on a SDK, keep the above in mind. You might still come to the conclusion that you need an SDK in order to quickly onboard developers or provide the best client for your API but at least you will be able to consciously weigh the benefits against the drawbacks.

If you want to dig more deeply into the subject, I can highly recommend the following podcasts, articles and blog posts, which helped greatly in forming my own opinions:

March 27th, 2014

SDK vs API – Round 2

SDK vs APIInspired by a conversation with Kin Lane and Mike Amundsen at last year’s APIdays conference in Paris, I decided to dig deeper into the SDK-vs-API debate.

As I wrote in my last post, I had noticed a pattern of using API SDKs rather than the underlying Web APIs. Let’s quickly define what I mean by SDK. There used to be a time, not so long ago, when “SDK” meant documentation, code samples, build scripts and libraries all bundled together. Today, you find all the former on the Web and usually only the library remains. When I use the term SDK, I mean a programmatic API (e.g. JS, Ruby, PHP, Python) on top of the Web API (usually REST/JSON).

As it happens, my wife gave me a small wearable activity monitor as a Christmas present (I could not possibly think of any reason why I would need that – and the new weight scale in the bathroom must have been pure coincidence). Since the gadget was uploading my stats to a cloud service and this cloud service had an API and my wife gave it to me as a present, I figured I had a perfect excuse to do some coding. My goal was to write a client-side app using JavaScript, pulling my stats from the cloud service via the API (and to keep notes on my experiences).

After registering at the developer portal, I hit my first stumbling block – no client-side JavaScript SDK. The closest I could find was a PHP SDK – which, of course, meant that I had to install PHP (I had not used PHP before) and the framework(s) used by the SDK. I also had to enable a Web server and debug the SDK’s OAuth implementation. That was not quite what I had in mind. Even though I got it running after one day and a half, I ended up being quite frustrated. All that work for a simple Web page displaying the stats for a hardcoded day!

So, I decided to take a different approach and use the SDK provided by Temboo. Again, no client-side Javascript SDK. While I could have used a Node.js SDK instead, I decided to stick with my PHP install and opted for the PHP SDK. From there, the integration was quick and I was up and running within an hour. What I did not like about the SDK was the footprint (it included all possible integrations) and how its abstraction and data presentation leaked into my application code. If I were to build a commercial product using it, I would have to consider the potential stickiness of the SDK. Personally, this did not feel right either. So, I went back to the drawing board and looked at my options.

What had I learned so far? My frame of reference going into the experiment was a client-side app using JavaScript. Yet the only SDKs I had found were written for server-side integration. Since it was the only choice offered to me, I had to invest a significant amount of time finding all the necessary information to get the server-side components and dependencies installed and configured. But even after going through all of this, the experience with either form of SDK left something to be desired.

I had started this exercise thinking that using an SDK was much easier than coding against the Web API – maybe it was time to reassess that assumption.

Looking back at the API documentation, I could not find anything inherently difficult. Looking at the vendor-provided PHP SDK, it dawned on me that the complexity of the client was entirely due to OAuth and the use of XML as payload. This finally gave me the opening I had been looking for. If I could avoid the complexities of OAuth on the client and use JSON as the payload format, I should be able to implement my client-side app with a few lines of JavaScript against the Web API. As a regular guest at Webshell‘s APIdays conference, I was familiar with the company’s OAuth Broker service. It took me a few minutes to get set up, configure the service and download their oauth.js client library. I cut and pasted the sample code into a JavaScript file, consulted the API docs to learn about switching to JSON format and did the API call. I was done in less than five lines of code!

While this experiment is just a single data point, I think it nicely illustrates some of the key lessons in the SDK-vs-API debate. I will attempt to provide a summary from both the API consumer and the API provider perspectives in my next post. I will also be talking about the SDK-vs-API issue in more detail during the upcoming Nordic APIs tour in Stockholm and Copenhagen and at the APIdays conference in Berlin.

January 31st, 2014

Would You Like a Library with That (API)?

LibraryIf you are professionally inclined – like I am – to read all about the business of APIs, you may have gotten the impression that APIs are going to take over everything and bring world peace.

Okay, I’m exaggerating but it is sometimes hard to remember that an API is really just a means to an end. That (business) end can vary. It might mean reaching more or different customers using mobile apps. It might mean integrating with partners. It might also mean giving access to services or data that provide enough value for them to be monetized. But in the end, I’m not using an API for the sake of using an API but because I want to use the services or data served by the API with the least amount of friction to myself because I – as a developer –  have a job to do.

Which brings me to my next point: When was the last time you looked at an API’s documentation and implemented it in a client app? If I need to integrate with an API in my Web app, I simply copy two lines of Javascript from the API provider page and cut and paste my API key into the <your_api_key_here> placeholder. Then I reload my Web app, which loads the Javascript library, which allows me to use the API. Or if I need to integrate with an API in the backend, I look for a pre-build component like a GEM (Ruby-on-Rails) or NPM (node.js) and add it to my loader file. Then I restart the backend, which loads the library, which allows me to use the API. Notice a pattern?

So here I am, using APIs via libraries/SDKs. In fact, I am not even sure when I last implemented a client using API documentation. In terms of priority, I only care if the service offered through the API meets my (business) needs – and then I use its library. And if it doesn’t have one, I might just move right along and look for the next one. (Remember: I have a job to do!)

For most developers out there in the real world, does consuming an API mean consuming an SDK that implements the API via a library? Should we talk about portable library design, efficient library loading (eager or lazy, async or sync) etc? Which platforms do I need to support to maximize my developer reach? What are the tradeoffs between offering (and having to support) a number of libraries versus just the API? Do dynamically-loaded libraries solve the API versioning challenge?

Reading about Evernote’s decision to use the Apache Thrift framework for its client API may help you formulate some potential answers to these questions.

In any case, none of this reduces the importance of providing a well-designed and documented API. Libraries and SDKs simply provide a convenient wrapper around an API and APIs are about removing friction. And client libraries are just another few steps in the march towards frictionless integration. (I still remember fondly the ease with which I was able to create client stubs and OSGI bundles from WSDL during the Web service days.) Nevertheless, we at Layer 7 – as an API Management company – will certainly be looking into how we can provide more support for client libraries in the future.

The preference for using client libraries rather than developing API clients becomes even more pronounced if we look at the Internet of Things.

Almost all the IoT integration vendors I have talked to consider supporting a large amount of client libraries for the myriad different IoT platforms to be one of their key differentiators in the market. Partly, this is driven by the need to optimize client stacks for resource-constrained platforms but it is also driven by the emergence of new binary and publish-subscribe protocols designed to better deal with IoT’s asynchronous communications patterns (see this blog post for a good overview).

While there has been quite some activity around API definition languages lately, I’m not aware of any attempt to provide a formal description language for asynchronous APIs of this type. Maybe this is an area where we will see some new ideas and innovation in the coming months.

In case you’re interested, I’ll be talking more about these trends as part of Layer 7’s upcoming API Academy Summits in London and New York.