August 17th, 2012

Building a Developer Ecosystem: Live Tech Talk, August 21 – 9am PDT | 12pm EDT

Alex Gaber Tech TalkOnce again, it’s time to get ready for Tech Talk Tuesday here at Layer 7. I’m getting excited about this latest one – Building a Developer Ecosystem – for a couple of reasons.

Firstly, I’m excited to be working with our new API Evangelist, Alex Gaber. He has a wealth of experience working with developer communities and he’s ready to answer questions and discuss strategies around developer community building. When it comes to this sort of thing,  Alex is the man. In fact, this weekend he’s onsite at Hack Denver, helping API publishers with their open APIs.

Secondly, I think it’s going to be a great chance for our API publishing audience to learn some really valuable lessons that may help them develop new business partnerships and revenue streams. And we’ll ride the momentum of our last Tech Talk, which had great attendance and – most importantly – excellent contributions from the audience.

Our aim with these Tech Talks is to create an informal channel for engaging with API experts in a live, interactive way. With that in mind, start thinking about any questions you might want to ask Alex, be sure to add Building a Developer Ecosystem to your calendar and join us on August 21 for another great Tech Talk.

On the day of the event, join on Livestream or Facebook:
»  livestream.com/layer7live
»  facebook.com/layer7

Tech Talk Tuesday: Building a Developer Ecosystem
Tuesday, August 21
9am PDT | 12pm EDT | 5pm BST

Submit your questions:
Tweet using the tag #Layer7Live
Email techtalk@layer7.com
Check-in & Chat through Facebook

July 26th, 2012

Programming in the Cloud

CloudDevelop LogoQuite a bit has been written about how the Cloud is altering the landscape for platform, software and infrastructure providers but not as much has been said about what all this means for developers. I recently decided to find out for myself by going on an “all-cloud diet”. In practical terms, this meant I used a sealed netbook or smartphone to do all my work.

Therefore, I had to do all the things an active developer regularly has to do (coding, debugging, testing etc.) from a device that has no appreciable hard-drive space and does not allow the installation of any customer software. In essence, I was on a strict diet of browser-based and plug-in based tools and services reachable via an Internet connection.

In relatively short order I was able to find browser-based editors (even ones that support line-by-line server-side debugging!), tools for managing data stores and code repositories. Furthermore, I was able to post test scripts for execution/review and even deploy my projects to a wide range of server providers – all from my browser.

Along the way, I discovered that I had an easier time collaborating online with colleagues in other locations and was better able to take advantage of the most recent releases of new services and tools (since there was no “install” or “update” I had to manage). And – of course – I was more mobile in the process.

Not all programming languages, runtime environments and server profiles are represented in the cloud. And there are still many details to work out in order to make assembling a full-featured “cloud tool chain” easy, reliable and cost effective. Nevertheless, I can see that it is a possibility and I have met people who are working to make that possibility a reality.

My advice to developers would be: Conduct your own experiments; try out your own “cloud-only diet” and see what you learn. Even if you decide that not all the pieces you need are available, you may still discover there are ways to leverage cloud-based tooling to reduce barriers, add flexibility and increase productivity in various aspects of your development efforts.

I’ll be exploring these issues in greater depth when I present a talk titled Programming with the OSS “Cloud Stack” at the CloudDevelop show in Columbus, OH on August 3.

July 19th, 2012

Hypermedia APIs – Tech Talk Tuesday July 24 Featuring Mike Amundsen

Mike Amundsen Tech TalkOur recent Tech Talk discussing OpenID Connect was great. We had some pre-questions sent in via email, lots of live questions through the stream and some great questions through our twitter hashtag #Layer7Live.  We’re going to pick up on the momentum of that last Tech Talk and continue on with our next interactive API-focused discussion on July 24 at 9am PDT.

We’re very excited to be welcoming Mike Amundsen, Layer 7′s Principal API Architect, back to the Tech Talk studio. He’s ready to take on questions and discuss hypermedia APIs, a subject he literally wrote the book on.

  • What makes a hypermedia API different from other API types?
  • How is designing one different from designing any other form of API?
  • What are the benefits or complications for the publisher and the developer?

These are just a few of the questions that arise when thinking about designing hypermedia APIs. Now’s the time to get your thinking caps on and start formulating the questions you want to ask Mike on his specialist subject.

