February 27th, 2014

New API Academy Team Member: Irakli Nadareishvili

Irakli NadareishviliThe API Academy team has a new member: Irakli Nadareishvili who has joined CA Layer 7 as Director of API Strategy. Before joining CA, Irakli served as Director of Engineering for Digital Media at NPR, which is noted for its leadership in API-oriented platform design. He has also participated in the creation of the Public Media Platform, worked with whitehouse.gov and helped a number of major media companies develop publishing solutions using open source software.

I recently sat down with Irakli to discuss what he has in mind as he joins API Academy.

MM: You once told me that you believe the future of Big Data is “linked APIs”? That sounds intriguing. Tell me more about it.

IN: In most people’s minds, “Big Data” is synonymous to “very large data”. You may hear: “Google-large” or “Twitter-large” or “petabytes”. The Wikipedia definition of Big Data is slightly more elaborate:

“Big data is the term for a collection of data sets so large and complex that it becomes difficult to process using on-hand database management tools or traditional data processing applications”.

In my work, I see the “complex” part of the definition becoming more important than the size. We have gotten pretty good at taming the large sizes of data. Tooling for horizontal partitioning and parallel processing of large data sets is now abundant. Still, most Big Data sets are contained and processed in the isolation of single organizations. This is bound to change very soon. The end of siloed Big Data is near: I believe that the next phase of Big Data challenges will have to do with data sets that cross organizational boundaries.

APIs will play a major role in this. Web APIs represent the most effective available technology that allows data to cross organizational boundaries. APIs efficiently connect and link data at a distance.

MM: Can you give an example of what you mean by “data sets that cross organizational boundaries”? And what challenges do these pose?

IN: You see, a lot of people have the notion that the data they need to process can be stored in a database maintained by a single organization. This notion is increasingly inaccurate. More and more, organizations are having to deal with highly-distributed data sets.

This can be very challenging. The infamous healthcare.gov is a good example of such a distributed system. The main technical challenge of implementing healthcare.gov’s backend was that it had to integrate with data in many existing systems.

The $500 million initial public fiasco of healthcare.gov is also a vivid indication of just how complex it is to build truly distributed systems. Practically the only successful implementation of such a large, distributed information system is the World Wide Web. There’s a lot we can learn from the architecture of the Web. It’s a battle-tested blueprint for building distributed systems at scale.

I believe the Big Data challenges of the future will be solved at the intersection of APIs with Web/hypermedia architecture, linked data and what we currently call Big Data tooling. I call this intersection “Linked APIs”, to differentiate it from the current, siloed state of most Web APIs.

MM: What practical advice would you give to the developers of future Big Data APIs?

IN: I think the most important thing is that we need to stop falsely assuming all of the API data is local data. It is not. Despite the name, an API for a distributed system is really not a “programming interface” to local data/assets. Rather, it is a programmable data index. Think of APIs as a programmable search index for a distributed collection of data sets.

I don’t like to think of the term “API” as an abbreviation anymore. Maybe it was one a while ago but it has since evolved way past that. Much like IBM doesn’t think of itself as “International Business Machines” anymore, APIs aren’t merely “application programming interfaces”. Most of what IBM does these days isn’t even necessarily about “machines”. Likewise, most of what we need out of APIs isn’t about any single application or an interface to it.

MM: Big Data represents one important challenge for computing today. What about IoT?

NN: The Internet of Things is already here, in small ways. The IoT we have today consists of a vast number of Web-connected devices, acting as sensors, sending myriads of signals to the cloud. That, by the way, is what creates many Big Data challenges. The future is much more interesting, however. Once the connected devices start engaging in peer-to-peer interactions, bypassing central authority, we will enter a significantly different realm. The most important challenge in that world, from my perspective, will be identity. Identity is always key in distributed systems but especially so in peer-to-peer networks.

MM: What excites you the most about your new role at Layer 7?

IN: Thank you for asking this question. I will start by telling you what terrifies me the most. The API Academy and Layer 7 teams represent a gathering of  ”scary” amounts of world-class brainpower and expertise in the API space. It is extremely humbling to be part of such a distinguished group.

