October 11th, 2012

Open up to the App Economy: API Management as a Service

APIfy LogoApps are everywhere. We are surrounded by them. They’re overrunning our smartphones and forcing us to buy ever larger tablets. They are on our TVs, on our game consoles, on our set-top boxes – everywhere in our living rooms. When I update my vehicle, I expect I’ll be asking what version of Android my prospective car has before I ask about its engine configuration.

Apps have become ubiquitous in just a few short years. It’s no surprise, then, that companies large and small want to be part of the app economy. For these companies, enabling internal and external app developers holds the promise of growing market reach, opening revenue streams and maximizing customer retention – all on the back of developer innovation.

For almost a decade, Layer 7 has been helping large organizations open their data and applications to outside partners, cloud services and developer communities. With APIfy, Layer 7 is now making these same capabilities available to smaller organizations and departments, straight from the cloud.

To small organizations looking to open their first APIs to outside developer communities, APIfy offers the core API Management, security and community features necessary to get started. And for users that end up wanting more advanced features, APIfy provides an easy entry point to the Layer 7 API Management Suite. With APIfy, we aim to create an API platform that can grow with our customers.

Over the next several months, we’ll be offering APIfy free on a limited-use beta program. We’re eager to get feedback, so we’re inviting you to sign up and work with us to make APIfy an industry-leading service for opening APIs to the app economy. Enjoy the trial and let us know how we can make things better!

October 8th, 2012

Define Your Own API Management Deployment Model

Category API Management
 

API Management platforms come in different shapes and sizes: cloud-based infrastructure, on-premise infrastructure, multi-tenant SaaS, single-provider portals, API ecosystems etc. For this third part in a series of posts on API Management deployment models, let’s look at some of the considerations in choosing the right approach for your API Management project.

Let’s Start With the Data
Assuming the data of the target APIs already exists, where is that data living? If the data does not exist, are there constraints as to where it can reside (certification requirements, legal obligations etc)? Bridging this data to the external world will require some level of security at the perimeter of the existing data zone, regardless of where or how the rest of the API Management infrastructure is deployed. In that case, the infrastructure model is at least part of the solution. Conversely, if the data does not exist yet and/or can freely exist in a public zone, the hosted API Management model is a great alternative. Ideally, the data or backend is located in the “same” public zone. This may seem obvious but if the same zone is not hosting both API Management and backend, you do not realize the full benefit. Backend as a service can be considered as part of the platform, especially for public deployments.
As Leif concludes in his post Do You Need MBaaS to be a Mobile Bad Ass Developer?, enterprise-focused APIs benefit less from MBaaS because the backend is too often tied to the enterprise zone.

Despite the advantages of a “near API Management”, many API providers require high degrees of elasticity, to handle seasonal peaks for example. Public providers deliver effective ways to accommodate such traffic characteristics. You want your cake and eat too? When data can be governed privately and pushed to public-side cache, API backend management is coordinated at the perimeter of each zone, to allow you to scale across multiple regions.

What About Identities?
Identity-related information is of particular sensitivity, which often makes it better suited for private. Even in situations where the data returned by APIs is effectively hosted, the authentication of subscribers can continue to involve an on-premise component. Done right, this means your API Management infrastructure will need to enable access control that accommodates federation across these zones.

OAuth accommodates this in many ways. One can decouple the OAuth authorization server closer to the source of the identity and the OAuth resource server closer to the API data. Another approach is to implement the OAuth implementation fully in each zone and delegate authentication across zones, using a federated authentication API.

The identities that applications will consume your API on behalf of may also be provided by a third party. Trends like social login and standards like OpenID Connect will enable this federated authentication to not only go across zones but integrate with social identity providers and enable a more social user experience. When building out your API Management infrastructure, be an OAuth hero, not a security zero.

Which Ecosystem?
Creating visibility for an API by joining an API ecosystem can also be a motivating factor in selecting an API Management platform. I would argue that the Internet is the ecosystem and that maintaining ownership of your own APIs and their infrastructure does not preclude you from reaching out to your target developer audience. An API marketplace may help provide the visibility you are looking for but the complete API management infrastructure will still have touch points to multiple zones, whether public or private.

In the end, there is no one-size-fits-all API Management deployment model and many considerations are relevant to design. This post does not claim to be an exhaustive list of such considerations. I’ve touched other obvious ones such as security and cost in the first and second parts of this series. Also, I will be describing this hybrid model in more detail at Cloud Security Alliance Congress when I give a presentation titled Seasonal Burst Handling Using Hybrid Cloud Infrastructure.

October 2nd, 2012

Non-Function Junction: API Automation for Enterprise Operations

API Operations AutomationRecently, I’ve been working closely with a number of large enterprise clients who have already gone or will soon go live with Layer 7 solutions at the core of mission-critical infrastructure. I’ve observed that, in the API Management space, proof of concept and initial projects often focus on functional needs but the emphasis shifts to non-functional requirements as environments mature and sharing increases. There’s a clear, three-phase progression for large enterprises, which moves along these lines:

  1. Solve the basic functional use cases – The 80% in the 80-20 rule
  2. Solve the remaining, more complex use cases – The 20%
  3. Deploy the basic functions on an enterprise scale – Back to the 80%

In Phase 3, it’s all about performance, scalability, operability, security, availability and consumability. The problems are very complex but the goal is to make the resulting solution as usable and simple as possible, given the wide range of users, developers, testers and operators that will be involved in its execution. As technology vendors, we are often guilty of focusing inwardly on bells and whistles, rather than outwardly on interoperability. This works well for phases 1 and 2 but brings a reckoning in the third phase. Fortunately, at Layer 7, we’ve spent the past decade working with enterprise clients and have evolved our products to meet their adaptability, reliability and automation needs.

The Layer 7 Management API is at the core of this capability. The Management API ships with all Layer 7 Gateways, to enable automated administration of policies, resources and access control that can plug into enterprise configuration management, deployment and monitoring systems. It can be accessed programmatically through a Java API, on the network through a Web service API or built into command line scripts. For the clients I have worked with, this capability and the assurance it provides on moving through the systems development lifecycle is quite simply a must have.