The unprecedented explosion of modern technologies combined with a burgeoning mobile space has forced enterprises to rethink previously held beliefs about the static enterprise perimeter. Remember the olden days when you said your enterprise was completely self-contained in one data center, with your apps inside the firewall and with everyone nearly as confident about it as being as secure as Ft. Knox? With an explosion in mobile computing, demand for cheap or “free” usage of resources, and a sharp reduction in cost with the cloud delivery model, it is expected (or rather demanded) that every enterprise expose their APIs not only from their enterprise but from a cloud based model. (NOTE: The cloud is referred to in a loosely defined delivery model be it — public, private, community or hybrid variety).
Couple this inexorable progression for having a cloud based model with the need for mobile enablement and web 2.0 technologies, and you are forced to expose not only your SOAP APIs, but also JSON, REST and other fast, quick TTM (time to market) APIs that can be easily manipulated and consumed.
This brings an interesting issue to the fore-front. You are forced to rethink your corporate security strategy. Many organizations (and the C levels that I speak with on a regular basis) are scared to move their sensitive applications (and processes, data) to the cloud, mainly, because of security. But that doesn’t stop them from exploring and moving some of the non-sensitive applications to the cloud and “testing the waters”, so to speak. Once they see how easy and cheap it can be, they begin losing sleep thinking about all of the money they can save by moving everything to the “cloud” due to the constant pressure to plan and come in under budget.
It’s no wonder that API traffic has exploded over the past few years. According to a recent survey, about 60% of the enterprise traffic is API based. According to Programmable Web, 75% twitter traffic is API based. According to Programmable Web there are at least 5000+ APIs (http://blog.programmableweb.com/2012/02/06/5000-apis-facebook-google-and-twitter-are-changing-the-web/) and the pace is growing. Programmable Web has a neat tool where you can search all the publicly available APIs (http://www.programmableweb.com/apis/directory). If you check this out you will immediately notice that most of the social APIs are mostly REST/ JSON based. There is obviously a good reason for that.
When it comes to APIs there are two distinct, broad categories – Social APIs and Enterprise APIs. The Social APIs are created by, and for, our society which is hungry for instant data updates. (Remember the AT&T 4G commercial “so 42 seconds ago” (http://www.youtube.com/watch?feature=player_embedded&v=bvVVQGgbKk0) . I miss the good old days where we found out what happened in the world by checking CNN website once an hour or so.
In general, the social APIs tend to be fast, easy to implement, REST only — without any enterprise class security, not monetized, and focused on publishing content etc.
You can’t afford to have the enterprise APIs published and consumed the same way. Your Enterprise class security needs to move with your applications API wherever it is going or however it is accessed. And it is not a question of if, it is a question of when. The success of companies with API as the core of their business models transformed the industry – look at Google, Twitter, Facebook, and other smaller players. According to Programmable Web “The most popular API category from the last 1,000 APIs is government. In total, we list 231 government APIs and nearly half of them have been added in the last four months.” When the government adopts a technology standard, you know that there is no going back, it is here to stay forever .
As applications migrate out of your own “Ft. Knox”, the issue will become more pronounced. You’ll still need the same quality of security, management, SLAs, centralization of usage based information – predicated on policy & identity information.
Most cloud providers just give you the base platform and leave most of this to you. However, your enterprise class APIs need to provide enterprise class security, governance, lifecycle management , API Key and credential management, throttling and quota management, security, protocol translation and versioning, API performance optimization, key management, discovery. The need to expose your APIs in multiple formats (as talked above such as REST, JSON, SOAP, etc), can multiply the complexity of an implementation exponentially.
Having set the stage (without wanting to scare you about the inherent risks of exposing your APIs to the cloud), let’s talk about how Intel can help you effortlessly achieve all of these things regardless of your usage model – without the need to be concerned about whether APIs are REST based, or full SOAP APIs or even JSON based mobile APIs.
Intel has been in the Web Services, XML, SOAP security space since the acquisition of Sarvega (circa 2005). Our expansion into the API security space has been a natural progression. We brought out an API security gateway last year which caught the attention of many of our customers. Especially given that it can help enterprises move enterprise grade security policies without having to rewrite the policies (and allow for subsequent enforcement of them in the cloud) makes it even more interesting.
With the addition of OAuth 2.0 to the API gateway in our latest release, it seems like a timely opportunity to talk about the capabilities of our API gateway. When you move your enterprise applications to the cloud and expose APIs from there,you can either retool your application to fit that platform/ delivery model . Or, you have a second option. Use our API gateway as the API middleware which can help you solve a lot of those issues. APIs have become strategic control points for the cloud.
So essentially you want to abstract the following functionality to API middleware:
- Keep your implementation technology agnostic. Provide a mechanism to support REST, JSON, SOAP, etc and mediate to the backend supported format in a non-intrusive manner. Most times this end result can be achieved by configuring the API gateway solution to act as a facade to the existing application. This is really important in the ever changing API world. JSON, REST APIs have evolved in the past few years. By being agnostic, you’ll be prepared for the next “flavor” in whatever way that instantiates itself.
- Keep your security and API management closer to your APIs and be transparent about it with your customers.
- Remove security, scalability, management and audit functionality and issues away from the an actual API implementation.
- Ensure that you have strong API monitoring, metering, logging, auditing, & versioning features.
Check out our API Gateway details to see how we can help you make this migration easy and painless.
http://software.intel.com/en-us/articles/Cloud-Service-Brokerage-API-Resource-Center/
For more information about Intel Expressway Service Gateway, case studies, testimonials and tech tutorials, please visit www.intel.com/go/identity
Andy Thurai — Chief Architect & CTO, Application Security and Identity Products, Intel. Andy Thurai is Chief Architect and CTO of Application Security and Identity Products with Intel, where he is responsible for architecting SOA, Cloud, Governance, Security, and Identity solutions for their major corporate customers. In his role he is responsible for helping Intel/McAfee field and technical teams and customer executives. Prior to this role he has held technology and architecture leadership and executive positions with L-1 Identity Solutions, IBM Datapower, BMC, CSC, and Nortel. His interests and expertise include Cloud, SOA, identity management, security, governance, and SaaS. He holds a degree in Electrical and Electronics engineering and has over 20+ years of IT experience.