Obviously, it also means that there is a lot of very fundamental thinking and innovation that happens here. Especially now that Layer 7 is part of CA Technologies, there’s really very little that we couldn’t accomplish if we put our hearts to it. That feels extremely empowering. I really care about all things related to APIs and distributed systems, the role they can play for the future of technology. I am super excited about the possibilities that lie ahead of us.

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.

December 2nd, 2013

How I Lost Weight & Learned About APIs

How I Lost Weight with APIsTrying to stay in shape is one of those never-ending life battles that I’ve come to expect as I get older. I’ve bounced between being a healthy shape and a not-so-healthy one for years and I’ve managed to live life just outside the edge of ideal fitness. A few months back, I reached an apex point and dedicated myself to losing a few pounds (again) and set off on a journey to change my life (yet again). Little did I know I’d learn something about APIs along the way.

Everyone has their own way of losing weight but I’ve always preferred a measurable, rationalist approach: I count the calories I consume, I subtract the calories I burn and I budget accordingly. The nice thing is that this method forces me to think about what I’m consuming and what I’m doing. The massive downside is that keeping track of all of the data is a monotonous and soul-destroying effort that often leads to me giving up.

Of course, there is an app for everything now and I started using  a tool to keep a log of foods that I ate along with their associated caloric burdens. One problem with this type of tool is that, while it’s easy to log consumption of food using features like bar code scanners and crowd-based data, the process of logging exercise and calorie expenditure is entirely manual. This can make fitness goals harder to achieve as users like me end up either under or over estimating their daily calorie burn.

Thankfully, devices to monitor your physical exertion do exist and they are reasonably affordable. These are wearable devices that provide a tally of steps taken, stairs climbed and physical exertion throughout the day, providing a wealth of personal data to mine. To be honest, I’d always viewed these devices in the same category as things like Google Glass – really cool pieces of technology that bleeding-edge enthusiasts wear publicly at the cost of their own dignity. But something changed for me when I realized that I’d be able to connect the calorie-counting app I was using with the wearable fitness device. So, I made a purchase.

By connecting the food-tracking application with the activity-tracking device, I was able to get a much more accurate picture of my caloric budget for the day. The systems integrated remarkably well and the quantification of remaining calories along with a few gamification features provided extra incentive for me to keep moving and eat less.

In the end, this behavioral conditioning of triggers, alerts and feedback loops worked well for me and I was able to drop a few pounds. Of course, I lost the tracker on an airplane about a month in and I’m currently racing back towards a pear shape but that isn’t the point. What is more interesting is what we can learn about integration from my journey:

1.  An API is a Great Way to Extend Customer Reach to Platforms
When we think about building APIs, we usually think about extending out to mobile devices or social platforms. But organizations should consider how their products can be extended to niche and non-traditional platforms that their target user base actively uses. If the wearable tracker I purchased didn’t work with the calorie-counting application I was already using, I never would have considered buying the tracker in the first place. But thanks to the API-based integration, I could visualize myself using it and this was the trigger that resulted in a purchase decision.

2.  Integration is Becoming a Core Requirement Instead of a Feature
Something I noticed when scanning the forums on the tracker device’s Web site was the number of posts related to integration with other exercise platforms. For this user base, integration with their favourite run-tracking, calorie-counting or fitness-gamification tools isn’t just a nice-to-have – it is the minimum expectation. It seems that end users are increasingly expecting product vendors to support their platforms of choice and want the freedom to make their own decisions. In other words,  users don’t want to be punished for choosing a less popular tracking tool or a mobile phone operating system that has less market share.

3.  Integration with Potential Competitors can Pay Off
What I didn’t mention in my story was that the fitness tracker I purchased did come with a calorie-consumption-tracking feature. In fact, part of the revenue stream for this product is the sale of subscriptions to the manufacturer’s fitness portal, as part of an end-to-end fitness management program. This means that supporting out-of-the box integration with other fitness trackers actually comes at a potential revenue cost for the tracker vendor. But I would imagine that the overall revenue benefit from attracting customers like myself outweighs the revenue lost from users who choose not to subscribe to the portal. Integrating with competitive products can be a risky proposition but a smart gamble can really pay off.

