For close to five years, Intel has had a stake in the API space. All the while, I’ve often asked myself why. Intel originally acquired an API Gateway from a prior Intel Capital investment that never fully blossomed. And despite the oddness of having a tiny enterprise software franchise lost inside a semiconductor behemoth, Intel persisted in its experiment, even in the face of questionable market success and lukewarm analyst reaction. So, why double down on APIs now?

With the steady decline of the PC business, Intel clearly has to look elsewhere for its future growth. The cloud datacenter is not a bad place to start. Cloud server farms clearly consume lots of processors. Still, servers powering Web sites can operate fine without APIs, thank-you. But servers powering mobile is a different story. Mobile apps (whether HTML5, hybrid or native) get the data that makes them valuable from applications that reside in datacenters. And APIs are the key to letting cloud data be sharable with mobile apps.

Clearly, app-centric “smart” phones and tablets and TVs and cars and watches and glasses are changing the way we go about our daily business. And APIs will power these smart devices by giving enterprise and Internet companies a way to push their data to apps. That hope of bridging the cloud with mobile is probably why Intel has kept its current API product intact. Mashery broadens Intel’s API scope by providing a way to not only share data with mobile apps but now also the developers that build these apps. But will this plan succeed?

If it does, it will take quite a bit of time. The reality today remains that Intel – even despite the semi-recent McAfee acquisition – is not oriented to selling software or even cloud services into the enterprise. It’s missing the sales force. It’s missing the history. And in many ways, it’s missing the rest of the software stack it needs to power the networking, infrastructure and application parts that underpin data in the cloud. That will make selling an API platform comprising a legacy API Gateway and newfound API developer platform a harder proposition. It’s kind of out there alone.

Another obvious roadblock to making the Mashery acquisition successful is that Intel’s existing API Gateway and the Mashery API service are designed for two very different audiences inside the enterprise, with un-reconcilable needs. The API Gateway is designed for an IT department that wants to run its API Management layer in its own datacenter. The Mashery offering is designed for a non-IT buyer (a mobile program manager, say) who wants to run everything in someone else’s cloud.

One is technical, the other is not. One is on-premise, the other is SaaS. One sells traditional software licenses, the other pure subscription. The first aims to address internal and external API integration challenges. The latter is only really concerned with the challenge of acquiring external API developers (though Mashery would probably protest this point).

Will the two be a marriage made in heaven? Given that the Intel/Mashery partnership is already a year old and that Mashery was barely able to grow its revenues in that time, the likelihood seems remote. But who knows for sure? And anyway, Intel has probably not bought Mashery for its $12M in revenue but for its long-term potential as a pathway to mobile.

Putting 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:

• layer7.com/live

Submit your questions:

• Tweet using the tag #Layer7Live
• Email techtalk@layer7.com

The Consumer Electronics Show (CES) 2013 is starting in Las Vegas next week and cloud computing is on the agenda. You can be sure that a technology has moved out of the hype cycle and into everyday use when it shows up at a show like CES, known more for the latest TVs and phones than computing infrastructure. People don’t really need to talk about cloud any more; it’s just there and we are using it.

Of course there will always be a place for a little more talking and I’ll be doing some of this myself as part of the CES panel Privacy & Security in the Cloud. This discussion will take place on Monday Jan 7, 11am-12pm, in LVCC, North Hall N259. The panel is chaired by my good friend Jeremy Geelan, founder of Cloud Computing Expo, who honed his considerable moderation skills at the BBC.

I’m planning on exploring the intersection between the cloud and our increasingly ubiquitous consumer devices. We will highlight the opportunities created by this technological convergence but we will also consider the implications this has for our personal privacy. I hope you can join us.

A recent study by researchers at North Carolina State University and the University of Oregon describes a threat scenario that allows attackers to exploit cloud-based resources for malicious purposes like cracking passwords or launching denial-of-service attacks. The study has gotten a lot of attention, including articles in reputable sources like Dark Reading, Ars Technica and Network World.

In order to optimize the performance of mobile apps or browsers, some computation-heavy functions have been offloaded to cloud-based resources, which in turn access backend resources and Web pages. This creates a middle ground in the cloud that is exploited in the attack, which the authors call “Browser Map Reduce (BMR)”. In reading the paper, it’s clear that this is a legitimate threat. The authors actually carried it out using free resources, although they limited the scope in order not to be abusive.

Aside from questions of curiosity around the mechanics of the vulnerability, the obvious question is this: How can we mitigate this threat? Here are a few perspectives here as well as a method for each.

Apps – This “cloud offload” architecture has arisen because of the processing limitations of mobile devices. When a backend resource is requested by a mobile user, it makes sense to have the data returned in the most consumable format, in order to optimize user experience. Whenever possible, instead of doing this through “browser offload”, data should be returned as JSON objects. This API approach is a proven method that works for mobile devices and is not subject to the BMR threat.

Cloud Services – This threat should not be viewed as a dismissal of the “cloud offload” approach. Cloud-based resources are necessary for handling caching, data indexing and other key functions in the mobile paradigm. However, it serves as a warning that these dedicated cloud-based resources cannot be considered part of a walled garden that includes the associated mobile app. The resource’s entry point must be protected against attackers. Layer 7’s SecureSpan Mobile Access Gateway is an ideal choice for this access control, as it uses identity-based measures to ensure that only requests from legitimate sources are serviced.

Web-Based Resources – Although the backend Web resource was not exploited in this scenario, the study is a reminder that the topology of the mobile Web is changing and increasing in complexity. P2P app-to-API connections cannot be assumed and therefore inbound API calls cannot be implicitly trusted. API access must be controlled and the SecureSpan API Proxy is a leading solution for this purpose.

To sum up, this is a legitimate threat but not a reason to abandon the use of cloud-based resources for mobile app optimization. Be aware of the threats, employ the mitigations and then you can continue to enjoy the exciting growth of the mobile Web.

I’m excited to welcome back our API Evangelist Alex Gaber to do his second Tech Talk. Back by popular demand, Alex will take your questions on Optimizing Cloud-Driven Mobile Apps. Alex is a dynamic speaker who knows the app economy inside and out, has built several of his own mobile apps and regularly host hackathons all over the globe.

Building cloud- and API-driven mobile apps introduces complex challenges around syncing, caching and securing data. So, connect live with Layer 7 on Tuesday November 20, at 9am Pacific Time, when Alex will be answering your questions about how to address these challenges. Alex will also provide insight into a range of related best practices, including techniques for building cross-platform applications in HTML 5.

Click here to get the full event details and a reminder in your calendar. On the day of the event, join the event at layer7.com/live and tweet questions to #layer7live.