January 28th, 2013

Growing Your APIs in the Amazon Cloud

Amazon Tech TalkPutting applications in the cloud can reduce overall IT costs and deliver greater scalability. Cost considerations are always a concern in IT infrastructures but scalability may be the most important benefit of hosting applications in the cloud. Leveraging the elasticity of Amazon’s cloud infrastructure can allow you to scale your APIs to match market demand. Amazon Web Services provides tooling that can help you be quicker to market with your APIs.

But do interfaces hosted on AWS and exposed to third-party developers contain significant vulnerabilities? Cloud services allow third-party access to applications and data through APIs. Failing to properly secure that access can put the data and applications at risk. So, how do you safely expose APIs in a cloud environment?

Understanding the cloud API model isn’t always easy. So, on January 29, we’re having a live discussion about publishing APIs in the AWS cloud, which may help answer questions surrounding exposing APIs in cloud environments. I’m excited to welcome Layer 7 Technologies Senior Software Developer Hirbod (Rod) Moshfeghi as our special guest for this API Tech Talk. This is a great opportunity to have your questions answered and to discuss the implications of publishing cloud-based APIs.

Here’s how to join the live discussion…

On the day of the event, click here to join:

Submit your questions:

January 28th, 2013

Four Tech-Related Trends That Will Shape 2013

Written by
Category Apps, Mobile Access
 

Mike Amundsen 2013 PredictionsLooking ahead, here are four tech-related trends that I think will shape the coming year. These are trends I noticed were already in flight during late 2012. I believe they will continue to affect the way we design and implement solutions in 2013.

As you’ll see, all of my predictions are driven by the relentless increase of connected mobile devices. This is the dominating overall trend that will continue to affect all aspects of information systems.

In a nutshell, I predict:

  • Individual service deployments on the Web will get smaller and more numerous
  • Mobile client deployment will be a bottleneck
  • Server mash-ups will increase but client mash-ups will decline
  • The demand for seamless switching between personal devices will increase

Services on the Web Get Smaller, More Numerous
Influenced by the existence of the many mobile apps running on a single device, Web-based services will become small, single-focused offerings that (in the words of Doug Mcllroy) “do one thing and do it well.” This will also explode the number of available services. The advantage of this trend will be an increase in the agility and evolvability of service offerings. The challenge will be an increased need for governance at the “micro-service” level.

Mobile Client Deployment Becomes a Bottleneck
As more services appear on the Web and more mobile devices spread throughout the world, keeping up with mobile app deployment will become more difficult and more costly. This is especially true for cases where an app store requires approval before release. To mitigate this problem, developers and architects will look for new ways to update and modify the functionality of already-installed mobile apps without the need for full-on redeployment. Solutions will include use of in-message hypermedia designs, reliance on remote discovery documents and just-in-time plug-in style implementations.

Server-Side Mash-Ups Increase while Client-Side Mash-Ups Decline
The increasing popularity of languages like Node.js, Erlang and Closure will make implementing server-side mash-ups more efficient and easier to maintain than doing the same work within a client application; especially for the mobile platform. This will reduce the “chattiness” of client-side applications and increase the security and flexibility of server-side implementations. The result will be a perceived increase in responsiveness and a reduced use of battery power on mobile apps.

Multiple Device Form Factors Will Demand Seamless Sharing
As more users access content on multiple devices, there will be an increased need to design apps that seamlessly share user data across these devices. This will affect the both client- and server-side implementation details. Identity will need to cross devices easily and content syncing will need to be seamless and automatic. App builders will rely more on the “responsive design” pattern in order to automatically adjust displays and functionality to meet the needs of the current form factor. Servers will need to be “context-aware” and provide the most up-to-date content while users switch from one device to the next.

Finally, whether my predictions are spot on or way off, I look forward to a very interesting and challenging 2013.

January 25th, 2013

Considerations for Private APIs

Written by
 

Considerations for Private APIsIn the past, we’ve talked about the nature of private APIs (those interfaces that are built primarily to serve an organization’s own projects rather than to fulfill the needs of others).  But what are the specific challenges and architectural decisions that need to be made when implementing a private API?

First and foremost, an API can’t be considered private if it is open for widespread public use, right?  A simple way of keeping an API private is to host the interface on a public network without explicitly advertising or documenting its existence.  This can work well initially but may lead to problems in the future. If your service is valuable enough that others want to get their hands on it, even an undocumented, unsupported, private API can easily end up becoming a depended-upon API for application developers, resulting in an outcry when the API publisher has the audacity to modify or retire its own service.

A better approach is to provide access control at run-time and restrict usage of your API to a few known parties. There are a great number of methods for protecting access to internal resources but the best ones are those that achieve a balance between ease of implementation and resistance to infiltration. Security at all costs can greatly increase the complexity of an interface and – in turn – the time required to complete the projects that depend on it. Instead, we need to implement access control that is practical. Thankfully, security protocols like SSL, HTTP Basic authentication and OAuth 2 are great for providing the basic level of access control needed to make it difficult for outsiders to use a private API. Bear in mind that there is much more to API security than simply validating identity but this is the minimum level needed to ensure a degree of privacy.