As interest in the Internet of Things (IoT) continues to increase, I expect to see an increasing variety of interesting device-to-platform integration stories. Businesses will need to have coherent business strategies for extending to this new world, with APIs as an important supporting action.

Also, if you happen to see me in person, don’t forget to tell me how great I’m looking nowadays.

November 29th, 2013

Ending the IoT Protocol Wars

Ending the IoT Protocol WarsIt’s been a while since my last blog post – not least because I have been traveling quite a bit to run Layer 7’s European API workshops together with my colleague Ronnie Mitra. The workshops (part of Layer7′s outreach program via the apiacademy.co) are vendor-neutral and focused on sharing API design and management best practices.

To be honest, I probably learn as much during these workshops as the participants do. It has certainly been striking to watch how our material evolves throughout the workshops. We constantly keep adding and tweaking material, based on what we learn. In particular, I’m struck by the amount of changes my IoT section has been going through.

Here is what I have learned regarding IoT protocols: It’s a zoo out there, with lots of protocols trying to become the next HTTP. And some candidates deploy a formidable array of marketing, making it exceedingly hard to cut through the fog.

My current shortlist of main contenders is (in alphabetical order):

I might add STOMP to that list, just for its simple brilliance. STOMP is a text-based messaging protocol that has recently been extended to allow for binary content. Additionally, I’ve recently started talking with some transportation companies and learning about their use of DDS, which might be another candidate for the shortlist.

In the corner of residing champion, we have JSON/HTTP. Not content to see this protocol pushed into early retirement, advocates have been developing some very interesting approaches that attempt to ensure the continuing relevance of HTTP for asynchronous small messages – WebSocket being the most well-known. Hypercat, Simple Thing Protocol and EventedAPI represent just a small sample of the interesting approaches emerging to support async eventing and messaging with HTTP.

Where does this leave a developer trying to choose the right protocol for that awesome winged steam punk toaster? I don’t really have the answer but there are some documents trying to tease out the differences. Take a look at the MQTT vs. CoAP comparison from 1248.io or the DDS/AMQP/MQTT/JMS/REST comparison from DDS champion PrismTech.

Based on what I’ve learned so far, only XMPP and DDS have significant commercial deployments while MQTT is being evaluated by almost every major vendor I have talked to. While MQTT’s use as the protocol powering Facebook’s messenger is a good demonstration of its scalability, I don’t think this constitutes a proof point for mission-critical commercial deployments. If you know of commercial deployments of MQTT, I’d love to hear about them.

Each protocol has weaknesses: MQTT appears to be weak in security; DDS seems to be complex to scale and has version dependencies; XMPP is considered heavy-weight. But they all have strengths too, of course: DDS has the deployments in the field to prove its relevance; XMPP supports EXI and WebSocket for efficiency and a proven track record; both DDS and XMPP are extremely mature and have built-in security. Given the industry interest in MQTT, I am sure that whatever security problems exist will be fixed in one of the next versions. The one puzzling piece is the absence of CoAP in a commercial deployment. Again, if you know of one, please let me know.

Where do I stand on all of this? Having watched technologies rise and fall, I think it’s very normal at this stage to have multiple contenders trying to improve on HTTP. What I try to keep in mind though is that both bandwidth and computing power seem to be on an ever-increasing trajectory, while at the same time becoming cheaper and cheaper. Reduction in power consumption and increase in battery capacity, mostly driven through mobile, further lowers the bar for mainstream technology to power even small devices. I would not be surprised if, after the initial phase, we continue to see HTTP and JSON being dominant. As geeks, we sometimes get too excited about efficiency gains while losing sight of the fact that, for most products, technology simply needs to be good enough. But I won’t complain if I am proven wrong this time.

And don’t just take my word for any of this. To help you learn more, here are a couple of other articles reviewing IoT protocols:

November 5th, 2013

Thoughts on Trends in IoT & Mobile Security

Written by
 

