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.

January 30th, 2014

API Academy Summits

API Academy SummitsLast year, Mike Amundsen, Holger Reinhardt and I each traipsed around the world to bring API architecture guidance and advice to your home towns.  It was a lot of fun, we got to meet some great people and we had a chance to learn about the challenges that front-line API designers face. We also managed to earn a lot of air miles and give away a lot of t-shirts.

But this year, we wanted to top ourselves and do something bigger and bolder. So, instead of going out individually, Mike, Holger and I are getting together to dish out practical API design advice together in a series of API Academy Summits. I’m really excited about these events because we’ll have a chance to provide differing points of view and draw on our collective expertise to give you the best guidance possible. Our goal this year is to continue to go beyond the inspirational hype about why your business needs an API and go deeper, addressing the real challenges that people who actually have to implement API programs face in the real world.

In addition to the API Academy team, we are extremely pleased to have Forrester Research analyst Randy Heffner providing a keynote presentation. Randy has been a great source of API design information over the last year and if you’ve been reading his work, you’ll know he is all about providing great practical advice to API designers.

Our first Summit is taking place in London on February 6, closely followed by an event in New York city on February 13. These full-day events will include real API implementation stories from William Hill and L’Oreal as well as providing a mobile developer’s view of API design, courtesy of local London developer Niall Roche.

Last year, we were surprised to hear from API Academy workshop attendees that they wanted us to talk about Layer 7′s products. We want these to be vendor-neutral events but we’ve listened to the feedback and are trialing a short session introducing the Layer 7 API Gateway and Portal.  This session will be held at the end of the day and we promise not to lock the doors and force you to listen to the pitch!

So, if you have a chance to be in London on February 6 or New York on February 13, make sure you find time to join us for one of our API Academy Summits!

January 8th, 2014

APIs Past, Present & Future – API Predictions 2014

2014 Predictions Tech TalkThe beginning of a new year is a great time to reflect back on the year that was and look ahead to the year that will be. Because 2013 was such an impressive year for API technology, I thought now would be a great time to assemble a panel of API experts and talk about The Past, Present & Future of APIs.

This will be our first API Tech Talk of 2014 and it’ll be a great chance for our audience to interact with the panel, ask questions, make comments and ultimately learn and think about the future of APIs.

At Layer 7, we’re proud to have thought leaders and top industry talent when it comes to API design, API security, the API economy and IoT. On the panel will be members of our API Academy: VP Client Services Matt McLarty; Principal API Architect, North America Mike Amundsen; Principal API Architect, Europe Ronnie Mitra; Product Architect Holger Reinhardt; Chief Architect Francois Lascelles. They will be joined by Layer 7′s Director of Product Management, Ross Garret.

So, we’ve brought together experts from a design/usability perspective, a business perspective, an integration perspective and – of course – an API security and management perspective.

Our customers – and enterprises in general – realize they can transform their businesses through APIs by leveraging their digital assets and taking advantage of all-pervasive trends like mobile, BYOD and IoT. Mobile apps are an integral part of daily life for most of us and smartphone use has become commonplace in the enterprise.  Mobile app developers need APIs to build the exciting applications we all love to use. And as the recent Snapchat security breach teaches us, security is a very important – but sometimes undervalued – aspect of API architecture.

APIs are driving the future of business and there are a lot of considerations when talking about API Management. The API itself needs to be designed well, the security needs to be tight to protect user data, it needs to be developer-friendly and on we go.

While  2013 may very well have been the year of the API, 2014 could be the year APIs go mainstream. So, join us on January 15 at 9am Pacific Time for a live discussion of The Past, Present & Future of APIs. You can tweet your questions or comments directly to @layer7 or you can use the #layer7live hashtag. You can also email your questions directly to us (techtalk@layer7tech.com).

I’m really looking forward to hosting this discussion and think you’ll get a great deal out of the discussion. We value your input and look forward to hearing from you on Jan 15.

December 23rd, 2013

Thanks to All Who’ve Been Good This Year

Layer 7 Holiday Promo 2013The year 2013 has been one heck of an adventure for me. My work with Layer 7, CA Technologies and the API Academy team (yes, we have many names!) has taken me around the world, allowed me to speak at several amazing conferences and provided the chance to interact with some remarkable organizations working on APIs for the Web and enterprise. Along the way, I’ve met many incredibly smart and generous people.

In the last year, I’ve worked with organizations striving to reinvent the role of the enterprise architect from a controlling force to an enabler – a person who ensures the development environment is a safe place to be creative; a person who provides help to product groups and development teams via research and guidance taken from a wide range of sources; someone who works to empower teams and cut down on unneeded ceremony and red tape. These are good people and they’ve been a pleasure to work with and learn from along the way.

I’ve also met many conference organizers and community leaders doing essentially the same thing from a different angle. Along the way, I’ve met people who are devoting huge chunks of time, effort and resources to creating events that improve communication, facilitate collaboration and foster success across a range of communities. It’s been really amazing to be a part of these events and to meet so many giving and open people working toward a common goal.

My experience online has been equally enlightening. In the last year, I’ve “met” many new and interesting people, discovered several helpful efforts and organizations. I am lucky that I can learn something new every day online from those I’d likely never meet in person, simply because we are physically far apart.

One experience in particular has marked 2013 for me. I had the honor to work closely with Leonard Richardson on a book project – RESTful Web APIs. It was Leonard’s idea to create the book and I was happy he invited me to help shape the message and content. I’ve learned a great deal from him and I can see the results of that work in online comments and reviews. I am pleased to be associated with Leonard’s talent and vision.

There’s a common thread through all these experiences: I’ve had the luck and privilege of meeting many “good” people this year. This blog post is my way to give a blanket shout out to everyone who challenged me, taught me, invited me, supported me and hosted me in so many ways in the last year. Thanks!

As another small way of saying thanks, we’re offering several free copies of the RESTful Web APIs book to some of those who’ve been “good” this year. All you need to do is add yourself to our “nice list” (go ahead, you know you deserve it). We’ll be giving away a couple dozen copies of the book soon after the holidays.

So, again, thanks to all for your help and support in 2013. And look out for us in 2014 – things are just getting started!