Although a private API’s developers are generally known to the publisher, the best private APIs utilize API portal components to provide self-service registrations and integration to their private developer communities. This can greatly reduce the friction involved in getting API integration-based projects started and reduce the overall project costs for B2B and mobile-based initiatives. In fact, many of the lessons of simplified design, documentation and administration learned from the public API world can be directly applied to private API management. While the ultimate goal may be different (driving efficient API usage for private APIs rather than far-reaching adoption of open APIs), the ways of getting there are largely the same.

A unique characteristic of private APIs is the need to manage groups of developers. Unlike the public API space, private API publishers will often define out of band contract terms before offering up a quick self-service integration mechanism for that team. This type of group-based role definition is particularly common in integration projects that occur between organizations and can stretch the limits of API portal software that has been built primarily for open API use. Ideally, an API portal should at least be capable of managing developers within groups, communities or organizational affiliations as part of the self-service registration process. Even better, the portal could  provide capabilities for managing whole communities as separate domains within the same infrastructure.

Designing a private API certainly requires a different perspective but the good news is that much of the knowledge around public API design can be directly applied to interfaces you want to keep secret. Of course, building the management and security capabilities required to expose the API to your trusted parties can be daunting but that is why a great API management portal and gateway combination can save the day.

 

January 17th, 2013

Layer 7 Hackathons: 2012 Round-Up & 2013 Plans

Las Vegas HackathonTo follow-up on my previous post about Layer 7’s hackathon activities, I wanted to provide an update on more events we’ve been involved with, as well as mentioning some of the exciting things we have planned for 2013.

Las Vegas Mobile App Hackathon (November 16-17)
The local developer community is thriving in Sin City, which may be a surprise to many. I was very impressed with the talent of the developers in Vegas, most of whom were writing native Objective C or Java for their iOS and Android apps. Also, the local PhoneGap user group manager was onsite, providing support for Adobe’s app development framework. The apps produced were quite polished and impressive. Several included API integrations while others came with plans for future Web integration of APIs, to add context and information.

Miami Mobile App Hackathon (December 14-15)
This hackathon brought an impressive group of sponsors together including AT&T, Microsoft Azure, Blackberry Dev, GitHub and – of course – Layer 7. With over 200 signups and some highly technical evangelists sent by the sponsors, I was excited to see what kinds of apps would be produced. The developers mashed together numerous Web services using native code or PhoneGap. It was great to see the local developer community come together, with numerous local start-up incubator leaders onsite scouting for new talent and investment opportunities.

For 2013, Layer 7 will once again be joining the AT&T Hackathon team for several events. Many organizations with APIs powered by Layer 7 will be promoting their APIs and providing prizes at these events. Stay tuned – we’ll be helping evangelize a lot of great APIs in 2013!

Find out more about upcoming Layer 7 Hackathons

January 10th, 2013

Measuring Hackathon ROI for APIs

Hackathon ROII often get asked whether hackathons actually provide API publishers with any true, measurable return on investment (ROI). The simple answer is “yes” – and the positive benefits of hackathons are now undeniable.  However, the benefits can be a little hard to quantify, making ROI tricky to measure objectively.

For example, hackathons provide a fantastic way to grow developer awareness of your API as a brand in and of itself, separate from your core business. When the developers who attend your hackathon go back to their day jobs on Monday, they have added your API to their programming tool belts and will use it, when appropriate, in upcoming projects. Additionally, hackathons will attract the attention of thought leaders and influencers who will mention your API on blogs and forums, spreading the word further. These benefits can deliver considerable value but they can also be difficult to quickly quantify.

Nevertheless, API evangelists will be held accountable for demonstrating the real-world value of their hackathons. One way to do this is to show how hackathons enable your company to conduct developer user experience (DevUX) research at a minimal cost. Gathering feedback and data from hackathons provides the most cost-effective way to optimize the quality of your API as a product by answering questions like:

  • How user-friendly is my registration process?
  • Do my APIs ever return incorrect or unexpected results?
  • What new features should I add to future versions of my API?
  • Is the skill level of my API appropriate for long-tail app developers?
  • What kind of tutorials and other documentation will my developers need?
  • Which programming languages are my developers using to implement my APIs?
  • How useful is my API and what are the most common/innovative use cases for it?

The data and feedback you gather will also help you to further demonstrate ROI by providing the answers to questions such as:

  • How many developers registered and how many actually attended?
  • Did the hackathon appeal to the types of developer we want to attract?
  • Did any valuable or innovative apps get prototyped?

Hackathons offer a fantastic way to build excitement around your API and optimize the quality of your interface. If you still have any doubts, join us for a hackathon (and participate!) to see how other API platforms are doing it.