IoT and Mobile SecurityRecently, I read an article about predicted growth in the Internet of Things (IoT). Extrapolating a previous estimation from Cisco, Morgan Stanley is predicting there will be 75 billion connected devices by 2020. This sort of math exercise is entertaining and has a real “wow” factor but the real question here is: What does this mean for consumers and enterprises?

In recent years, consumer electronics manufactures have started to see the usefulness of building Internet connectivity into their appliances. This enables the post-sales delivery of service upgrades and enhanced features. It also allows mobile apps to control home appliances remotely. This is nothing radical per se, a decade ago I observed a sauna in the Nokia Research Center’s lab being controlled by voice and WML. But this was still a simple one-off integration. As the number of device form factors increases, the complexity of integrating devices grows. The term “anytime, anywhere computing” is usually used to describe this scenario but it isn’t entirely adequate. As a consumer I don’t only want device-independent access to a service – I want the various devices and appliances to work with each other so that smarter interactions can be achieved.

Today, we already see a plethora of connected devices with more-or-less crude connectivity and integration options. Smartphones can sync and connect with tablets, TVs and laptops. Mostly, these are very basic integrations, such as your various devices “knowing” about the last page you read in an eBook, regardless of which device you used. But the number and complexity of these integrations will increase greatly in the coming years.

The Coming Age of Connectivity
One of the main reasons the iPhone revolutionized mobile computing was Apple’s focus on user experience. Since then, mobile vendors have battled to see who could provide the best experience within the device. The next battle will be over cross-device experiences within the broader ecosystem, as users roam from device to device. And in the battle, the big players will keep adding their own proprietary components (software and hardware). The sheer size of these ecosystems will make the opportunity large enough to attract even more mindshare. If you make money – who cares about proprietary protocols and connectors?

But how does this relate to IoT, you may ask – isn’t this just a subset of IoT’s promise? The answer is “yes” but that is how this revolution will work – closer to an evolution where the consumer-driven use cases will be implemented first. Yes, there are other enterprise use cases and we can see many protocols and frameworks that claim to address these requirements. In the end though, I believe most of these platforms will struggle with developer uptake as most of the developer mindshare is found in the big mobile ecosystems. As with mobile, the successful approaches will be the platforms that can offer developers familiar tools and a roadmap to revenue.

It’s clear the big players in mobile, like Samsung and Apple, see a huge opportunity in connected devices. As we move on, we will see more devices get included in each of the mobile ecosystems’ spheres. Increased integration between mobile devices and cars is already in the works. Similarly, among the many notable events at last week’s Samsung DevCon (an excellent show, by the way), several SDKs were launched with the aim of solving specific consumer needs around media consumption in the home. But the impact of increasing connectivity will go beyond these relatively well-understood use cases to encompass home automation, smart grid, healthcare and much more.

Alternative Authentication Methods for the Connected World
In this multi-device, multi-service world, conventional username/password login methods will not be convenient. Advances in the biometric space (such as Nymi or Apple Touch ID) will be relevant here. I suspect that, just as we have seen a bring-your-own-device trend grow in enterprise mobile, we will see a bring-your-own-authentication paradigm develop. As a larger set of authentication methods develops in the consumer space, enterprise IT systems will need to support these methods and often be required to adopt a multi-layered approach.

Ensuring Big Data Privacy in the Age of IoT
Another set of challenges will be created by the enormous amounts of data generated by IoT. Increasingly, connected devices are able to collect and transmit contextual data on users. This information can be highly useful for vendors and users alike. But what happens if data is used for purposes other than those first intended or agreed to? Who owns the raw data and the generated insights? And how is the rightful owner in control of this? Today, there is no general standard available nor are the mobile ecosystems providing adequate privacy protection. Sometimes one gets the feeling that users don’t care but they will probably start caring if and when data leakage starts to make an impact on their wallets.

Meanwhile, Layer 7 will continue to innovate and work on solutions that address the challenges created by IoT, multi-device authentication and Big Data. Oh and by the way, I believe Morgan Stanley underestimated the number, I think it will be double that. You heard it here first…