Make sure you click Add to Calendar to get the full event details and a reminder on the day.

On the day of the event, join on Livestream or Facebook:
»  livestream.com/layer7live
»  facebook.com/layer7

Submit your questions:

July 17th, 2012

Developer Management & the Layer 7 API Portal 2.1

Layer 7 API Portal Version 2.1As Layer 7’s CTO, Scott Morrison, recently stated: API Management = Developer Management. Okay, there are actually many elements to API Management – securing APIs, enforcing rate limits and SLAs, translating protocols and so forth. But if developers can’t make use of your APIs, then your APIs aren’t going to do you much good. So, providing a place where developers can discover, register for, learn about and leverage your APIs is – in many ways – the key to a truly effective API Management strategy.

That’s why the Layer 7 API Portal – which is designed to help organizations onboard, educate and manage developers – is one of the cornerstones of our API Management Suite.

The world of Web, mobile and cloud API publishing is growing and changing at an incredible rate right now, so we’re constantly working hard to expand and refine our line of API-focused products. With all that in mind – and hot on the heels of our SecureSpan Mobile Access Gateway – we’re very excited to announce version 2.1 of the Portal.

With the developer management needs of API publishers constantly evolving, we’ve added a range of new functionality to the Portal, including:

  • Advanced analytic reports
  • More granular privacy controls
  • Enhanced lifecycle management features
  • New customization options for the content management system

We’re exhibiting at Mobile+Web DevCon in San Francisco this week. If you’re at the show and you’d like to learn more about this new API Portal release, please stop by our booth.

July 10th, 2012

Hey Twitter: API Management = Developer Management

Twitter APIQuick question for you: What matters most, the client or the server?

Answer: Neither —  they are really only useful as a whole. A client without a server is usually little more than an non-functional wire frame and a server without a client is simply unrealized potential. Bring them together though and you have something of lasting value. So, neither matters more and each actually matters a lot less than half.

In the API world, this is an easy point to miss. The server side always wields disproportionate power by virtue of controlling the API to its services and this can easily foster an arrogance about the server’s place in the world. This effect is nicely illustrated by Twitter’s recent missteps around developer management.

The problems for Twitter all began with a blog entry. Blogs are the mouthpiece of the platform. Tucked away within an interesting entry about Twitter Cards and the potential to run applications within tweets (something that is genuinely exciting), can be found a restatement of an early warning to developers:

“(D)evelopers should not ‘build client apps that mimic or reproduce the mainstream Twitter consumer client experience.’”

Ominous stuff indeed. This was quickly picked up on by Nick Bilton writing in the New York Times Bits blog, who pointed out that the real problem is that Twitter just isn’t very good at writing client-side apps that leverage its own API. Stifling competition by leveraging the API power card can only alienate developers — and by extension the public, who are left with a single vendor solution. Suddenly, it feels like the 1980s all over again.

This ignited a firestorm of concern that was well summarized by Adam Green on ProgrammableWeb. Green acknowledged that API change is inevitable but pointed out that this is something that can be managed effectively — which is not what Twitter is doing right now.

The irony of the whole thing is that, in the past, by exercising its power position, Twitter has actually made great contributions to the API community. In mid 2010, Twitter cut off basic authentication to APIs in favor of OAuth, a drop-dead event that became known as the OAuthcalypse. Hyperbole aside, in terms of actual impact on the populace, this cut over made even Y2K look like the end of days. Given a tractable challenge, developers cope, which is really Green’s point.

What is important to realize is that API Management isn’t technical but social. Win the community over and they will move mountains. Piss them off and they will leave in droves for the next paying gig.

The thing I always remind people is that as a trend, APIs are not about technology; they are a strategy. Truth is, the technology is pretty easy — and that’s the real secret to API’s success. You see, the communications are never the thing; the app is the thing (and that is what WS-* missed). Maintaining simplicity and a low barrier to entry counts for everything because it means you can get on with building real apps.

Now, I can give you the very best infrastructure and tools to facilitate API community. But how you manage this community… Well, that is where the real work begins and — in the end — it’s all a lot less deterministic than we technologists like to admit. People are hard to manage but communities are even harder.

If there is a lesson here, it is that APIs are really about potential and that potential can only be realized when you have two sides — client and server — fully engaged. Mess this one up and you’re left with just a bunch of unused interfaces.